NetworkManager.vpn fails -- nm-vpn-connection.c.900: NeedSecrets

Bug #360818 reported by naheed
534
This bug affects 135 people
Affects Status Importance Assigned to Milestone
network-manager-openvpn (Fedora)
Invalid
Medium
network-manager-openvpn (Ubuntu)
Fix Released
Medium
Martin Knudsen
Nominated for Karmic by Chris Sherlock
Nominated for Lucid by Chris D
network-manager-pptp (Ubuntu)
Fix Released
Undecided
Unassigned
Nominated for Karmic by Chris Sherlock
Nominated for Lucid by Chris D
network-manager-vpnc (Ubuntu)
Fix Released
Medium
Alexander Sack
Nominated for Karmic by Chris Sherlock
Nominated for Lucid by Chris D

Bug Description

WORKAROUND: ensure that you have no root shells (e.g. close/exit all sudo su terminals etc.) open while connecting.

Binary package hint: network-manager-vpnc

vpnc:
  Installed: 0.5.3-1
  Candidate: 0.5.3-1
  Version table:
 *** 0.5.3-1 0

network-manager:
  Installed: 0.7.1~rc4.1.cf199a964-0ubuntu1
  Candidate: 0.7.1~rc4.1.cf199a964-0ubuntu1
  Version table:
 *** 0.7.1~rc4.1.cf199a964-0ubuntu1 0

network-manager-vpnc:
  Installed: 0.7.1~rc4.20090316+bzr21-0ubuntu2
  Candidate: 0.7.1~rc4.20090316+bzr21-0ubuntu2
  Version table:
 *** 0.7.1~rc4.20090316+bzr21-0ubuntu2 0

I am trying to connect to corporate cisco vpn via network-manager-vpnc plugin. vpnc is able to connect successfully via cmdline with the same configuration parameters, whereas nm.vpnc fails to connect. It doesn't even try to connect to external server (confirmed from wireshark), and bails out by saying "Failed because there were no valid VPN secrets".

daemon.log :

Apr 13 17:52:51 buraq NetworkManager: <info> Starting VPN service 'org.freedesktop.NetworkManager.vpnc'...
Apr 13 17:52:51 buraq NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.vpnc' started (org.freedesktop.NetworkManager.vpnc), PID 5228
Apr 13 17:52:51 buraq NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.vpnc' just appeared, activating connections
Apr 13 17:52:51 buraq NetworkManager: nm-vpn-connection.c.900: NeedSecrets failed: dbus-glib-error-quark Rejected send message, 1 matched rules; type="method_call", sender=":1.8" (uid=0 pid=3572 comm="/usr/sbin/NetworkManager --pid-file /var/run/Netwo") interface="org.freedesktop.NetworkManager.VPN.Plugin" member="NeedSecrets" error name="(unset)" requested_reply=0 destination="org.freedesktop.NetworkManager.vpnc" (uid=0 pid=5228 comm="/usr/lib/network-manager-vpnc/nm-vpnc-service "))
Apr 13 17:52:51 buraq NetworkManager: <WARN> connection_state_changed(): Rejected send message, 1 matched rules; type="method_call", sender=":1.8" (uid=0 pid=3572 comm="/usr/sbin/NetworkManager --pid-file /var/run/Netwo") interface="org.freedesktop.NetworkManager.VPN.Plugin" member="Disconnect" error name="(unset)" requested_reply=0 destination="org.freedesktop.NetworkManager.vpnc" (uid=0 pid=5228 comm="/usr/lib/network-manager-vpnc/nm-vpnc-service "))
Apr 13 17:52:51 buraq NetworkManager: <info> (wlan0): writing resolv.conf to /sbin/resolvconf
Apr 13 17:52:51 buraq NetworkManager: <info> Policy set 'bindaas' (wlan0) as default for routing and DNS.
Apr 13 17:53:04 buraq NetworkManager: <debug> [1239670384.002921] ensure_killed(): waiting for vpn service pid 5228 to exit
Apr 13 17:53:04 buraq NetworkManager: <debug> [1239670384.003055] ensure_killed(): vpn service pid 5228 cleaned up

--
My VPN settings in NM GUI has a valid Gateway, Group-name, Group-password (converted from obfuscated-secret using /usr/lib/vpnc/cisco-decrypt), User name. Encryption method is set to Secure(default) and NAT Traversal is Cisco UDP (default). DPD is checked.

naheed (naheed)
tags: added: jaunty networkmanager vpnc
summary: - NetworkManager.vpn fails complaining : NeedSecrets
+ NetworkManager.vpn fails -- nm-vpn-connection.c.900: NeedSecrets
Revision history for this message
David Fokkema (dfokkema) wrote :

I can confirm this. I'm wondering what the dbus error 'Rejected send message' means, but to me, it seems to be the culprit.

Revision history for this message
Patrick Healy (phealy) wrote :

This is affecting me as well on the 9.04rc, with the same settings/symptoms as the original post. While looking up this bug report, I noticed a somewhat similar problem with network-manager-pptp that was resolved by fixing dbus permissions (bug 343270).

Revision history for this message
Patrick Healy (phealy) wrote :

Actually, reading off that other bug, I added the at_console permissions to /etc/dbus-1/system.d/nm-vpnc-service.conf and fixed the problem. A patch is attached.

Revision history for this message
Pobice (robert-pobice) wrote :

I can confirm the above patch fixes the error. Please note you will need to restart after chaning the conf file.

Revision history for this message
Alexander Sack (asac) wrote :

i assume this is still an issue in latest jaunty? does it help to flag the vpn connection for "Make available to All users"?

Changed in network-manager-vpnc (Ubuntu):
status: New → Incomplete
Revision history for this message
Pobice (robert-pobice) wrote : Re: [Bug 360818] Re: NetworkManager.vpn fails -- nm-vpn-connection.c.900: NeedSecrets

On Mon, 20 Apr 2009 21:29:29 +0100, Alexander Sack <email address hidden> wrote:

> i assume this is still an issue in latest jaunty? does it help to flag
> the vpn connection for "Make available to All users"?
>
> ** Changed in: network-manager-vpnc (Ubuntu)
> Status: New => Incomplete
>

Yes - It was still a bug in the latest jaunty (I came across the bug
today), but the patch above fixed it for me.

Not sure about that flag - will test it tomorrow if I remember.

Revision history for this message
Alexander Sack (asac) wrote :

please run

tar czf /tmp/dbus-dir.tgz /etc/dbus-1/system.d/

and attach the dbus-dir.tgz.

also run dpkg-query -W -f'${Conffiles}' network-manager-vpnc and post the output.

thanks.

Revision history for this message
Patrick Kilgore (patrick-kilgore) wrote :

Alexander,
I am seeing the exact same issue with Jaunty, here is my information.

Output of dpkg-query:
 /etc/dbus-1/system.d/nm-vpnc-service.conf fd1972dab1966261b4cc7aaa274d3e84
 /etc/NetworkManager/VPN/nm-vpnc-service.name da725da28b8e843fa6c32dde7a2b3851

Changed in network-manager-vpnc (Ubuntu):
status: Incomplete → Confirmed
Revision history for this message
Alexander Sack (asac) wrote :

so please run

sudo /usr/lib/network-manager-vpnc/nm-vpnc-service

in one terminal and

sudo dbus-send --print-reply --system --dest=org.freedesktop.NetworkManager.vpnc /org/freedesktop/NetworkManager/VPN/Plugin org.freedesktop.NetworkManager.VPN.Plugin.Disconnect

in another ... does that work?

Revision history for this message
Patrick Kilgore (patrick-kilgore) wrote :

Doesn't look like it.

Here's what I get after running the dbus-send command:

pck@ubuntu:~$ sudo dbus......
[sudo] password for pck:
method return sender=:1.238 -> dest=:1.240 reply_serial=2
pck@ubuntu:~$

No VPN connect was established.

Revision history for this message
Alexander Sack (asac) wrote :

ok. we need to get more output from dbus.

can you please stop dbus (sudo /etc/init.d/dbus stop) and start it from a command line like:

sudo DBUS_DEBUG_OUTPUT=1 dbus-daemon --nofork 2>&1 | tee /tmp/dbus.log.txt

... then please reproduce and attach the dbus.log.txt.

Thanks!

Revision history for this message
Pobice (robert-pobice) wrote :

I've just removed the patch and the vpn connection is still working . Even setting up a new user and new vpn connection is fine, so am unable to do any more tests. I'll upgrade my PC to jaunty tomorrow to see if it has the same issue as my laptop had so I can do some more debugging.

Revision history for this message
Patrick Kilgore (patrick-kilgore) wrote :

Alexander,
Despite my best efforts to hack away around it, I cannot seem to stop dbus without being logged out of gnome and my system becoming unresponsive. Any suggestions?

Revision history for this message
Alexander Sack (asac) wrote :

you could see if adding a line:

export DBUS_DEBUG_OUTPUT=1

in /etc/default/dbus

enables debug output for you (usually would go to syslog i think). but be careful that could produce really a lot of output, so in case everything slows down or causing other issues, remember to remove that again.

Revision history for this message
Alexander Sack (asac) wrote :

so in case it works, let the system settle and (assuming its syslog where the output goes to) do a

 tail -n0 -f /var/log/syslog > /tmp/dbus.log.txt

right before clicking on the VPN menu entry. hit ctrl-c to abort that "tail" thing right after the bug happened.

Revision history for this message
Patrick Kilgore (patrick-kilgore) wrote :

Adding export DBUS_DEBUG_OUTPUT=1 to the params section of /etc/default/dbus resulted in the same errors as before, with system unresponsiveness at the login screen. A hard restart is required to reboot, and I had to recovery console into the config file and remove the option to get my system to work. Looking at my logs, it appears that dbus just doesn't start with that option enabled, either way a few services seem to be freaking out because of it (relevant section in syslog attached).

Revision history for this message
Alexander Sack (asac) wrote :

> Adding export DBUS_DEBUG_OUTPUT=1 to the params section of /etc/default/dbus

not sure i understand. did you add that into PARAMS="..."? doing that will probably make dbus not start, yes.

please check if you did you do what i said:

> you could see if adding a line:
> export DBUS_DEBUG_OUTPUT=1
> in /etc/default/dbus

Revision history for this message
Patrick Kilgore (patrick-kilgore) wrote :

Ahh nope, that was my mistake.
However, I just tried the connection and it worked. Doesn't make any sense, wasn't working even this morning. Maybe an update got it? I didn't pay attention to see if network-manager or network-manager-vpnc was patched. Or maybe it was on my school's end? Either way, my problem is solved.

I'll let you know if the issue reappears.

Thanks for the help.

Revision history for this message
Alexander Sack (asac) wrote :

maybe you never rebooted before?

Changed in network-manager-vpnc (Ubuntu):
status: Confirmed → Invalid
Revision history for this message
Patrick Kilgore (patrick-kilgore) wrote : Re: [Bug 360818] Re: NetworkManager.vpn fails -- nm-vpn-connection.c.900: NeedSecrets

No, that is always bugfix #1 for me. I did delete the vnc profile I
currently had before I started your debugging procedure. Maybe it was a
problem with carrying it over from intrepid in the upgrade and it was fixed
by recreating in Jaunty?

Revision history for this message
Alexander Sack (asac) wrote :

the vpnc profile fixing this is really really unlikely. you clearly had dbus communication issues, which usually mean your system.d policies are messed up. Did you revert to the default files there? Maybe you still have the at_console hack in it?

Revision history for this message
wei (weiweiseu) wrote :

I have the same problem and fixedwith Patrick Healy 's method.
Thanks for help!

Revision history for this message
Mike Crowe (mac) wrote :

I had what looks like the same problem with network-manager-openvpn (it looked like the same type of DBUS miscommunication.)

The problem went away after a complete system restart. I made no configuration file changes elsewhere.

I only mention this because many people seem to be reporting that everything starts working without explanation - it could very well be that a configuration file added/tweaked during install isn't being enacted until the next boot.

Revision history for this message
Stephen Crowley (crow-crowlogic) wrote :

The patch to nm-vpnc-service.conf above is incorrect, instead of user="at_console" it should be at_console="true"

<policy at_console="true">
 <allow own="org.freedesktop.NetworkManager.vpnc"/>
 <allow send_destination="org.freedesktop.NetworkManager.vpnc"/>
</policy>

This makes vpnc work, but still I set tons of rejected send messages from dbus in /var/log/auth.log

Revision history for this message
Vincent Hindriksen (vhindriksen) wrote :

I can confirm the bug and the fix of Patrick Healy does work.

@Stpehen, you must have another issue. please look in your log-files and see what you have.
@Alexander, I normally do not reboot my pc except for kernel-changes. In Windows rebooting might be called a fix, in Linux it remains a bug. So therefore I changed the state to "incomplete".

Changed in network-manager-vpnc (Ubuntu):
status: Invalid → Incomplete
Revision history for this message
Keith Buel (kbuel) wrote :

I can confirm this error as well. I am receiving the same error as the one pasted in the original description in my /var/log/syslog file.

Revision history for this message
Alexander Sack (asac) wrote :

this stays invalid. dbus policy changes only get applied after reboot in ubuntu ... you can manually try to reload dbus config.

Also dont apply the none fix with at_console ... that really makes no sense and opens security issues for you. Dont spread that stuff around please.

Changed in network-manager-vpnc (Ubuntu):
status: Incomplete → Invalid
Revision history for this message
Alexander Sack (asac) wrote :

also remember that as soon as you touched any file in /etc/ you wont get those files auto updated anymore ... so in future you might end up in more issues if we need to change the dbus rules.

Revision history for this message
Alexander Sack (asac) wrote :

ok. after getting more complains about these issues we debugged this and it turned out to be caused by new consolekit behaviour.

Problem is that root becomes @console if you have a root shell open (like sudo su). So to connect you just need to log out all root shells.

We are working on a solution real solution on this, so stay tuned.

Changed in network-manager-vpnc (Ubuntu):
assignee: nobody → Alexander Sack (asac)
importance: Undecided → Medium
status: Invalid → In Progress
Revision history for this message
Serwei (serwei) wrote :

meanwhile running 'sudo vpnc' works without problems, I'm using this while waiting for the elegant solution :)

Alexander Sack (asac)
description: updated
Revision history for this message
Alexander Sack (asac) wrote :

> meanwhile running 'sudo vpnc' works without problems, I'm using this
> while waiting for the elegant solution

Thats great. but please don't post such things as workaround to network-manager bugs ... while this might sound like a smart idea (and maybe its indeed smart), its not productive (trust me!) and exiting all root shells while you connect does not really ask for much ;).

Revision history for this message
Alexander Sack (asac) wrote :

so back to topic: if you see this issue, could you please confirm that there is a /var/run/console/root file? If so, please verify that exiting all root shells fixes this. Thanks!

Revision history for this message
Chris Sherlock (ta-bu-shi-da-yu) wrote :

I don't have a /var/run/console/root file, there are no root shells running, but I'm still getting this issue.

Revision history for this message
Alexander Sack (asac) wrote :

Chris, did you reboot in between?

Revision history for this message
Alexander Sack (asac) wrote :

Chris, could you please also attach the syslog output you get while trying to connect? I want to check that you are really seeing this issue.

Revision history for this message
Chris Sherlock (ta-bu-shi-da-yu) wrote :

May 7 08:22:08 ubuntu NetworkManager: <info> Starting VPN service 'org.freedesktop.NetworkManager.vpnc'...
May 7 08:22:08 ubuntu NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.vpnc' started (org.freedesktop.NetworkManager.vpnc), PID 8365
May 7 08:22:08 ubuntu NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.vpnc' just appeared, activating connections
May 7 08:22:08 ubuntu NetworkManager: <info> VPN plugin state changed: 1
May 7 08:22:14 ubuntu NetworkManager: <info> VPN plugin state changed: 3
May 7 08:22:14 ubuntu NetworkManager: <info> VPN connection 'For clients behind a NAT devices' (Connect) reply received.
May 7 08:22:14 ubuntu kernel: [288742.257810] tun0: Disabled Privacy Extensions
May 7 08:22:18 ubuntu NetworkManager: <info> VPN plugin failed: 0
May 7 08:22:18 ubuntu NetworkManager: <info> VPN plugin state changed: 6
May 7 08:22:18 ubuntu NetworkManager: <info> VPN plugin state change reason: 10
May 7 08:22:18 ubuntu NetworkManager: <WARN> connection_state_changed(): Could not process the request because no VPN connection was active.
May 7 08:22:18 ubuntu NetworkManager: <info> Policy set 'Auto eth0' (eth0) as default for routing and DNS.

Revision history for this message
Chris Sherlock (ta-bu-shi-da-yu) wrote :

Sorry, I forgot to note that I have rebooted since then - same issue :-)

I'd love to get a VPN connection to my work's network, I am willing to assist further. Tell me what is required and I'll do it, gladly!

Revision history for this message
Robinson Tryon (colonelqubit) wrote :

I had the same problem and was able to correct it using Patrick Healy's patch.

I'm running up-to-date Ubuntu 9.04 x86_64.

network-manager: 0.7.1~rc4.1.cf199a964-0ubuntu2
network-manager-gnome: 0.7.1~rc4.1-0ubuntu2
network-manager-vpnc: 0.7.1~rc4.20090316+bzr21-0ubuntu

Please let me know if there's any testing, etc... I can do to speed up the release of the "real solution" Alexander mentions above.

Revision history for this message
eryksun (eryksun) wrote :

In 9.04 I have the same error: NeedSecrets failed: dbus-glib-error....
No root shell is running (var/run/console).
sudo vpnc-connect works at the terminal.
Patrick Healy's user="at_console" policy fixes the problem.

Revision history for this message
AndersAndreasen (andr1976) wrote :

I have had the same issue after installing vpnc and network-manager-vpnc. Tried the fix by Patrick Healy - but it didn't help. Actually a reboot (first one after installing the packages mentioned before) did the trick (reverting the fix by Healy to the original), it even works with a root shell running.

Btw: Ubuntu 9.04
network-manager: 0.7.1~rc4.1.cf199a964-0ubuntu2
network-manager-vpnc: 0.7.1~rc4.20090316+bzr21-0ubuntu
Output of dpkg-query:
 /etc/dbus-1/system.d/nm-vpnc-service.conf fd1972dab1966261b4cc7aaa274d3e84
 /etc/NetworkManager/VPN/nm-vpnc-service.name da725da28b8e843fa6c32dde7a2b3851

Revision history for this message
C. Michael Pilato (cmpilato) wrote :

I can confirm the problem after an upgrade from 8.04. I can also confirm that Patrick Healy's fix solves the problem for me. Yay!

Revision history for this message
Dominic Sacré (dooooomi) wrote :

I also saw this problem, but it seems all I had to do was reboot after installing the network-manager-vpnc package. No at_console "fix" needed.

Revision history for this message
jan2ary (jan2ary) wrote :

Reboot after installing of network-manager-vpnc is a workaround and works.

Revision history for this message
eventhorizon (eventhorizon42) wrote :

Confirm Problem and Patch from "Patrick Healy wrote on 2009-04-18".
Ubuntu 64 9.04

Revision history for this message
Chris Sherlock (ta-bu-shi-da-yu) wrote :

Alex said the following though:

"Also dont apply the none fix with at_console ... that really makes no sense and opens security issues for you. Dont spread that stuff around please."

If this works, why is this such a bad thing to do? What sort of security issues can this potentially cause? And if this isn't an acceptable workaround, what must we do to move this forward? (2nd time of asking)

Revision history for this message
Chris Sherlock (ta-bu-shi-da-yu) wrote :

I suppose I should have also added: What is at_console anyway? try as I might, I can't find any documentation on this. And yes, I did try google. :-)

Revision history for this message
Stephen Crowley (crow-crowlogic) wrote :

There is some information on at_console at
http://markmail.org/message/34mwbf6ozkuwb3o7

Also, more information in bug37181
athttps://bugs.launchpad.net/ubuntu/+source/dbus/+bug/37181

Revision history for this message
In , Chris (chris-redhat-bugs) wrote :

Description of problem:

Can't establish vpnc connection

Version-Release number of selected component (if applicable):

NetworkManager-vpnc-0.7.0.99-1.fc11.x86_64

How reproducible:

every time

Steps to Reproduce:
1. create vpnc connection
2. set shared secret (set to saved)
3. set user password to "Always Ask"

Actual results:

Fails to establish connection

Expected results:

Password prompt and connection succeeds

Additional info:

Jun 30 11:07:26 x200 NetworkManager: <info> Starting VPN service 'org.freedesktop.NetworkManager.vpnc'...
Jun 30 11:07:26 x200 NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.vpnc' started (org.freedesktop.NetworkManager.vpnc), PID 14089
Jun 30 11:07:26 x200 NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.vpnc' just appeared, activating connections
Jun 30 11:07:26 x200 dbus: Rejected send message, 1 matched rules; type="method_call", sender=":1.8" (uid=0 pid=1877 comm="NetworkManager --pid-file=/var/run/NetworkManager/") interface="org.freedesktop.NetworkManager.VPN.Plugin" member="NeedSecrets" error name="(unset)" requested_reply=0 destination="org.freedesktop.NetworkManager.vpnc" (uid=0 pid=14089 comm="/usr/libexec/nm-vpnc-service "))
Jun 30 11:07:26 x200 NetworkManager: nm-vpn-connection.c.900: NeedSecrets failed: dbus-glib-error-quark Rejected send message, 1 matched rules; type="method_call", sender=":1.8" (uid=0 pid=1877 comm="NetworkManager --pid-file=/var/run/NetworkManager/") interface="org.freedesktop.NetworkManager.VPN.Plugin" member="NeedSecrets" error name="(unset)" requested_reply=0 destination="org.freedesktop.NetworkManager.vpnc" (uid=0 pid=14089 comm="/usr/libexec/nm-vpnc-service "))
Jun 30 11:07:26 x200 dbus: Rejected send message, 1 matched rules; type="method_call", sender=":1.8" (uid=0 pid=1877 comm="NetworkManager --pid-file=/var/run/NetworkManager/") interface="org.freedesktop.NetworkManager.VPN.Plugin" member="Disconnect" error name="(unset)" requested_reply=0 destination="org.freedesktop.NetworkManager.vpnc" (uid=0 pid=14089 comm="/usr/libexec/nm-vpnc-service "))
Jun 30 11:07:26 x200 NetworkManager: <WARN> connection_state_changed(): Rejected send message, 1 matched rules; type="method_call", sender=":1.8" (uid=0 pid=1877 comm="NetworkManager --pid-file=/var/run/NetworkManager/") interface="org.freedesktop.NetworkManager.VPN.Plugin" member="Disconnect" error name="(unset)" requested_reply=0 destination="org.freedesktop.NetworkManager.vpnc" (uid=0 pid=14089 comm="/usr/libexec/nm-vpnc-service "))
Jun 30 11:07:26 x200 NetworkManager: <info> Policy set 'Auto sequoia' (wlan0) as default for routing and DNS.

Revision history for this message
In , Steven (steven-redhat-bugs) wrote :

I have similar messages for NetworkManager-pptp-0.7.0.99-1.fc11.i586

Jul 7 11:22:40 steveslaptop NetworkManager: <info> Starting VPN service 'org.freedesktop.NetworkManager.pptp'...
Jul 7 11:22:40 steveslaptop NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.pptp' started (org.freedesktop.NetworkManager.pptp), PID 6858
Jul 7 11:22:40 steveslaptop NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.pptp' just appeared, activating connections
Jul 7 11:22:40 steveslaptop dbus: Rejected send message, 1 matched rules; type="method_call", sender=":1.8" (uid=0 pid=1761 comm="NetworkManager --pid-file=/var/run/NetworkManager/") interface="org.freedesktop.NetworkManager.VPN.Plugin" member="NeedSecrets" error name="(unset)" requested_reply=0 destination="org.freedesktop.NetworkManager.pptp" (uid=0 pid=6858 comm="/usr/libexec/nm-pptp-service "))
Jul 7 11:22:40 steveslaptop NetworkManager: nm-vpn-connection.c.900: NeedSecrets failed: dbus-glib-error-quark Rejected send message, 1 matched rules; type="method_call", sender=":1.8" (uid=0 pid=1761 comm="NetworkManager --pid-file=/var/run/NetworkManager/") interface="org.freedesktop.NetworkManager.VPN.Plugin" member="NeedSecrets" error name="(unset)" requested_reply=0 destination="org.freedesktop.NetworkManager.pptp" (uid=0 pid=6858 comm="/usr/libexec/nm-pptp-service "))
Jul 7 11:22:40 steveslaptop dbus: Rejected send message, 1 matched rules; type="method_call", sender=":1.8" (uid=0 pid=1761 comm="NetworkManager --pid-file=/var/run/NetworkManager/") interface="org.freedesktop.NetworkManager.VPN.Plugin" member="Disconnect" error name="(unset)" requested_reply=0 destination="org.freedesktop.NetworkManager.pptp" (uid=0 pid=6858 comm="/usr/libexec/nm-pptp-service "))
Jul 7 11:22:40 steveslaptop NetworkManager: <WARN> connection_state_changed(): Rejected send message, 1 matched rules; type="method_call", sender=":1.8" (uid=0 pid=1761 comm="NetworkManager --pid-file=/var/run/NetworkManager/") interface="org.freedesktop.NetworkManager.VPN.Plugin" member="Disconnect" error name="(unset)" requested_reply=0 destination="org.freedesktop.NetworkManager.pptp" (uid=0 pid=6858 comm="/usr/libexec/nm-pptp-service "))

Note, the NetworkManager gnome app didn't ask for me to save secrets or anything.

Revision history for this message
In , Steven (steven-redhat-bugs) wrote :

From another network, the vpn connection works without a problem, so maybe it's simply an issue with testing the VPN from the network you're trying to connect to.

The error message certainly is useless however. In my case, the error only appears in /var/log/messages, there were no visual indications from the UI that the connection was even attempted or failed.

Revision history for this message
Greg Smith (gsmith-gregsmith) wrote :

My experience on my up to date Jaunty system matches that of #23 from Mike Crowe. After installing network-manager-openvpn I initially got "VPN Connection failed because there were no valid VPN secrets" back from the GUI. After playing with the password settings to try and work around that, the connection attempts just quietly failed with "NetworkManager: nm-vpn-connection.c.900: NeedSecrets failed" in the daemon.log.

All I had to do was reboot in order to fix this. After that, I got the "Allow application access to keyring?" prompt I remembered from the last system where this worked properly, and then everything worked fine. So for the network-manager-openvpn incarnation of this problem at least, a reboot seems the first thing to try after setting things up if the connection fails with a NeedSecrets failure.

Revision history for this message
richardh (r-hayden) wrote :

Can confirm my experience also matches #23 and #48 on up-to-date 9.04. This time with network-manager-pptp.

I installed the plugin, configured the connection, tried to connect and got the "no valid secrets" GUI message. Rebooted after reading this and then on connection got the keyring message and everything was fine.

Revision history for this message
Jan Tiedemann (aeonspire) wrote :

Can confirm bug and fix on up-to-date Jaunty 64-bit and network-manager-vpnc.
However I did not reboot before applying the fix, only after - so could also be fixed by that.

Revision history for this message
Hrunting (ubuntu-hrunting) wrote :

I have this same problem with Jaunty 64-bit and a new PPTP connection. I did not have it available for all users. I fixed it by restarting NetworkManager. It seems that NetworkManager either doesn't recognize with the PPTP NM plugin gets installed or when a new connection is configured.

Revision history for this message
Katy Levinson (katylevinson) wrote :

I'm another user who just restarted and it worked.

Revision history for this message
LCID Fire (lcid-fire) wrote :

Same here - restarting got me to the keyring dialog.

Revision history for this message
Brendan Braybrook (brendan-ming) wrote :

note on workaround:

it seems that you must reboot, then not start any root session (ie "sudo bash"). something about having a root shell spawned before network manager runs (even if the root shell no longer exists) triggers the problem.

Revision history for this message
Alexander Sack (asac) wrote : Re: [Bug 360818] Re: NetworkManager.vpn fails -- nm-vpn-connection.c.900: NeedSecrets

On Thu, Oct 01, 2009 at 08:23:53PM -0000, Brendan Braybrook wrote:
> note on workaround:
>
> it seems that you must reboot, then not start any root session (ie "sudo
> bash"). something about having a root shell spawned before network
> manager runs (even if the root shell no longer exists) triggers the
> problem.

Would be great if you could track down what is creating a root and
doesnt set it free for you.

 - Alexander

Revision history for this message
In , Michael (michael-redhat-bugs) wrote :
Revision history for this message
Michael (michaeljt) wrote :

"Me too". Karmic beta, fully up-to-date. Trying to connect using network-manager-vpnc, the message is that the "VPN service stopped unexpectedly".

I installed yesterday, and yesterday a reboot fixed the problem. From yesterday, I have a number of messages in auth.log as follows:

{{{
Oct 6 15:51:13 michael-laptop dbus-daemon: Rejected send message, 1 matched rules; type="method_call", sender=":1.4" (uid=0 pid=986 comm="NetworkManager) interface="org.freedesktop.NetworkManager.VPN.Plugin" member="NeedSecrets" error name="(unset)" requested_reply=0 destination="org.freedesktop.NetworkManager.vpnc" (uid=0 pid=2858 comm="/usr/lib/network-manager-vpnc/nm-vpnc-service))
Oct 6 15:51:13 michael-laptop dbus-daemon: Rejected send message, 1 matched rules; type="method_call", sender=":1.4" (uid=0 pid=986 comm="NetworkManager) interface="org.freedesktop.NetworkManager.VPN.Plugin" member="Disconnect" error name="(unset)" requested_reply=0 destination="org.freedesktop.NetworkManager.vpnc" (uid=0 pid=2858 comm="/usr/lib/network-manager-vpnc/nm-vpnc-service))
}}}

Today I am unable to connect with the same bubble message, but nothing in auth.log. Today, I have messages in daemon.log like the following:

{{{
Oct 7 11:41:53 michael-laptop NetworkManager: <info> Starting VPN service 'org.freedesktop.NetworkManager.vpnc'...
Oct 7 11:41:53 michael-laptop NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.vpnc' started (org.freedesktop.NetworkManager.vpnc), PID 1944
Oct 7 11:41:53 michael-laptop NetworkManager: <WARN> vpn_service_watch_cb(): VPN service 'org.freedesktop.NetworkManager.vpnc' exited with error: 1
Oct 7 11:41:53 michael-laptop NetworkManager: <info> (wlan0): writing resolv.conf to /sbin/resolvconf
Oct 7 11:41:53 michael-laptop NetworkManager: <info> Policy set 'Auto fritz.box' (wlan0) as default for routing and DNS.
Oct 7 11:41:59 michael-laptop NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.vpnc' did not start in time, cancelling connections
}}}

I couldn't find any root shells, and the at_console thing didn't help either. I got messages like the above both before and after applying the at_console patch and rebooting.

Revision history for this message
In , Dan (dan-redhat-bugs) wrote :

Looks more like dbus permissions issues, what version of dbus does everyone have installed?

Revision history for this message
Alexander Sack (asac) wrote :

On Wed, Oct 07, 2009 at 09:50:50AM -0000, Michael wrote:
>
> Today I am unable to connect with the same bubble message, but nothing
> in auth.log. Today, I have messages in daemon.log like the following:
>
> {{{
> Oct 7 11:41:53 michael-laptop NetworkManager: <info> Starting VPN service 'org.freedesktop.NetworkManager.vpnc'...
> Oct 7 11:41:53 michael-laptop NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.vpnc' started (org.freedesktop.NetworkManager.vpnc), PID 1944
> Oct 7 11:41:53 michael-laptop NetworkManager: <WARN> vpn_service_watch_cb(): VPN service 'org.freedesktop.NetworkManager.vpnc' exited with error: 1
> Oct 7 11:41:53 michael-laptop NetworkManager: <info> (wlan0): writing resolv.conf to /sbin/resolvconf
> Oct 7 11:41:53 michael-laptop NetworkManager: <info> Policy set 'Auto fritz.box' (wlan0) as default for routing and DNS.
> Oct 7 11:41:59 michael-laptop NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.vpnc' did not start in time, cancelling connections
> }}}
>
> I couldn't find any root shells, and the at_console thing didn't help
> either. I got messages like the above both before and after applying
> the at_console patch and rebooting.
>

This looks a different/new bug. could you open one and give us that id?

 - Alexander

Revision history for this message
Alexander Sack (asac) wrote :

if you said that it wasnt fixed in latest karmic and you run amd64 (e.g. 64-bit), then please try to upgrade again. the package got stuck somewhere, so you probably didnt test what i wanted you to test. Thanks for reconfirming.

Revision history for this message
Michael (michaeljt) wrote :

Sorry for not responding, I obviously failed to register for notifications on this bug. I just wanted to add that after yesterdays update to networkmanager-vpnc I had no problems connecting this morning. If problems do reappear I will comment again, otherwise assume that they are gone. Thanks for your time and effort!

Revision history for this message
David (idht4n) wrote :

I'm fully up to date on Mythbuntu 9.10 beta and seeing the "there were no valid VPN secrets" message. I think I have the same NM setup as my fedora rawhide configuration that works.

Revision history for this message
Alexander Sack (asac) wrote :

david, what versions do you have? for nm and nm-vpnc and applet?

Revision history for this message
Alexander Sack (asac) wrote :

anyway. i dont see how the initial bug cannot be fixed now in karmic. even if not the code is different enough to justify a new bug. If you still get this with a up-to-date karmic pristine install, please open a new bug and drop your bug id here.

Changed in network-manager-vpnc (Ubuntu):
status: In Progress → Fix Released
Revision history for this message
Valentijn Sessink (valentijn) wrote :

Karmic, updated from Jaunty; in Jaunty, a working VPN, in Karmic, my auth.log says:
Oct 19 14:15:53 abrikoos dbus-daemon: Rejected send message, 3 matched rules; type="method_call", sender=":1.52" (uid=1001 pid=2332 comm="/usr/lib/indicator-messages/indicator-messages-ser") interface="org.freedesktop.DBus.Introspectable" member="Introspect" error name="(unset)" requested_reply=0 destination=":1.72" (uid=0 pid=3079 comm="/usr/lib/network-manager-openvpn/nm-openvpn-servic"))

Unfortunately, at this moment, no time to investigate.

Revision history for this message
In , Chris (chris-redhat-bugs) wrote :

$ rpm -q dbus
dbus-1.2.12-2.fc11.x86_64

$ rpm -qa | grep NetworkManager
NetworkManager-vpnc-0.7.0.99-1.fc11.x86_64
NetworkManager-gnome-0.7.1-8.git20090708.fc11.x86_64
NetworkManager-glib-0.7.1-8.git20090708.fc11.x86_64
NetworkManager-0.7.1-8.git20090708.fc11.x86_64

I just randomly tried this again...it's working fine now.

Revision history for this message
KillerKiwi (killerkiwi2005) wrote :

Getting this error which looks like the same issue

Oct 28 09:44:04 jason-laptop NetworkManager: nm-vpn-connection.c.828: NeedSecrets failed: dbus-glib-error-quark Rejected send message, 1 matched rules; type="method_call", sender=":1.4" (uid=0 pid=1090 comm="NetworkManager) interface="org.freedesktop.NetworkManager.VPN.Plugin" member="NeedSecrets" error name="(unset)" requested_reply=0 destination="org.freedesktop.NetworkManager.pptp" (uid=0 pid=3917 comm="/usr/lib/network-manager-pptp/nm-pptp-service))

Revision history for this message
Ivars Strazdiņš (ivars-strazdins) wrote :

I confirm with another one:

Oct 28 14:45:35 kurmis NetworkManager: nm-vpn-connection.c.828: NeedSecrets failed: dbus-glib-error-quark Rejected send message, 1 matched rules; type="method_call", sender=":1.5" (uid=0 pid=1109 comm="NetworkManager) interface="org.freedesktop.NetworkManager.VPN.Plugin" member="NeedSecrets" error name="(unset)" requested_reply=0 destination="org.freedesktop.NetworkManager.openvpn" (uid=0 pid=19312 comm="/usr/lib/network-manager-openvpn/nm-openvpn-servic"))
Oct 28 14:45:35 kurmis NetworkManager: <WARN> connection_state_changed(): Rejected send message, 1 matched rules; type="method_call", sender=":1.5" (uid=0 pid=1109 comm="NetworkManager) interface="org.freedesktop.NetworkManager.VPN.Plugin" member="Disconnect" error name="(unset)" requested_reply=0 destination="org.freedesktop.NetworkManager.openvpn" (uid=0 pid=19312 comm="/usr/lib/network-manager-openvpn/nm-openvpn-servic"))

Revision history for this message
Chris Sherlock (ta-bu-shi-da-yu) wrote : Re: [Bug 360818] Re: NetworkManager.vpn fails -- nm-vpn-connection.c.900: NeedSecrets

I'm getting:

Oct 28 23:59:07 ubuntu dbus-daemon: Rejected send message, 1 matched rules;
type="method_call", sender=":1.36" (uid=1000 pid=3994
comm="/usr/lib/indicator-applet/indicator-applet --oaf-a")
interface="org.freedesktop.DBus.Properties" member="Get" error
name="(unset)" requested_reply=0 destination=":1.98" (uid=0 pid=14625
comm="/usr/lib/network-manager-vpnc/nm-vpnc-service "))

2009/10/28 Ivars Strazdiņš <email address hidden>

> I confirm with another one:
>
> Oct 28 14:45:35 kurmis NetworkManager: nm-vpn-connection.c.828: NeedSecrets
> failed: dbus-glib-error-quark Rejected send message, 1 matched rules;
> type="method_call", sender=":1.5" (uid=0 pid=1109 comm="NetworkManager)
> interface="org.freedesktop.NetworkManager.VPN.Plugin" member="NeedSecrets"
> error name="(unset)" requested_reply=0
> destination="org.freedesktop.NetworkManager.openvpn" (uid=0 pid=19312
> comm="/usr/lib/network-manager-openvpn/nm-openvpn-servic"))
> Oct 28 14:45:35 kurmis NetworkManager: <WARN> connection_state_changed():
> Rejected send message, 1 matched rules; type="method_call", sender=":1.5"
> (uid=0 pid=1109 comm="NetworkManager)
> interface="org.freedesktop.NetworkManager.VPN.Plugin" member="Disconnect"
> error name="(unset)" requested_reply=0
> destination="org.freedesktop.NetworkManager.openvpn" (uid=0 pid=19312
> comm="/usr/lib/network-manager-openvpn/nm-openvpn-servic"))
>
> --
> NetworkManager.vpn fails -- nm-vpn-connection.c.900: NeedSecrets
> https://bugs.launchpad.net/bugs/360818
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Revision history for this message
Alexander Sack (asac) wrote : Re: [Bug 360818] Re: NetworkManager.vpn fails -- nm-vpn-connection.c.900: NeedSecrets

On Tue, Oct 27, 2009 at 08:50:25PM -0000, KillerKiwi wrote:
> Getting this error which looks like the same issue
>
> Oct 28 09:44:04 jason-laptop NetworkManager: nm-vpn-connection.c.828:
> NeedSecrets failed: dbus-glib-error-quark Rejected send message, 1
> matched rules; type="method_call", sender=":1.4" (uid=0 pid=1090
> comm="NetworkManager)
> interface="org.freedesktop.NetworkManager.VPN.Plugin"
> member="NeedSecrets" error name="(unset)" requested_reply=0
> destination="org.freedesktop.NetworkManager.pptp" (uid=0 pid=3917
> comm="/usr/lib/network-manager-pptp/nm-pptp-service))

do you use "available to all user" connections? Try to uncheck that.

 - Alexander

Revision history for this message
Laurent Bigonville (bigon) wrote :

I still get that bug on karmic with openvpn connections...

Changed in network-manager-openvpn (Ubuntu):
importance: Undecided → Medium
Revision history for this message
Niall Brosnan (niallb) wrote :

I am seeing it on a fresh install of Karmic with openvpn configuration from Jaunty.
Recreating the connection with my original keys makes no difference.

Adding at_console permissions to /etc/dbus-1/system.d/nm-openvpn-service.conf
 as described above by Patrick Healy for vpnc on 2009-04-18 fixes the issue for me for now.

His solution for vpnc applied to openvpn followed by a restart removed the problem.
A new bug has been opened specifically for openvpn in karmic as bug number 453807,
but it appears to be the same behaviour whichever vpn plugin is in use.

I believe that this patch was backed out as an insecure fix, but can't find the correct fix just now,
so forgive me for posting unprepared - I just needed my connections back up asap.

Revision history for this message
lagwagon667 (david-rummel-deactivatedaccount) wrote :

Hi, I had the same issues as Niall. In my case my existing openvpn connection from Jaunty stopped working throwing the "No valid VPN secret" message in the syslog. Also tried to create a new connection using the same settings but that also didn't fix the issue. Can confirm, that Patrick Healy's workaround, adding at_console permissions to /etc/dbus-1/system.d/nm-openvpn-service.conf fixed the issue for me, now.

Revision history for this message
Marco (marcodefreitas) wrote :

9.10 upgraded form 9.04 has the same problem with PPPoE connections. Fresh install stills the same:

pppd[2291]: pppd 2.4.5 started by root, uid 0
pppd[2291]: PPP session is 4346
pppd[2291]: Connected to 00:90:1a:42:90:c9 via interface eth0
pppd[2291]: Using interface ppp0
pppd[2291]: Connect: ppp0 <--> eth0
NetworkManager: SCPlugin-Ifupdown: devices added (path: /sys/devices/virtual/net/ppp0, iface: ppp0)
NetworkManager: SCPlugin-Ifupdown: device added (path: /sys/devices/virtual/net/ppp0, iface: ppp0): no ifupdown configuration found.
NetworkManager: <WARN> pppd_timed_out(): Looks like pppd didn't initialize our dbus module
NetworkManager: <info> (eth0): device state change: 7 -> 9 (reason 14)
NetworkManager: <info> Marking connection 'Connection DSL 1' invalid.
NetworkManager: <info> Activation (eth0) failed.
NetworkManager: <info> (eth0): device state change: 9 -> 3 (reason 0)
NetworkManager: <info> (eth0): deactivating device (reason: 0).
NetworkManager: <debug> [1257103303.002323] ensure_killed(): waiting for ppp pid 2291 to exit
NetworkManager: <debug> [1257103303.041718] ensure_killed(): ppp pid 2291 cleaned up
NetworkManager: SCPlugin-Ifupdown: devices removed (path: /sys/devices/virtual/net/ppp0, iface: ppp0)
NetworkManager: <info> Activation (eth0) starting connection 'Wired Connection 1'

I can only connect via pppoeconf.

I don't have a `/var/run/console/root' directory or file. I don't use sudo before connecting.

Revision history for this message
Michael Rooney (mrooney) wrote :

I can confirm the openvpn task as I hit this there. All I had to do was restart my machine and everything worked as expected, however.

Changed in network-manager-openvpn (Ubuntu):
status: New → Confirmed
Revision history for this message
In , Dan (dan-redhat-bugs) wrote :

If you'd just installed NM-vpnc or updated NM, there is a dbus bug that when a new permissions file gets dropped onto the disk, sometimes dbus needs a HUP before it'll recognize the new permissions. If you get this again, try a 'killall -HUP dbus-daemon' and then try the VPN again. Reopen if you see this again and the HUP doesn't work, thanks!

Revision history for this message
Alexander Sack (asac) wrote :

On Mon, Nov 02, 2009 at 06:12:05AM -0000, Michael Rooney wrote:
> I can confirm the openvpn task as I hit this there. All I had to do was
> restart my machine and everything worked as expected, however.

So ... you did this stop working again or did this go away completely?

 - Alexander

Revision history for this message
Michael Rooney (mrooney) wrote : Re: [Bug 360818] Re: NetworkManager.vpn fails -- nm-vpn-connection.c.900: NeedSecrets

On Mon, Nov 9, 2009 at 3:41 AM, Alexander Sack <email address hidden> wrote:
> So ... you did this stop working again or did this go away completely?

I have used it a bunch of times over the past week since, and haven't
encountered a single issue. It seems to only necessitate a single
restart somewhere along the line, either after installing the nm
plugin, importing the connection, or trying the first time.

Revision history for this message
Rene Jablonski (son-riab) wrote :

Hi Alexander!

I want to debug the openvpn plugin because of this bug: #453807 but i don't know exactly how! ^^
Can you please give me some hints how i could debug the plugin or the dbus on Karmic?

Revision history for this message
Chris Sherlock (ta-bu-shi-da-yu) wrote :

I would also be willing to do the same. What can I do to help get to the bottom of this matter? I have rebooted and this still isn't working for me.

Revision history for this message
n3m3s1s4u (n3m3s1s4u) wrote :

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?

Revision history for this message
Valentijn Sessink (valentijn) wrote :

Could some of you check your config file: does it have an IP address for "remote"? Or a host name?

My openvpn config is as follows: no password; single user (i.e. not for everyone); remote site is an IP address first (our office wifi is VPN protected), then a hostname (when I'm connected to the internet).

I still have problems setting it up, but those may be related to my DNS setup being flakey. I see that first the DNS is dropped by Networkmanager; then is complains that it can't connect - well, how could you, without DNS :)

Please note that the DNS problem itself is not related, that is due to a local problem. But the result of it (i.e. DNS changing, then OpenVPN kicking in) could be experienced by others. You may want to check.

Revision history for this message
Valentijn Sessink (valentijn) wrote :

Well, never mind my previous posting - DNS is not the problem.

Revision history for this message
Niall Brosnan (niallb) wrote :

Hi n3m3s1s4u .
You have posted the text from the previous fix too literally I think,
and as such you have fixed the problem for the vpnc plugin rather than the openvpn plugin.

Try this instead: the target file is /etc/dbus-1/system.d/nm-openvpn-service.conf

<!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.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"/>
 </policy>
</busconfig>

It has been working for me since release day. You will need to restart dbus etc, so a reboot may be simplest.

Revision history for this message
Laurent Bigonville (bigon) wrote :

Not sure this fix openvpn connection in 100% of the cases as I still get the "No VPN secrets!" error time to time

Revision history for this message
Rene Jablonski (son-riab) wrote :

For me this "fix" does not fix anything! That's why i am asking Alexander to give me some hints how to debug/help debugging the openvpn plugin!

Revision history for this message
Niall Brosnan (niallb) wrote :
Download full text (6.7 KiB)

I've just done a fresh install with network-manager-openvpn on a laptop.
Adding my keys to create a new connection fails with the Need Secrets message immediately after installation.

I can confirm a succesful connection after a reboot without applying the dbus patch I used on my other machines. I will post back if it fails for me at some point, but the most consistent element in the behaviour experienced by most of us is that a new nm openvpn configration does not work until after a reboot.
At this point the gnome keyring tool opens and asks to give access to the application.
I chose to allow it to remain authorised for future connections.

As I've now seen it work both with and without the dbus patch,
I must conclude that the dbus fix was coincidental with my reboot and of no inherent merit.

(/var/log/daemon.log for the failed connection before reboot)
Nov 12 16:42:43 mynetbook NetworkManager: user_connection_updated_cb: assertion `old_connection != NULL' failed
Nov 12 16:42:58 mynetbook NetworkManager: <info> Starting VPN service 'org.freedesktop.NetworkManager.openvpn'...
Nov 12 16:42:58 mynetbook NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.openvpn' started (org.freedesktop.NetworkManager.openvpn), PID 3539
Nov 12 16:42:58 mynetbook NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.openvpn' just appeared, activating connections
Nov 12 16:42:58 mynetbook NetworkManager: nm-vpn-connection.c.828: NeedSecrets failed: dbus-glib-error-quark Rejected send message, 1 matched rules; type="method_call", sender=":1.3" (uid=0 pid=751 comm="NetworkManager) interface="org.freedesktop.NetworkManager.VPN.Plugin" member="NeedSecrets" error name="(unset)" requested_reply=0 destination="org.freedesktop.NetworkManager.openvpn" (uid=0 pid=3539 comm="/usr/lib/network-manager-openvpn/nm-openvpn-servic"))
Nov 12 16:42:58 mynetbook NetworkManager: <WARN> connection_state_changed(): Rejected send message, 1 matched rules; type="method_call", sender=":1.3" (uid=0 pid=751 comm="NetworkManager) interface="org.freedesktop.NetworkManager.VPN.Plugin" member="Disconnect" error name="(unset)" requested_reply=0 destination="org.freedesktop.NetworkManager.openvpn" (uid=0 pid=3539 comm="/usr/lib/network-manager-openvpn/nm-openvpn-servic"))
Nov 12 16:42:58 mynetbook NetworkManager: <info> Policy set 'Auto WIFI' (wlan0) as default for routing and DNS.
Nov 12 16:43:11 mynetbook NetworkManager: <debug> [1258044191.000801] ensure_killed(): waiting for vpn service pid 3539 to exit
Nov 12 16:43:11 mynetbook NetworkManager: <debug> [1258044191.001142] ensure_killed(): vpn service pid 3539 cleaned up
=================================================================================

(/var/log/daemon.log output of the succesful connection:)
Nov 12 17:46:52 mynetbook NetworkManager: <info> Starting VPN service 'org.freedesktop.NetworkManager.openvpn'...
Nov 12 17:46:53 mynetbook NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.openvpn' started (org.freedesktop.NetworkManager.openvpn), PID 2325
Nov 12 17:46:53 mynetbook NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.openvpn' just appeared, activati...

Read more...

Revision history for this message
Alexander Sack (asac) wrote : Re: [Bug 360818] Re: NetworkManager.vpn fails -- nm-vpn-connection.c.900: NeedSecrets

On Thu, Nov 12, 2009 at 01:27:17PM -0000, Niall Brosnan wrote:
> Hi n3m3s1s4u .
> You have posted the text from the previous fix too literally I think,
> and as such you have fixed the problem for the vpnc plugin rather than the openvpn plugin.
>
> Try this instead: the target file is /etc/dbus-1/system.d/nm-openvpn-
> service.conf

at_console really is not sensible ... dont add that.

>
> It has been working for me since release day. You will need to restart dbus etc, so a reboot may be simplest.
>

I got more than one confirm that it works with just default ... can
you recheck that please?

 - Alexander

Revision history for this message
Alexander Sack (asac) wrote :

On Thu, Nov 12, 2009 at 03:52:08PM -0000, Rene Jablonski wrote:
> For me this "fix" does not fix anything! That's why i am asking
> Alexander to give me some hints how to debug/help debugging the openvpn
> plugin!
>

well ... i think it would be easiest if you get us steps to reproduce.

For instance, you could provide access to your openvpn net to me and I
can see if that triggers this issue ... jump into #nm channel on
freenode and ping me there if thats something you could do.

 - Alexander

Revision history for this message
Laurent Bigonville (bigon) wrote :

Well for me I only see that (IIRC) on an openvpn connection (tcp+lzo + TLS keys)

With another connection (UDP, login/password + TLS key) I don't remember having seen that error once

Revision history for this message
Rene Jablonski (son-riab) wrote :

I have the same error after a fresh installation of the openpvn plugin.

nm-vpn-connection.c.828: NeedSecrets failed: dbus-glib-error-quark
Rejected send message, 1 matched rules; type="method_call",
sender=":1.4" (uid=0 pid=991 comm="NetworkManager)
interface="org.freedesktop.NetworkManager.VPN.Plugin"
member="NeedSecrets" error name="(unset)" requested_reply=0
destination="org.freedesktop.NetworkManager.openvpn" (uid=0 pid=16481
comm="/usr/lib/network-manager-openvpn/nm-openvpn-servic"))

Looks like the same error but pay attention to the line.
vpnc: nm-vpn-connection.c.900
openvpn: nm-vpn-connection.c.828

After rebooting the only thing logged to syslog was

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

By the way, this is the way i use openvpn:

- authentication by certificates without a password for the keyfile
- lzo compression
- tun device
- udp
- rest -> default

Oh, i forgot: The vpnc-plugin is working without any problems!
I tried to find the error reported in the first post, but i can not find
it in syslog. I am using vpnc with an user and group password both
stored in the keyring. The rest are default values.

Alexander, i can not give you access to it, unfortunately. But using
openvpn in a terminal with a config file is working without problems.

- Rene

Revision history for this message
Niall Brosnan (niallb) wrote :

> I got more than one confirm that it works with just default ... can
> you recheck that please?
>
> - Alexander
Already confirmed in the post immediately before the one where you asked this.

To quote myself - (I know the post was long as I included logs, hoping they might be useful.)

As I've now seen it work both with and without the dbus patch,
I must conclude that the dbus fix was coincidental with my reboot and of no inherent merit.

Revision history for this message
Anton Lindström (hlewagastir) wrote :

This affect me too...

Tried reboot, does not help. Running Karmic, upgraded from Jaunty. Using OpenVPN. I've never tried setting this up before. Starting the VPN from console with
sudo /etc/init.d/openvpn start
works. I'd happily assist in any debugging...

Nov 14 01:40:00 localhost NetworkManager: <info> Starting VPN service 'org.freedesktop.NetworkManager.openvpn'...
Nov 14 01:40:00 localhost NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.openvpn' started (org.freedesktop.NetworkManager.openvpn), PID 2855
Nov 14 01:40:00 localhost NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.openvpn' just appeared, activating connections
Nov 14 01:40:00 localhost NetworkManager: <info> VPN plugin state changed: 1
Nov 14 01:40:00 localhost NetworkManager: <info> VPN plugin state changed: 3
Nov 14 01:40:00 localhost NetworkManager: <info> VPN connection 'LeChuck VPN-anslutning' (Connect) reply received.
Nov 14 01:40:00 localhost NetworkManager: <WARN> nm_vpn_connection_connect_cb(): VPN connection 'LeChuck VPN-anslutning' failed to connect: 'No VPN secrets!'.
Nov 14 01:40:00 localhost NetworkManager: <WARN> connection_state_changed(): Could not process the request because no VPN connection was active.
Nov 14 01:40:00 localhost NetworkManager: <info> Policy set 'Hemma' (eth1) as default for routing and DNS.

Revision history for this message
Nicolai_J. (fireandfuel) wrote :

I think the openvpn bugs should been detach from this vpnc bugs because it seems to be a absolutely different bug.

Revision history for this message
Andrew Daugherity (andrew-daugherity) wrote :

network-manager-openvpn was working fine under Jaunty, but since updating to Karmic it doesn't. However, I got the opposite behavior of the workaround listed -- with a root shell open, it connects properly; without one, it fails with the 'No VPN secrets!' error.

The at_console patch in #80 does fix it for me (after rebooting), but people say that's wrong...

network-manager-vpnc does exhibit the behavior described (connects w/o root shell, fails w/ a root shell), without any at_console entry in dbus, so it does appear that the openvpn issues are probably a separate bug.

Revision history for this message
Martin Konrad (info-martin-konrad) wrote :

I seems like this problem is already fixed upstream:

http://bugs.kde.org/show_bug.cgi?id=213900#c3

I gave it a try and recompiled plasma-widget-networkmanagement after applying this patch. This seems to fix the "No VPN secrets!" issue.

Here is what I did in detail:

apt-get source plasma-widget-networkmanagement
sudo apt-get build-dep plasma-widget-networkmanagement
cd plasma-widget-networkmanagement-0.9-svn1029786+ag1/
dpkg-buildpackage -rfakeroot -b
sudo dpkg -i ../plasma-widget-networkmanagement-0.9-svn1029786+ag1-0ubuntu1_amd64.deb

The bug is located in the code that saves the data from the widget. That's why you need to delete the config entries for all your openvpn connections and recreate them again after installing the fixed package!

Revision history for this message
Martin Konrad (info-martin-konrad) wrote :

If you tried the upstream patch and still experience problems please tell us how you configured Network Manager. Are you using KDE with plasma-widget-networkmanagement or Gnome?

Revision history for this message
zeke7237 (john-sort) wrote :

Just to further muddy the waters :)

I use openvpn, no private password. Been working pretty reliably on 8.10 and then 9.04 for a year. 9.10 was fine until most recent update, when no secrets problem popped up. I was studying the synaptic history to see if I could maybe guess which package broke things, and I noticed kernel updated. I had been on 2.6.28-16 (unintentionally, had set default to 2 in grub conf a while back and forgot to reset to 0). Today brought in 2.6.31-15, which pushed 2.6.31-14 to #2 and that's when things broke. I find that if I back down to 2.6.28-16 openvpn is back to normal (though sound is now broken)

Revision history for this message
falstaff (falstaff) wrote :

I first posted this accidently to a duplicate of this bug...

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...

Revision history for this message
BDenis (borenko) wrote :

I look at nm_setting_vpn_get_secret.

nm_setting_vpn_get_secret (NMSettingVPN *setting, const char *key)
{
 g_return_val_if_fail (NM_IS_SETTING_VPN (setting), NULL);

 return (const char *) g_hash_table_lookup (NM_SETTING_VPN_GET_PRIVATE (setting)->secrets, key);
}
It's return TRUE in one case, if setting->secrets has a key. NULL we can get in two cases, if 'settings' has a wrong type and if there is no key in 'settings -> secrets'. You say that setting already verified, than something wrong with settings -> secrets.

May be something wrong with rights when reading secrets?

Sorry for bad english.

Revision history for this message
Anton Lindström (hlewagastir) wrote :

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.

Revision history for this message
BDenis (borenko) wrote :

Thank you, Anton! It's really good workaround.

Revision history for this message
DavidW (d-david-w) wrote :

Anton, thank you very much! It's also working for me.

Revision history for this message
lagwagon667 (david-rummel-deactivatedaccount) wrote :

Works for me, too. Thanks Anton!

Revision history for this message
Paul Bußmann (paul-medwyn) wrote :

Thank you very much Anton! The workaround works.
It looks like the cause of the failure is still unknown. I'd like to help solving this issue. But how?

Revision history for this message
Marco Giorgetti (midimarcus) wrote :

Thank you Anton.
I've just made an attempt using your waorkaround and everthing went fine.
If other problems occur I'll add some comment here.

Revision history for this message
Morten Minke (morten-amagi) wrote :

The workaround which Anton describes works for me too.
Thanks Anton

Now the big question is, why is it working with wrong settings and not when everything is setup correctly!

Revision history for this message
bnight (bnight) wrote :

Hi,

I have Ubuntu 9.10 x64 with kde3 from ppd and have the same problem:

NetworkManager: nm-vpn-connection.c.828: NeedSecrets failed: dbus-glib-error-quark Invalid connection type.

I use:

ii network-manager-kde-kde3 1:0.8-0ubuntu12 KDE systray applet for controlling NetworkMa
ii network-manager-openvpn 0.8~a~git.20091008t123607.7c184a9-0ubuntu1 network management framework (OpenVPN plugin

This workaround dosn`t work for me.

Can someone help ?

Changed in network-manager-vpnc (Ubuntu):
status: Fix Released → Fix Committed
status: Fix Committed → Fix Released
Revision history for this message
Nicolai_J. (fireandfuel) wrote :

@bnight: KDE4 is installed by default under (K)Ubuntu 9.10.
KDE3 is not anymore supported under (K)Ubuntu 9.10.

Please update to KDE4!
Otherwise please write a new bug report (to distinguish, because it is a another bug)

Revision history for this message
bnight (bnight) wrote :

I know that KDE3 is not anymore supported.

But i don`t want to use KDE4.

What should i do to have this issue fixed i think that this is the same issue as the others but only that the workaround with +password don`t work.

Please told me what should i do to get this working.

It`s not a big issue after all because i connect with openvpn vpn.conf but i want to use NM for this one.

Thanks in advance for the support.

Revision history for this message
wasteinc (gravrainy) wrote :

antons workaround was a saver after weeks of furstration

kudos to anton

Revision history for this message
Martin Luder (maser) wrote :

Why has this fix only been released for vpnc, not openvpn?

Revision history for this message
wasteinc (gravrainy) wrote :

well I believe Anton's "fix" is not a fix but a workaround, and yes it works for openvpn

Revision history for this message
Pawel Foremski (pforemski) wrote :

Hi there,

Attached patch work-arounds the problem with OpenVPN.

Looking at the source, I'm puzzled, cos' line 1000 of Karmic Koalas nm-openvpn-service.c does validations of set #1 of parameters, whereas line 1004 does validation of set #2. The problem is that these sets are divergent, so either one doesnt provide any "secret parameters" (hence the "No VPN secrets!" error), or receives an error that such parameter is invalid.

I dont know if my reasoning is correct, I dont know why it worked intermittently - I just wanted my OpenVPN back :-) Please forward my remarks upstream if you find this helpful.

Pawel

Revision history for this message
Andreas Oberritter (mtdcr) wrote :

Can anyone confirm that this bug has actually been fixed in any version of network-manager-vpnc or in a related package? All I can see is that Ronan F marked this bug as fixed, but I fail to see any mention of the actual fix or version. Version 0.7.997 was released on 2009-12-08, but it doesn't seem to contain any obvious bugfixes related to this issue.

This bug hit me two times on karmic with OpenVPN during the last week and both times I went through the "edit connections" dialogue to select the same user certificate that has already been selected before. No other parameters were changed. After hitting "Apply" I was able to establish VPN connections again.

Could have been pure luck, though, taking into account all the other ways that seem to have helped other people.

Revision history for this message
Laurent Bigonville (bigon) wrote :

looks like pptp plugin is affected too:

Mar 16 11:16:03 valmar NetworkManager: <info> Starting VPN service 'org.freedesktop.NetworkManager.pptp'...
Mar 16 11:16:03 valmar NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.pptp' started (org.freedesktop.NetworkManager.pptp), PID 4556
Mar 16 11:16:03 valmar NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.pptp' just appeared, activating connections
Mar 16 11:16:03 valmar NetworkManager: nm-vpn-connection.c.828: NeedSecrets failed: dbus-glib-error-quark Rejected send message, 1 matched rules; type="method_call", sender=":1.2" (uid=0 pid=1114 comm="NetworkManager) interface="org.freedesktop.NetworkManager.VPN.Plugin" member="NeedSecrets" error name="(unset)" requested_reply=0 destination="org.freedesktop.NetworkManager.pptp" (uid=0 pid=4556 comm="/usr/lib/network-manager-pptp/nm-pptp-service))
Mar 16 11:16:03 valmar NetworkManager: <WARN> connection_state_changed(): Rejected send message, 1 matched rules; type="method_call", sender=":1.2" (uid=0 pid=1114 comm="NetworkManager) interface="org.freedesktop.NetworkManager.VPN.Plugin" member="Disconnect" error name="(unset)" requested_reply=0 destination="org.freedesktop.NetworkManager.pptp" (uid=0 pid=4556 comm="/usr/lib/network-manager-pptp/nm-pptp-service))

Janus (reslayer-mail)
tags: added: pptp
Revision history for this message
neilyalowitz (neilyalowitz) wrote :

After a reboot, vpnc works for me...

HOWEVER, the user/group password is randomly forgotten, even when the GUI option "Saved" is selected. "Ask every time" does not actually ask, ever. The only way to use the VPN connection after the passwords are randomly forgotten is to click "Configure VPN" and type the passwords again and set the dropdown to "Saved."

Retyping the passwords gets old quick, and I've seen this "NoSecrets" issue in Ubuntu for ages (multiple OS installs on different boxes, same problem).

Revision history for this message
segler (segler-alex) wrote :

this bug is still there in lucid

Revision history for this message
Niall Brosnan (niallb) wrote :

Have you rebooted yet?
Hopefully you've made no other changes, but if you've this issue on a fresh install of lucid,
I'd love to see if a single reboot fixes it (I suspect a restart of X/network-manager would).

Revision history for this message
Chris Sherlock (ta-bu-shi-da-yu) wrote : Re: [Bug 360818] Re: NetworkManager.vpn fails -- nm-vpn-connection.c.900: NeedSecrets

Sadly, I get the same error - and yes, I've rebooted.

On Sat, May 1, 2010 at 9:59 AM, Niall Brosnan
<email address hidden>wrote:

> Have you rebooted yet?
> Hopefully you've made no other changes, but if you've this issue on a fresh
> install of lucid,
> I'd love to see if a single reboot fixes it (I suspect a restart of
> X/network-manager would).
>
> --
> NetworkManager.vpn fails -- nm-vpn-connection.c.900: NeedSecrets
> https://bugs.launchpad.net/bugs/360818
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Revision history for this message
Chris D (cdekter) wrote :

Still broken in Lucid. Tested the fix by modifying /etc/dbus-1/system.d/nm-openvpn-service.conf and it works perfectly. This is a 4 line fix that has been tested and works - why has it not been implemented?

Revision history for this message
klap-in (klap-in) wrote :

I meet here the same problem of failing because no secrets (trying configuring and start directly after installing network-manager-vpnc). I reboot, next i have installed something using sudo apt-get install(and close the terminal after directly, so i don't know if maybe there was a sudo active), and then i tried again starting the vpn and it works fine. I will do more tests with new installations today, so when people have scenarios that must fail, i like to know to test these.

How can i guaranteed that i have a root shell open?

Revision history for this message
Philipp C. Heckel (binwiederhier) wrote :

I completely agree with Christiaan D in comment #117. The fix has been released over a year ago. It should have been added to the distro by now. Instead, the bug is still there in Lucid...

I confirm that it works perfectly when adding the "at_console" privileges like described by Patrick Healy in comment #3 (April 2009 !!)

Revision history for this message
dirk (dirk-kuijsten) wrote :

Still nothing happened. Same problem and fixed as in #117.
Even Micro$oft seems faster with fixing bugs compared to this bug. (maybe this comment will spur some action...)

Revision history for this message
Chris Sherlock (ta-bu-shi-da-yu) wrote :

You know, I cannot understand why anyone says that the patch produced in comment #3 works for folks. The syntax is totally wrong - it's at_console="true", not user="at_console".

I looked up what at_console does, and as it turns out at_console was originally created to use RedHat's pam_console... which of course is specific to RedHat. Ubuntu gets around this by using libpam-foreground, and from the following bug report at Debian http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=422349 I believe that there's been a patch done to dbus to get this working.

I guess my next question is: if you aren't using at_console (or pam_console, or pam_forground), then how does ConsoleKit do this?

Revision history for this message
Chris Sherlock (ta-bu-shi-da-yu) wrote :

OK, so I'm trying to work this out.

NeedSecrets - now correct me if I'm wrong here, but from what I've read while doing some research, this is an error that's occuring because network-manager can't get access to the relevant passwords for the VPN connection!

So in my travails into how it seems that NetworkManager does things (someone please pipe in here if I'm wrong), but this is how I understand that it works:

1. You bring up the network manager interface to connect to the VPN
2. nm then looks at gconf at System/Network/Connections/ and looks for the entry that matches the name, uuid and the service plugin name (?? is this right?)
3. It can then prompt for credentials, or it looks at Gnome-keyring.

So therefore, I guess that the following need to be checked:

1. Check what the uuid is for your VPN connection in gconf
2. Now go to Applications -> Accessories -> Passwords and Encryption Keys
3. Find the key for this connection (it should says something like "password for <VPN connection name>"

If you can't find it, then possibly there is something wrong with retrieving the secrets needed for the VPN?

Just a thought. If an nm person could chime in, that would be great :-) Hopefully I'm not misleading anyone! But this bug has been going on for a long time...

Revision history for this message
Chris Sherlock (ta-bu-shi-da-yu) wrote :

Alternatively... is it possible that it can't access the keyring?

Revision history for this message
Stephen Crowley (crow-crowlogic) wrote :

Not to toot my own horn, but I pointed out the solution to #3 in #24 and it worked for me. If you try making that change alone does it work?

Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

Anybody who still has this issue in Lucid, could you please open a new bug about it, preferably using the 'ubuntu-bug network-manager' command, so we can get full details of what is going on? Please make sure you add how you got that system to Lucid, that is, whether it was a clean install or an upgrade; and if it was an upgrade, from what other version of Ubuntu.

Chris, you pretty much got it right. The passwords currently saved for VPNs need to be verified. If there are some, you should be able to delete them for NM to ask about them again. Another thing to try could be to create a new user, and create the connection from scratch in that user to see if it can be completed.

As there is no patch attached that can reasonably and provably fix these issues (and given we've had multiple reports of this working properly in and after karmic), I've unsubscribed ubuntu-reviewers for now.

tags: added: patch
papukaija (papukaija)
tags: removed: networkmanager
Revision history for this message
Miguel Angel (mansuco-miguel) wrote :

This bug are too in Ubuntu 10.04 Lucid Lynx. This workaround works fine for me:

* Goto System -> Preferences -> Passwords and Encryption Keys.
* You must see the stored password for <Connection Name>/org.freedesktop.NetworkManager.vpnc/vpn.
* Right click -> Properties -> Applications tab.
* Check Permissions -> Read and Write.
* Close -> Close.
* Reboot.

Revision history for this message
cmnorton (octopusgrabbus) wrote :

I don't have

* Goto System -> Preferences -> Passwords and Encryption Keys.

My entry is encryption and keyrings, and my connection for VPN is not there. Is there a workaround?

Revision history for this message
cmnorton (octopusgrabbus) wrote :

Oh, and I am running 10.04 with latest patches.

Revision history for this message
Christian Jacobsen (cjacobsen) wrote :

Try with
Applications -> Accesories -> Passwords and Encryption Keys
There is a filter at the top to search for 'freedesktop'

Revision history for this message
cmnorton (octopusgrabbus) wrote :

I found the keys at Applications -> Accesories -> Passwords and Encryption Key, but there is no freedesktop there.

I did find my VPN connection that does not work -- same error "would not start", after setting the the read write privs.

Revision history for this message
Cd-MaN (panther79) wrote :

Hello everybody,

I can confirm that the problem still happens with 11.04, as follows:
- on first installation of network-manager-vpnc I can't connect to the VPN, and I get the error "Failed because there were no valid VPN secrets"
- after reboot it works

Explanation in commend #27 (bus policy changes only get applied after reboot in ubuntu) seems to make sense to me. This problem happened to me since 10.04 at least. network-manager-vpnc package version: 0.8.1+git.20110207t151002.6a2b2d6-0ubuntu2

Changed in network-manager-pptp (Ubuntu):
status: New → Confirmed
Revision history for this message
Nils J Steinsund (njsteinsund) wrote :

Hi!

Can confirm the reports of a reboot needed for this to work.

First setup of a VPN connection at all on a 11.04 install (Gnome 2.32.1 Classic)
- Installed the plugin for Cisco VPN: (this should really be better documented in the dialog box in Network Manager
sudo apt-get install network-manager-vpnc
- Imported my .pcf file with the Cisco VPN settings.
- Tried to connect and got the"Failed because there were no valid VPN secrets"
- Rebooted
- Tried to connect - works perfect!

Revision history for this message
cmnorton (octopusgrabbus) wrote :

I revisited this. I used Applications --> Accessories --> Passwords and Encryption keys. I see where a connection's read and write properties could be checked. However, my vpn connection is not present in this list. So, when created, it's never getting there. Any ideas on how to get it there by hand configuration?

So, obviously, this is still a bug for me.

Revision history for this message
cmnorton (octopusgrabbus) wrote :

Are there any workarounds for this? This is for 10.04 LTS.

Revision history for this message
ossjunkie (ossjunkie) wrote :

Solution for an update-to-date Ubuntu 10.04 is to reboot your machine after installing or importing your vpnc connection.

For adavanced users: Instead of rebooting you can also restart network-manager and the dbus daemon. The upstream author only recommends "killall -HUP dbus-daemon", but i haven't tested that.

Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

This has been covered for a long while now, and since (Oneiric, I think) you should no longer need to restart anything for the connection to be registered. If it still doesn't work, it would be a different bug.

A reboot is only required after *installing* the VPN, it doesn't need to be done for each new connection ;)

Please, if you're still getting this issue regardless of the version of Ubuntu in use, please file a *new*, *separate* bug report to make sure we can cover any possible case affecting you and really make sure *everything* is fixed. I'll close this bug report here as Fix Released since by and large this has already been covered in newer Ubuntu releases (it as the very least definitely works for me on a new install of the current development release).

Changed in network-manager-pptp (Ubuntu):
status: Confirmed → Fix Released
Changed in network-manager-openvpn (Ubuntu):
status: Confirmed → Fix Released
Changed in network-manager-openvpn (Ubuntu):
assignee: nobody → Martin Knudsen (proletar)
Changed in network-manager-openvpn (Fedora):
importance: Unknown → Medium
status: Unknown → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.