nm_vpn_connection_connect_cb(): VPN connection 'xyz' failed to connect: 'No VPN secrets!'.

i'm seeing the same issue, interestingly it may have something to do with the keyless secret i'm using.

With todays karmic I get the exact same errors (and same log content). I tried it with a password-less private key AND with a password protected private key, so that can't be the issue.

The information I gave NetworkManager was:
gateway, certificates and key, LZO-compression, port. In the IPv4 settings I edited the routes and checked the option to only use the connection for the network I'm connecting to (otherwise the internet-connection would also be routed through openvpn).

This used to work in jaunty but stopped working in karmic.

BTW: there are ALOT of duplicates of this bug.

Of course this is a showstopper for using karmic on company laptops (where you have no wired connection).

I have this same bug..

I can connect from the console using openvpn --script-security 2, which leads me to wonder if it is a regression from this bug : https://bugs.launchpad.net/ubuntu/+source/network-manager-openvpn/+bug/260291

I can confirm this behavior .

I can confirm this on karmic with working configuration from jaunty.
I'm using certificates for auth.

There are some messages in the terminal, if I start nm-applet from there:

** (nm-applet:21163): WARNING **: _nm_object_get_property: Error getting 'State' for /org/freedesktop/NetworkManager/ActiveConnection/26: Method "Get" with signature "ss" on interface "org.freedesktop.DBus.Properties" doesn't exist

** (nm-applet:21163): WARNING **: _nm_object_get_property: Error getting 'State' for /org/freedesktop/NetworkManager/ActiveConnection/27: Method "Get" with signature "ss" on interface "org.freedesktop.DBus.Properties" doesn't exist

** (nm-applet:21163): WARNING **: _nm_object_get_property: Error getting 'Devices' for /org/freedesktop/NetworkManager/ActiveConnection/27: Method "Get" with signature "ss" on interface "org.freedesktop.DBus.Properties" doesn't exist

** (nm-applet:21163): WARNING **: _nm_object_get_property: Error getting 'ServiceName' for /org/freedesktop/NetworkManager/ActiveConnection/27: Method "Get" with signature "ss" on interface "org.freedesktop.DBus.Properties" doesn't exist

** (nm-applet:21163): CRITICAL **: applet_get_connection_for_active: assertion `scope != NM_CONNECTION_SCOPE_UNKNOWN' failed

I think it's a dupe with bug #360818

could you try the workaround at the top of the description

I'm not really sure if this report is a duplicate.
I try the fix posted in the comments, but it does not work for me. I'm still getting the same error reported here.

But i can remember that i have the same problem reported by the other bug #360818 !
After restarting ubuntu (without changing anything!) the network-manager show this error message in syslog.

Yeap. Same for me. "No vpi secrets!"

same for me ... it worked well under jaunty, and stop working under karmic (btw : sometimes it works, but don't understand how to reproduce a success connexion)

This fix is working:

--- nm-openvpn-service.conf.fixed 2009-11-05 16:07:53.764591878 +0200
+++ nm-openvpn-service.conf 2009-11-05 12:24:59.672779358 +0200
@@ -6,6 +6,10 @@
   <allow own="org.freedesktop.NetworkManager.openvpn"/>
   <allow send_destination="org.freedesktop.NetworkManager.openvpn"/>
  </policy>
+ <policy user="at_console">
+ <allow own="org.freedesktop.NetworkManager.openvpn"/>
+ <allow send_destination="org.freedesktop.NetworkManager.openvpn"/>
+ </policy>
  <policy context="default">
   <deny own="org.freedesktop.NetworkManager.openvpn"/>
   <deny send_destination="org.freedesktop.NetworkManager.openvpn"/>

This fix does not work for me!
But I have noticed that I am able to connect sometimes.
After trying to connect, I have wait a little bit and try it again and then it works sometimes.

Like @rene.
this fix doesn't work for me.
And sometimes it works as expected, sometimes not (!?!)

The at_console fix is still working for me.
It required a dbus and network manager restart (I rebooted).
Perhaps the noted workaround of not having any root shells active is affecting you.
It would be worth trying the connection both with and without a root shell open on the machine
to see if that makes the failure consistent.

I have checked if any root shell is running and try both, connecting with and without any root shell running but i can not connect. Tomorrow i will try to log some debug informations and add them here.

I had this issue after installing the openvpn plugin for network
manager, but in my case, all I had to do was restart the machine and
everything was working properly. It hasn't misbehaved since. Did that
work for anyone else?

HI - I am too getting this problem - fresh copy of Karmic - Open Vpn connection to me server at work:
no password needed - 2 cert files and a key file
and I get this error when connecting

Nov 10 21:29:57 glenn-laptop NetworkManager: <info> Starting VPN service 'org.freedesktop.NetworkManager.openvpn'...
Nov 10 21:29:57 glenn-laptop NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.openvpn' started (org.freedesktop.NetworkManager.openvpn), PID 2435
Nov 10 21:29:57 glenn-laptop kernel: [ 101.248287] tun: Universal TUN/TAP device driver, 1.6
Nov 10 21:29:57 glenn-laptop kernel: [ 101.248292] tun: (C) 1999-2004 Max Krasnyansky <email address hidden>
Nov 10 21:29:57 glenn-laptop NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.openvpn' just appeared, activating connections
Nov 10 21:29:57 glenn-laptop NetworkManager: <info> VPN plugin state changed: 3
Nov 10 21:29:57 glenn-laptop NetworkManager: <info> VPN connection 'nicor' (Connect) reply received.
Nov 10 21:29:57 glenn-laptop NetworkManager: <WARN> nm_vpn_connection_connect_cb(): VPN connection 'nicor' failed to connect: 'No VPN secrets!'.
Nov 10 21:29:57 glenn-laptop NetworkManager: <WARN> connection_state_changed(): Could not process the request because no VPN connection was active.
Nov 10 21:29:57 glenn-laptop NetworkManager: <info> (wlan0): writing resolv.conf to /sbin/resolvconf
Nov 10 21:29:57 glenn-laptop NetworkManager: <info> Policy set 'Auto dlink' (wlan0) as default for routing and DNS.

Tried adding the at_console bits - not sure if its right - rebooted - not workging,

<!DOCTYPE busconfig PUBLIC
 "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN"
 "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
<busconfig>
 <policy user="root">
  <allow own="org.freedesktop.NetworkManager.vpnc"/>
  <allow send_destination="org.freedesktop.NetworkManager.vpnc"/>
 </policy>
 <policy context="default">
  <deny own="org.freedesktop.NetworkManager.vpnc"/>
  <deny send_destination="org.freedesktop.NetworkManager.vpnc"/>
 </policy>
 <policy user="at_console">
  <allow own="org.freedesktop.NetworkManager.vpnc"/>
  <allow send_destination="org.freedesktop.NetworkManager.vpnc"/>
 </policy>
</busconfig>

any other things I can try?

This "Fix" isn't working for this issue, so please remove it from your config file.

So what does work then?

Try to connect to your server by running openvpn in terminal, if you have a config file for it:

sudo openvpn --config example.conf

If you do not have any config file, you can create a new one or modifiy this example to your needs:

http://openvpn.net/index.php/open-source/documentation/howto.html#examples (you have to scroll a little bit down!)

This is the way i am doing it right now.

Thank you Rene,

when not using the NM Plugin everything is fine. So your methode with the console works.

If any Developer wants to reproduce the error, i can provide an OpenVPN Server and fitting Certificates.

Some other Information on this:

Using Ubuntu 8.10 the NM is not affected and the VPN Connection is working like it should.

Greetings

@rene jablonsky

I did what you said, in a terminal ...
everythins seems fine ... openvpn displays :
Fri Nov 20 18:48:40 2009 Initialization Sequence Completed

but when I launch my browser, it can't connect to the internet ?!?
is there a way to launch that ?

Do you connect to the internet directly (using network-manager) or do you use a router?
I think the problem is, that Ubuntu tries to route all traffic through the vpn conncetion which actually fails.
I am not sure how you have to set up the internet connection to avoid this.
Maye all you need to do is to set up a dns server for the internet connection, but i am not sure!
I will try it by myself ...

@rene jablonsky
> Do you connect to the internet directly (using network-manager)
> or do you use a router?

directly (using network-manager)

I can't test it at the moment, but i will try it later.

Ok, just add one or more DNS Server to your DSL config under tab IP4 Configuration. This should help you.
Here are some free uncensored dns server:

http://wiki.ak-zensur.de/index.php/Unzensierte_DNS_Server

I have tested this way and the internet works like expected.

@rene
I can't edit DNS under IP4 ... coz I'm in DHCP ... so I setup them (opendns) thru /etc/resolv.conf
restarted the network-manager ...
and trying to do your openvpn command line ...
and it doesn't seem better ... can't resolve ;-( ...
it's very not easy, with this bug ;-(

@rene
sorry for my last post : I found a solution ...
I had created another eth0 profil, with manual connection (ip, gateway, mask and dns) ... and I use this one when i need to connect to my vpn with a manual "sudo openvpn --config example.conf".
and it works .. I can connect to my openvpn provider again !!!! (great ! it's hidden, but I'm happy again) ...

It was a lot lot lot easier in jaunty ;-)

I experience this problem too, and its getting really anying. Therefor I started to debug this problem by myself. If have no idea of NetworkManager by grepping through the source I found out that the message is generated from nm-openvpn-service.c.

I compiled the network-manager-openvpn service by cloning it from the git repository and install some additional packages (namely libdbus-glib-1-dev libnm-glib-dev intltool libtool autoconf libgtk2.0-dev libglade2-dev libgconf2-dev libgnome-keyring-dev). Then I executed this...
./autogen.sh --prefix=/usr/bin/ --libexecdir=/usr/lib/network-manager-openvpn/
make

This then compiled the service and i could stat it by invoking

sudo ./src/nm-openvpn-service

The applet then uses this newly compiled service. I added some debug messages and found this out:
The function real_connect calls nm_connection_get_setting, which contains the settings for the choosen vpn. Later then, the settings are verified, and it fails when he tries to verify the secret. Even if there is no secret set at the applet, the applet sets a secret property with the name no-secret to true.

I added right after the nm_connection_get_setting call this code:
tmp = nm_setting_vpn_get_secret (s_vpn, NM_OPENVPN_KEY_NOSECRET);
nm_info("No Secert Property: %s", tmp);

Each time when it worked, this code returns that:
** Message: <info> No Secert Property: true

But most of the time, everytime it fails, this code returns that:
** Message: <info> No Secert Property: (null)

The property is sometimes set, and sometimes not! I do have no idea why this can happen, but I suggest there is a race condition somewhere. I would have to debug the nm_connection_get_setting, which belongs to libnm-util1. Would nice if a developer with more know how in this area could have a look why this property is not set sometimes. Or give me hints what I could test/where to search exactly...

the trouble is gone away for me, with this workaround, but I don't know where I've red that ...

My VPN is configured with a "certificat tls" ... and I simply choose "password with certificat TLS", and enter anythig in login/password : and now it works for me !!!!, like in previous ubuntu version !

hourra !

The work around posted by manatlan on 2009-12-06 seems to have fixed my "No VPN secrets" problem.

Thanks manatlan!

The workaround by manatlan works for me as well. thanks!

This bug is most definitely <b>not</b> a duplicate of <a href=" https://bugs.launchpad.net/bugs/360818">Bug #360818</a>!

That bug deals with dbus rejecting permission to send a message to the user at the console.

This bug deals with a separate issue: dbus allows sending the message but, <a href="https://bugs.launchpad.net/ubuntu/+source/network-manager-openvpn/+bug/453807/comments/31">as falstaff noted</a> the program later attempts to read the "Secret Property", and it gets inconsistent results: the call to nm_setting_vpn_get_secret (s_vpn, NM_OPENVPN_KEY_NOSECRET) sometimes returns the string "true", sometimes NULL. The connection works when it returns "true", and fails when it returns NULL, resulting in intermittent failure to connect. Most of the time, the connection fails, but every few times it does work.

Please, remove the "duplicate" link in this bug, it is incorrect.

Looks like you aren't the only one to have noticed this.

See http://<email address hidden>/msg166998.html

This patch solves the issue.

The problem was that the service attempted to validate secrets for all connection types except static keys (the comment was "/* Static Key doesn't need secrets; the rest do */"), which is incorrect: passwordless TLS doesn't need secrets either. the attached patch solves the issue. I am still mistyfied as to why it *sometimes* worked, though...

This patch solves for openvpn the same issue than was reported for vpnc in Bug #360818, and solved through the patch at: <http://launchpadlibrarian.net/25715305/nm-vpnc-service.patch>.

Ivars Strazdiņš sent this patch to the discussion, but it doesn't work if you take it from there because the formatting is mangled.

Looking futher in the code, I realized that the problem may be that the developers of the program don't want to support unencrypted private key certificates because they are a security risk. Encrypted private key certificates have the .pem extension instead of .key, and network-manager stores a secret for them in the keyring: the password needed to decrypt the key certificate.

What we may be seeing here is a disconnect between the configuration user interface (which does allow the user to specify an unencrypted key certificate) and the connection back-end (which refuses to work with a not-very-helpful error message when the user configures the VPN this way).

So, another workaround to get this working is to use encrypted private key certificates, but if it is the developer's intent to force the use of such keys, then the UI should not allow the user to select a plaintext key file, and provide a helpful message explaining why it is not allowed, and how to obtain an encrypted key from a plaintext one (openssl rsa -in somecert.key -des3 -out somecert.pem).

@perlhead's solution of encrypting the key works perfectly!

there is also this workaround that could work

https://bugs.launchpad.net/ubuntu/+source/network-manager-vpnc/+bug/360818/comments/97

look at

https://launchpad.net/~nail-nodomain/+archive
it contains many fixes

the link is taken from https://bugs.launchpad.net/ubuntu/+source/network-manager-openvpn/+bug/117991

I'd like to confirm that perlhead's solution of encrypting the private key works for me. It's not a big deal as you are prompted to save the passphrase to the GNOME keyring the first time you connect using your encrypted private key file.

I'll be ... The below comment works for me.

Tried everything else, with no succes.

I have the exact problem, "... no secrets", using ssh and openvpn in Karmic

Ferry

Comment 97 for bug 360818
Anton Lindström wrote on 2009-12-04: #97

Just want to comment that I have found a workaround for network-manager-openvpn: Instead of selecting authentication type "Certificate (TLS)" (I'm translating this to English so it might not be exactly the same) I select "Password with certificate (TLS)". Then I fill in a bogus username and password. This works for me, I hope it could help someone else.

Confirmed the workaround proposed by Ferry Toth.
Select "Password with Certificates (TLS)" instead of just "Certificates (TLS)".
Then enter a bogus username and password.
Works great. Thanks Ferry!

Same issue here, and Anton's workaround works for me too.
For those of you using Kubuntu, the setting to change is "Connection type", from "X.509 Certificates" to "X.509 With Password".

I also can confirm the workaround proposed by Ferry Toth.
Really great help.
Thank you, Ferry!

I'm also having this issue, however, the workarounds above don't work for me. I have an ovpn file that I use on Windows with the OpenVPN GUI just fine. I've tried using Certs + credentials (that are bogus), and I've tried using an encrypted key file.

seems like this is fixed in network-manager-openvpn 0.8-0ubuntu1 as i was able to do "Certificates (TLS)" with a private key passphrase without any bogus user & password. this is on a clean installation of lucid with deleted user settings.

Yes, it's fixed. If you happen to have a connection TLS with password - with a bogus username/password, you can reset it to TLS (without password) and it will keep working.

Bit of additional info, had this issue on first use of the VPN. Did a machine restart and error is gone. Lucid, network-manager-openvpn 0.8-0ubuntu3

Hi,

I think I really need your help: I just installed 2 days ago Ubuntu 10.04.1 LTS (x88) plus OpenVPN and Network Manager Gnome support (amongst with PPTP and CISCO) => network-manager-openvpn 0.8-0ubuntu3

I also had the 'No VPN secrets!' error. So I've applied the modification to nm-openvpn-service.conf

        <policy user="at_console">
                <allow own="org.freedesktop.NetworkManager.openvpn"/>
                <allow send_destination="org.freedesktop.NetworkManager.openvpn"/>
        </policy>

But when I try to activate the OpenVPN connection, I have the following error:

Aug 24 22:53:26 box NetworkManager: <info> Starting VPN service 'org.freedesktop.NetworkManager.openvpn'...
Aug 24 22:53:26 box NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.openvpn' started (org.freedesktop.NetworkManager.openvpn), PID 2285
Aug 24 22:53:26 box NetworkManager: <WARN> vpn_service_watch_cb(): VPN service 'org.freedesktop.NetworkManager.openvpn' exited with error: 1
Aug 24 22:53:26 box NetworkManager: <info> (eth0): writing resolv.conf to /sbin/resolvconf
Aug 24 22:53:26 box NetworkManager: <info> Policy set 'Auto eth0' (eth0) as default for routing and DNS.
Aug 24 22:53:32 box NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.openvpn' did not start in time, cancelling connections

I'm stuck since two days on it...

The connection type is a really basic "Certificates TLS" with a private key requiring a password. I've tried to change

user="at_console"
to
at_console="true"

I've checked that the vpn settins in gconf-editor are there, and also the password in gnome keyring manager.

Addition:

I've also tries to swicht to "Password with certificate (TLS)" with a username/password but the same error is displayed.

If I start NetworkManager from the console, I see this error:

NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.openvpn' started (org.freedesktop.NetworkManager.openvpn), PID 6085

** (process:6085): WARNING **: <WARN> constructor(): Connection ":1.61" is not allowed to own the service "org.freedesktop.NetworkManager.openvpn" due to security policies in the configuration file

NetworkManager: <WARN> vpn_service_watch_cb(): VPN service 'org.freedesktop.NetworkManager.openvpn' exited with error: 1
NetworkManager: <info> (eth0): writing resolv.conf to /sbin/resolvconf

On 25/08/2010, Mathieu Carbou wrote:
> I've also tries to swicht to "Password with certificate (TLS)" with
> a username/password but the same error is displayed.

Hmmm... then it's not the same bug.

 Fede

(10.04) I'm having a similar bug with a PPTP VPN. It works fine until I try to set it to be Available to all users. I assume this is because the password isn't in the connection's file under /etc/NetworkManager/system-connections, and it's only in my user's keyring. Adding "password=xxx" or "pass=xxx" to the connection's file didn't work, only got me an error saying those parameters are unsupported.

10.10 has the same exact issue, are we getting some progress from release to release or just benefiting from the hype ?

Hy!

Actually it seems to solved in maverick for me.

On Tue, Oct 19, 2010 at 3:58 PM, Iustinian T. <email address hidden>wrote:

> 10.10 has the same exact issue, are we getting some progress from
> release to release or just benefiting from the hype ?
>
> --
> nm_vpn_connection_connect_cb(): VPN connection 'xyz' failed to connect: 'No
> VPN secrets!'.
> https://bugs.launchpad.net/bugs/453807
> You received this bug notification because you are a direct subscriber
> of a duplicate bug (442862).
>

Same issue here under Karmic with OpenVPN.

I'm using TLS with no password.

Changing the Type to Password with Certificates (TLS) and a dummy username/password means OpenVPN connections are reliable again.

Currently solution is to restart network-manager.

Would it be appropriate for such a restart to be added to the post-install script as possibly an ugly hack?

I think the problem with the Network Manager OpenVPN plug-in (excluding the access issues related to bug #360818) is that it only recently gained the ability to store passwords for system-wide connections (a.k.a. Available to all users):
https://bugzilla.gnome.org/show_bug.cgi?id=619610

I forgot to add that the plug-in requires a password-protected key:
http://mail.gnome.org/archives/networkmanager-list/2010-February/msg00108.html