VPN connection fails: "unable to find valid VPN secrets" (auth dialog crash when secrets exist)

[Oren_B]

To verify, reproduce:

1. Run

   /usr/lib/network-manager-pptp/nm-pptp-auth-dialog -u 1234 -n lalala -s org.freedesktop.NetworkManager.pptp

2. Enter some password
3. Check 'remember password for this session'
4. Press 'Ok'
5. ^C the program because it doesn't close for some reason
6. Run it again
7. Watch it crash and burn

=====
Binary package hint: network-manager

I'm using intrepid beta.
I'm using a rather unique internet connection method, used only in Russia and Israel IIRC. I have a cable connection but I'm not connected to the internet all the time. On Windows have to use some kind of dialer, which actually makes a VPN connection. On Ubuntu I use the network manager to connect to the ISP VPN, after installing the packages pptp-linux and network-manager-pptp (I know very little about networks, I hope this description is informative enough and actually relevant :)
I updated my system this morning and after rebooting (there was also a kernel update) I can't connect to the VPN. I immediately get an error message that says something like "unable to find valid VPN secrets".
I'm posting this from windows so I can't check the exact error message of the version number of the package.

[petebach (peter-bache1)]

I get this too
connecting to a PPTP VPN server
Ubuntu 8.10
 uname -a
Linux ibm-laptop 2.6.27-7-generic #1 SMP Tue Oct 14 18:40:44 UTC 2008 i686 GNU/Linux

[anx (anx)]

i had this too on 8.10 after yesterdays patches.
 workaround for me by system -> encryption and keyrings, deleting the respective entrys and then connecting through the nm-widget. you'll be asked for the password, enter it and you should be fine. for now... dont save it to the keyring.
it seems that storing the password in the keyring is somehow broken, from the configure panel in network-manager as well as from the ad-hoc dialog from the widget.

[Oren_B (oren.barnea)]

Thanks anx, it works.

[Jaco (jacotb)]

A more simple workaround is just deleting the password from the nm-applet VPN connection editing dialog. It will ask for a password once connecting. Just don't save it to the keyring, and it will work.

[JazzyPenguin (jazzy-clarinet)]

I too have this same problem. Updated to release candidate today. VPN working under Hardy this morning, but getting error unable to find valid VPN secrets when attempting PPTP VPN using network-manager under intrepid. The workaround of deleting passward from connection information allows password to be entered during connection establishment and doing this a connection can be achieved - but a pain.

[Jonathan Harker (jonathanharker)]

Just updated to latest intrepid updates (network-manager-pptp 0.7~~svn20081015t024626-0ubuntu1) and I still can't connect to any of my previous PPTP VPNs, no matter what I do with the password. Output of /var/log/syslog says this when connecting with password stored in the config:

Oct 28 10:24:26 zmog NetworkManager: <info> Starting VPN service 'org.freedesktop.NetworkManager.pptp'...
Oct 28 10:24:26 zmog NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.pptp' started (org.freedesktop.NetworkManager.pptp), PID 16090
Oct 28 10:24:26 zmog NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.pptp' just appeared, activating connections
Oct 28 10:24:26 zmog NetworkManager: <WARN> get_secrets_cb(): Couldn't get connection secrets: vpn-password-dialog.c.299 (nma_vpn_request_password): canceled.
Oct 28 10:24:26 zmog NetworkManager: <info> Policy set 'Auto eth0' (eth0) as default for routing and DNS.
Oct 28 10:24:38 zmog NetworkManager: <debug> [1225142678.628389] ensure_killed(): waiting for vpn service pid 16090 to exit
Oct 28 10:24:38 zmog NetworkManager: <debug> [1225142678.628687] ensure_killed(): vpn service pid 16090 cleaned up

And this when typed into a dialog box, which looks like a CHAP auth failure, except it isn't because the same user/pass works in Hardy:

Oct 28 10:25:01 zmog NetworkManager: <info> Starting VPN service 'org.freedesktop.NetworkManager.pptp'...
Oct 28 10:25:01 zmog NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.pptp' started (org.freedesktop.NetworkManager.pptp), PID 16115
Oct 28 10:25:01 zmog NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.pptp' just appeared, activating connections
Oct 28 10:25:01 zmog NetworkManager: <info> VPN plugin state changed: 1
Oct 28 10:25:06 zmog NetworkManager: <info> VPN plugin state changed: 3
Oct 28 10:25:06 zmog NetworkManager: <info> VPN connection 'UCol' (Connect) reply received.
Oct 28 10:25:06 zmog pppd[16119]: Plugin /usr/lib/pppd/2.4.4/nm-pptp-pppd-plugin.so loaded.
Oct 28 10:25:07 zmog kernel: [36106.541213] PPP generic driver version 2.4.2
Oct 28 10:25:07 zmog pppd[16119]: pppd 2.4.4 started by root, uid 0
Oct 28 10:25:07 zmog pptp[16136]: nm-pptp-service-16115 log[main:pptp.c:314]: The synchronous pptp option is NOT activated
Oct 28 10:25:07 zmog pppd[16119]: Using interface ppp0
Oct 28 10:25:07 zmog pppd[16119]: Connect: ppp0 <--> /dev/pts/2
Oct 28 10:25:07 zmog pptp[16155]: nm-pptp-service-16115 log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 1 'Start-Control-Connection-Request'
Oct 28 10:25:07 zmog pptp[16155]: nm-pptp-service-16115 log[ctrlp_disp:pptp_ctrl.c:739]: Received Start Control Connection Reply
Oct 28 10:25:07 zmog pptp[16155]: nm-pptp-service-16115 log[ctrlp_disp:pptp_ctrl.c:773]: Client connection established.
Oct 28 10:25:08 zmog pptp[16155]: nm-pptp-service-16115 log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 7 'Outgoing-Call-Request'
Oct 28 10:25:08 zmog pptp[16155]: nm-pptp-service-16115 log[ctrlp_disp:pptp_ctrl.c:858]: Received Outgoing Call Reply.
Oct 28 10:25:08 zmog pptp[16155]: nm-pptp-service-16115 log[ctrlp_disp:pptp_ctrl.c:897]: Out...

[Oren_B (oren.barnea)]

Jonathan, that's the version of network-manager-pptp I have, and I'm able to connect (when entering a password manually). Try configuring a new connection, I think it will work. It did for me.

[Artem Popov (artfwo)]

It works when entering VPN password by hand indeed, but I think this bug is focused around the connection failure, after the password has been saved to the keyring.

I have a pretty complex VPN password, that I don't want to memorize and I have to manually copy-and-paste it from a plain text file. A very annoying issue, although everything worked flawlessy until around mid-october Intrepid updates...

[Marius Gedminas (mgedmin)]

Playing manually with the auth dialog:

1. Run

   /usr/lib/network-manager-pptp/nm-pptp-auth-dialog -u 1234 -n lalala -s org.freedesktop.NetworkManager.pptp

2. Enter some password
3. Check 'remember password for this session'
4. Press 'Ok'
5. ^C the program because it doesn't close for some reason
6. Run it again
7. Watch it crash and burn:

*** glibc detected *** /usr/lib/network-manager-pptp/nm-pptp-auth-dialog: free(): invalid pointer: 0xb6944060 ***
======= Backtrace: =========
/lib/tls/i686/cmov/libc.so.6[0xb71713f4]
/lib/tls/i686/cmov/libc.so.6(cfree+0x96)[0xb7173456]
/usr/lib/libglib-2.0.so.0(g_free+0x36)[0xb72bac06]
/usr/lib/network-manager-pptp/nm-pptp-auth-dialog[0x804a538]
/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe5)[0xb7118685]
/usr/lib/network-manager-pptp/nm-pptp-auth-dialog[0x804a251]
======= Memory map: ========
08048000-0804e000 r-xp 00000000 08:03 3784847 /usr/lib/network-manager-pptp/nm-pptp-auth-dialog
0804e000-0804f000 r--p 00005000 08:03 3784847 /usr/lib/network-manager-pptp/nm-pptp-auth-dialog
0804f000-08050000 rw-p 00006000 08:03 3784847 /usr/lib/network-manager-pptp/nm-pptp-auth-dialog
09a95000-09afa000 rw-p 09a95000 00:00 0 [heap]
b6800000-b6821000 rw-p b6800000 00:00 0
b6821000-b6900000 ---p b6821000 00:00 0
b6917000-b6924000 r-xp 00000000 08:03 1317361 /lib/libgcc_s.so.1
b6924000-b6925000 r--p 0000c000 08:03 1317361 /lib/libgcc_s.so.1
b6925000-b6926000 rw-p 0000d000 08:03 1317361 /lib/libgcc_s.so.1
b6943000-b6944000 rw-p b6943000 00:00 0
b6944000-b6948000 rw-p b6944000 00:00 0
b6948000-b694b000 r--p 00000000 08:03 317986 /usr/share/locale-langpack/lt/LC_MESSAGES/libbonobo-2.0.mo
b694b000-b6970000 r--p 00000000 08:03 315398 /usr/share/locale-langpack/lt/LC_MESSAGES/gtk20-properties.mo
b6970000-b6981000 r--p 00000000 08:03 317966 /usr/share/locale-langpack/lt/LC_MESSAGES/gtk20.mo
b6981000-b69c0000 r--p 00000000 08:03 215078 /usr/lib/locale/lt_LT.utf8/LC_CTYPE
b69c0000-b6aa1000 r--p 00000000 08:03 311807 /usr/lib/locale/lt_LT.utf8/LC_COLLATE
b6aa1000-b6aab000 r-xp 00000000 08:03 3686827 /lib/tls/i686/cmov/libnss_files-2.8.90.so
b6aab000-b6aac000 r--p 00009000 08:03 3686827 /lib/tls/i686/cmov/libnss_files-2.8.90.so
b6aac000-b6aad000 rw-p 0000a000 08:03 3686827 /lib/tls/i686/cmov/libnss_files-2.8.90.so
b6aad000-b6ab6000 r-xp 00000000 08:03 3686829 /lib/tls/i686/cmov/libnss_nis-2.8.90.so
b6ab6000-b6ab7000 r--p 00008000 08:03 3686829 /lib/tls/i686/cmov/libnss_nis-2.8.90.so
b6ab7000-b6ab8000 rw-p 00009000 08:03 3686829 /lib/tls/i686/cmov/libnss_nis-2.8.90.so
b6ab8000-b6abf000 r-xp 00000000 08:03 3686824 /lib/tls/i686/cmov/libnss_compat-2.8.90.so
b6abf000-b6ac0000 r--p 00006000 08:03 3686824 /lib/tls/i686/cmov/libnss_compat-2.8.90.so
b6ac0000-b6ac1000 rw-p 00007000 08:03 3686824 /lib/tls/i686/cmov/libnss_compat-2.8.90.so
b6ac1000-b6ac6000 rw-p b6ac1000 00:00 0
b6ac6000-b6ac9000 r-xp 00000000 08:03 4915432 /lib/libgpg-error.so.0.3.0
b6ac9000-b6aca000 rw-p 00002000 08:03 4915432 /lib/libgpg-error.so.0.3.0
b6aca000-b6b8d000 r-xp 00000000 08:03 164713 /usr/lib/libasound.so.2.0.0
b6b8d000-b6b8f000 r--p 000c2000 08:03 164713 /us...

[Marius Gedminas (mgedmin)]

Here's a patch that fixes the problem for me. It should be harmless: removing that g_free() doesn't leak memory because all memory is freed when the short-lived helper program exits.

[Ansus (neptunia)]

Have the same problem. Can't connect the Internet, using Windows instead.

[Alexander Sack (asac)]

marius, could you install the -dbgsym packages for network-manager libnm-util0 and libnm-glib0 and network-manager-pptp and then get the same backtrace you posted?

[Alexander Sack (asac)]

also, though i doubt that this bug is fixed there, you could test the latest NM pptp plugin for intrepid here: http://launchpad.net/~network-manager/+archive

[Andris Sprūds (aspruds)]

Hi, I just wanted to let you know that the latest network manager from "deb http://ppa.launchpad.net/network-manager/ubuntu intrepid main" still fails with "shared secrets" error if password is saved in the keyring.

[Alexander Sack (asac)]

Marius, I made a bug out of your crash: bug 292681!

[Alexander Sack (asac)]

OK, I uploaded a new package with a potential fix for bug 292681:

network-manager-pptp_0.7~~svn20081015t024626-0ubuntu2~nm3_source.changes

please test if that helps here (from http://launchpad.net/~network-manager/+archive PPA (intrepid)).

[Ansus (neptunia)]

Yes, now it remembers the password. But still cannot add routes to the connection properties.

[Alexander Sack (asac)]

ok, for -pptp the fix in PPA (from bug 291737) works. i will check whether the other plugins have a similar issue.

[Alexander Sack (asac)]

sorry. last one should have been bug 292681.

[Alexander Sack (asac)]

pptp fix committed in PPA with patch from bug 292681: http://launchpadlibrarian.net/19238751/keyring_memory_free.patch

[llevering (l-levering)]

I want to thank everybody who helped with a work-around and Alexander thank you for the fix! Any idea when the update will be distributed? If that will take weeks I will use the PPA, but if it is a matter of days I would rather just wait.

[Dmytro Korzhevin (korg)]

2 Alexander Sack

Hello!

Thanks for the fixed package. When this fixed package will be in Intrepid main or mabe in intrepid-proposed?

[Paul Elliott (omahn)]

The updated packages in the ppa also solve the issue for me. What's the delay in moving network-manager to intrepid-proposed for further testing?

[Ansus (neptunia)]

No interest, I think.

Volunteer and do it yourself.

[Jonathan Harker (jonathanharker)]

That's not very helpful - how does one go about doing it oneself?

[Jonathan Harker (jonathanharker)]

More importantly, why is there no interest, and who is it that is supposed to be interested anyway?

[Paul Elliott (omahn)]

I believe an unfortunately side effect of having PPAs is that people just add them to their systems and don't spend the time to have the issue resolved in the mainline distribution resulting in bugs like this becoming stalled.

Unfortunately I don't know the procedure to push this bug onwards otherwise I would do my best to assist. Although as Network Manager is such a fundamental piece of a Ubuntu system, I really believe that this should be done by someone within Canonical.

[Eric Buist (buisteric)]

I have the same problem, but even after I removed the password from the keys, it keeps failing to connect. It seems to fail the MS-CHAP authentication.
As I can understand from the last posts, there is no fix to be expected, because no one knows how to release it or wants to do it. I am more and more extremely disappointed by Ubuntu for this practice happening for juste EVERY bug. Using PPAs complicates things very much.

[Allochtoon (marcovd)]

Experiencing same bug, Intrepid. Testing out solutions.

Also, an option to resize the authentication methods should be mandatory.

[Davim (davim)]

why isn't the deb from the PPA pushed into intrepid-proposed?

[Alexander Sack (asac)]

initiating SRU for pptp part.

[Alexander Sack (asac)]

uploading network-manager-pptp_0.7~~svn20081015t024626-0ubuntu1.8.10.1_source.changes to ubuntu/intrepid-proposed

uploading network-manager-pptp_0.7~~svn20081015t024626-0ubuntu2_source.changes to ubuntu/jaunty

[Launchpad Janitor (janitor)]

This bug was fixed in the package network-manager-pptp - 0.7~~svn20081015t024626-0ubuntu2

---------------
network-manager-pptp (0.7~~svn20081015t024626-0ubuntu2) jaunty; urgency=low

  * LP: #259168 Network Manager unable to connect to PPTP VPN (bad NT-Domain
    escaping); we improve ppp domain in username encoding
    - add debian/patches/lp259168_ppp_nt_domain_escaping.patch
  * LP: #268667 MASTER - not all required ppp options get set on command line
    which makes ppp use bad values from /etc/ppp/options*; we explicitly set
    good values for: nodefaultroute, lcp-echo-failure and lcp-echo-interval
    - add debian/patches/lp268667_ppp_default_options.patch
  * LP: #292681 crash when running auth-dialog and secret in keyring;
    we use the proper memory functions in this patch (dupe-of LP: #284212
    VPN connection fails: "unable to find valid VPN secrets")
    - add debian/patches/lp_292681_keyring_memory_free.patch
  * LP: #290468 VPN fails, "/usr/bin/nm-ppp-starter missing"; we remove
    obsolete conffiles in .preinst now
    - add debian/network-manager-pptp.preinst

 -- Alexander Sack <email address hidden> Thu, 30 Oct 2008 00:22:51 +0100

[Martin Pitt (pitti)]

Accepted into intrepid-proposed, please test and give feedback here. Please see https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

[Ansus (neptunia)]

The issues discussed above work well.

Altough

* Does not set up routes for VPN. When entering they simply do not apper in the table of routes.

* Does not connect VPN on startup even with "Autoconnect" option enabled.

[llevering (l-levering)]

Before installing the update out of intrepid-backports, it still crashed.
After installing the update it works fine! Everyone who put effort into getting this bug sorted out: Thank you!

[Eric Buist (buisteric)]

The update has solved the password problem, but I still get a failed
connection with very few clues to debug further. The information put in
/var/log/syslog and /var/log/daemon is very sparse. It makes me believe
that the PPTP client of Linux is so incompatible with the Windows VPN
server that the server hangs up without notice; communication is really
impossible.
The only remaining hope is that the MTU and MRU are not properly set up.
My server requires them to be 1500 while the new PPTP client of Network
Manager does not let me alter this. Is there a way to force this MTU and
MRU at connexion time without bypassing Network Manager completely?
Eric

llevering a écrit :
> Before installing the update out of intrepid-backports, it still crashed.
> After installing the update it works fine! Everyone who put effort into getting this bug sorted out: Thank you!
>
>

[Marius Gedminas (mgedmin)]

The old Network Manager PPTP plugin had a checkbox to enable pppd debugging output, so you had something to go on (not that it helped much).

Eric: have you tried enabling MPPE and requiring 128-bit keys? That's what solved my VPN connection problems.

[Alexander Sack (asac)]

Ansus:

* Does not set up routes for VPN. When entering they simply do not apper in the table of routes.
 -> different issue. we have a bug for route issues and VPN

* Does not connect VPN on startup even with "Autoconnect" option enabled.
 -> haven't heard of this one. Please file a new bug.

[Alexander Sack (asac)]

verified that -openvpn is affected too.

[Alexander Sack (asac)]

NM core seems not to have this issue.

[Launchpad Janitor (janitor)]

This bug was fixed in the package network-manager-pptp - 0.7~~svn20081015t024626-0ubuntu1.8.10.1

---------------
network-manager-pptp (0.7~~svn20081015t024626-0ubuntu1.8.10.1) intrepid-proposed; urgency=low

  * LP: #259168 Network Manager unable to connect to PPTP VPN (bad NT-Domain
    escaping); we improve ppp domain in username encoding
    - add debian/patches/lp259168_ppp_nt_domain_escaping.patch
  * LP: #268667 MASTER - not all required ppp options get set on command line
    which makes ppp use bad values from /etc/ppp/options*; we explicitly set
    good values for: nodefaultroute, lcp-echo-failure and lcp-echo-interval
    - add debian/patches/lp268667_ppp_default_options.patch
  * LP: #292681 crash when running auth-dialog and secret in keyring;
    we use the proper memory functions in this patch (dupe-of LP: #284212
    VPN connection fails: "unable to find valid VPN secrets")
    - add debian/patches/lp_292681_keyring_memory_free.patch
  * LP: #290468 VPN fails, "/usr/bin/nm-ppp-starter missing"; we remove
    obsolete conffiles in .preinst now
    - add debian/network-manager-pptp.preinst

 -- Alexander Sack <email address hidden> Thu, 30 Oct 2008 00:22:51 +0100

[Bryan McLellan (btm)]

Recent Ubuntu Intrepid 8.10 install (last week or so)

Installed network-manager-pptp
Created a PPTP Connection and entered the username and password
Connection failed as above due to "unable to find valid VPN secrets"

Upgraded network-manager-pptp to 0.7~~svn20081015t024626-0ubuntu1.8.10.1

Network Manager continued beyond the original failure point
Other problems are preventing a connection, but this bug appears to be fixed.

[Alexander Sack (asac)]

will upload openvpn fix to proposed tomorrow. sorry for the delay.

[Alexander Sack (asac)]

Bryan, do the PPA packages work for you?

[mvavrek (mattvavrek)]

I am unsure if this is the appropriate place to post, but I have encountered the same bug in Jaunty, even with up to date PPA packages. vpnc seems to work from the command line just fine, but the network manager applet continually gives a "The VPN connection 'XXXX' failed because there were no valid vpn secrets", despite using the exact same values.

[mvavrek (mattvavrek)]

Problem seems to have resolved itself after restart. Sorry about the above post.

[unggnu (unggnu)]

Seems to be still an issue in Jaunty with openvpn network manager plugin. Works fine with Hardy.

[Mariano Mara (marplatense)]

I'm with unggnu, previous openvpn connection in intrepid worked ok but with jaunty I'm getting "there were no valid VPN secrets". openvpn connects ok from command line.

[Adolfo R. Brandes (arbrandes)]

Confirmed on an up-to-date Jaunty; no secrets found. However, I'm using passworded certificates. Maybe that's the problem!

[Olaf (tholap)]

Just tried OpenVPN on Jaunty - no problem here.
NetworkManager with OpenVPN plugin
Type: Cerificates (TLS)
provided the 3 files for User, CA and Private Key, typed in my password
everything else left at default (will try setting routes sometime)
Worked out of the box (Jaunty upgraded from hardy after release)
No PPAs - everything (NM, plugin) from jaunty repo.

I can also confirm that the PPTP plugin works again with Jaunty (I skipped Intrepid because if this - gotta love live CDs :-) )

[unggnu (unggnu)]

I don't know what happened but suddenly it worked for me too some time ago without a configuration change. Maybe it was an update or server change.

[Oren_B (oren.barnea)]

I still have this problem after upgrading my machine to Ubuntu 9.04.
I don't have the OpenVPN plugin (I don't even know what it is :)

[Alexander Sack (asac)]

jaunty is out long enough, we won't put effort into fixing bugs in intrepid anymore - and hence risking regressions for those that are happy.

[Alexander Sack (asac)]

isnt this fixed in jaunty/karmic? if not, please reopen.

[Claudio Moretti (flyingstar16)]

No, sorry :( Can someone set this as triaged again? Appears I can't...

[houstonbofh (leesharp)]

Alexander Sack wrote:
> jaunty is out long enough, we won't put effort into fixing bugs in
> intrepid anymore - and hence risking regressions for those that are
> happy.
>
> ** Changed in: network-manager-openvpn (Ubuntu Intrepid)
> Status: Triaged => Won't Fix

This is one thing I never understood. The policy of leaving things
broken when there are known fixes is never something I can agree with in
a still "supported" release. If the fix is causing regressions, it is
also causing them in Jaunty and Karmic. If the fix requires a version
rev, and that is against policy, we need to have a method of exception
for that policy. But just leaving it broken really bothers me.

[Martin Pitt (pitti)]

houstonbofh [2009-07-09 12:18 -0000]:
> If the fix is causing regressions, it is also causing them in Jaunty
> and Karmic.

That's an invalid assumption, as reality has shown us. (See bug
207072, for example)

[Robert Buhren (weelkin)]

i'm still having this problem in jaunty. I'm connection toa openvpn server with certificates which don't have passwords.
Is there any workaround?

[eiver (eiver)]

I also have this problem, but only if I very quickly after startup try to connect to my VPN. After few failed attempts it will eventually succeed.

On the other hand if I wait a while after startup before connecting, then the first attempt will succeed.

Is something loading at startup and is required for the VPN connection?

[Michael Baudino (gornack)]

FYI, that bug suddenly happen on my jaunty box few days/weeks ago (maybe due to an upgrade cause there were no configuration change).
Simply deleting the password for the SSL private key in SeaHorse ("Applications" > "Accessories" > "Passwords and Encryption Keys") did the trick. Network Manager asked me for it again, and it worked.
Thanks to anx, for being the first to publish this workaround.

[Psy[H[] (vovik-wfa)]

Do not know if this is a same problem:
I am not able to save password in system-wide pptp connection, field remains blank.
NM does not ask for password when connecting, and there is an error in syslog:
nm_vpn_connection_connect_cb(): VPN connection 'VPN1' failed to connect: 'No VPN secrets!'

user-level connection works fine.

NM version: 0.8~a~git.20091008t231804.c31b3e4-0ubuntu1~nmt1

[unggnu (unggnu)]

The OpenVPN plugin seems to work fine in current Karmic. Can anyone confirm this?

[Psy[H[] (vovik-wfa)]

still have 'No VPN secrets!' for pptp, and password field is emptied in system connection

[Matthias Niess (mniess)]

In can confirm this doesn't work in karmic with the exact same settings I used in jaunty (where it worked). I also get "no VPN secrets" when connecting to an OpenVPN. cmdline client works fine.

If I use a connection with certificates and password, it works. If my certificates are not password-protected, it doesn't.

network-manager-openvpn: 0.8~a~git.20091008t123607.7c184a9-0ubuntu1
/var/log/syslog
<info> Starting VPN service 'org.freedesktop.NetworkManager.openvpn'...
<info> VPN service 'org.freedesktop.NetworkManager.openvpn' started (org.freedesktop.NetworkManager.openvpn), PID 2456
<info> VPN service 'org.freedesktop.NetworkManager.openvpn' just appeared, activating connections
<info> VPN plugin state changed: 1
<info> VPN plugin state changed: 3
<info> VPN connection 'MyVPN' (Connect) reply received.
<WARN> nm_vpn_connection_connect_cb(): VPN connection 'MyVPN' failed to connect: 'No VPN secrets!'.
<WARN> connection_state_changed(): Could not process the request because no VPN connection was active.
<info> Policy set 'Auto MyWIFI' (wlan0) as default for routing and DNS.
<debug> [1256208847.001481] ensure_killed(): waiting for vpn service pid 2456 to exit
<debug> [1256208847.001597] ensure_killed(): vpn service pid 2456 cleaned up

[Justin Slauson (justin-slauson)]

I am experiencing the same problem. The password does not get saved and it never asks when trying to connect. Syslog shows VPN connection 'VPN connection 1' failed to connect: 'No VPN secrets!'

[Justin Slauson (justin-slauson)]

OK. I got this to work. it seems that I only had to uncheck "Available to all users." and have the proper network items selected (i.e, no eap, use MPPE, 40-bit encryption, don't allow bsd compression, don't allow Deflate data compression) and it would then save the password into the keyring.

[Justin Slauson (justin-slauson)]

I never posted this, sorry. I'm using Ubuntu Karmic, fully updated.

[Mike (0x656b694d)]

Same problem here, but the solutions above don't help. openvpn works in command line just fine. I'm using the ultravnp.fr service with password authentication. 9.10 here, up to date.

[Martin Emrich (emme)]

@unggnu: I use the OpenVPN plugin on karmic i386 (including karmic-proposed), and I still see the problem. I click on an OpenVPN connection, and the notification immediately pops up with a message that the vpn service could not be started.

Sometimes it helps to try again several times, or to try again after a few minutes. Then the connection works fine. Smells like some race condition or timeout.

[Lando Nachtmann (lanna)]

I experience another variation of this problem:

My setup is: Karmic (i386 netbook remix, fresh install, fully updated), vpnc-plugin, password-based VPN (user and group passwords saved via network-manager)

- On first connection attempt after a boot everything is okay
- After a disconnect (manually or netbook goes asleep, does not matter) it will refuse to reconnect until I reboot the machine
In that case I get this 'No VPN secrets!' warning in syslog and all password fields in the network-manager GUI are empty. The passwords reappear after a reboot.

[Lando Nachtmann (lanna)]

Oh, I forgot to say that I never had a problem with Jaunty, though.

[Tom (tomko9)]

To those who have problems with private keys without password :

You can create new private key WITH password by running :

openssl rsa -in OLD_PRIVATE_KEY.key -des3 -out NEW_PRIVATE_KEY.key

You will ba asked for password , so enter something and remember( or write it down) .

Don't forget to do: chmod og-rwx NEW_PRIVATE_KEY.key or you will get warnings from openvpn .

In Openvpn config provide NEW_PRIVATE_KEY.key and password you entered .

Should work in all versions of Ubuntu .

[Clayton Kramer (clayton-kramer)]

Tom: Your private key password conversion tip rocks. Saved me a bunch of troubleshooting headaches and nudged me to be more secure with my keys. Thanks!

[drplix (pjr-1060)]

@Martin Emrich - I use Karmic x64 and see exactly the same issue "VPN could not be started".

As you say: "Sometimes it helps to try again several times, or to try again after a few minutes. Then the connection works fine. Smells like some race condition or timeout." This does work but it seems pretty random.

FYI I am trying to connect to an openvpn server. Eventually it works and I stay connected. Previously on Jaunty the VPN connection manager with the same settings was rock solid.

[Martin Emrich (emme)]

Yes, I am using OpenVPN, too. Adding bogus credentials fixes it for me, too.

[Andre Schild (andre-schild)]

I am using OpenVPN, too. Adding bogus credentials fixes it for me, too.

[cmnorton (octopusgrabbus)]

I am using 9.10 without the keyring. Here is my log trace. What can I do to get vpn working?

Dec 28 20:02:11 hiawatha NetworkManager: <info> Starting VPN service 'org.freedesktop.NetworkManager.pptp'...
Dec 28 20:02:11 hiawatha NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.pptp' started (org.freedesktop.NetworkManager.pptp), PID 25127
Dec 28 20:02:11 hiawatha NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.pptp' just appeared, activating connections
Dec 28 20:02:11 hiawatha NetworkManager: <info> VPN plugin state changed: 3
Dec 28 20:02:11 hiawatha NetworkManager: <info> VPN connection 'townofarlington' (Connect) reply received.
Dec 28 20:02:11 hiawatha NetworkManager: <WARN> nm_vpn_connection_connect_cb(): VPN connection 'townofarlington' failed to connect: 'No VPN secrets!'.
Dec 28 20:02:11 hiawatha NetworkManager: <WARN> connection_state_changed(): Could not process the request because no VPN connection was active.
Dec 28 20:02:11 hiawatha NetworkManager: <info> Policy set 'Auto MtLaughmore' (wlan0) as default for routing and DNS.
Dec 28 20:02:24 hiawatha NetworkManager: <debug> [1262048544.002732] ensure_killed(): waiting for vpn service pid 25127 to exit
Dec 28 20:02:24 hiawatha NetworkManager: <debug> [1262048544.002918] ensure_killed(): vpn service pid 25127 cleaned up
Dec 28 20:02:59 hiawatha NetworkManager: <info> Starting VPN service 'org.freedesktop.NetworkManager.pptp'...
Dec 28 20:02:59 hiawatha NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.pptp' started (org.freedesktop.NetworkManager.pptp), PID 28525
Dec 28 20:02:59 hiawatha NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.pptp' just appeared, activating connections
Dec 28 20:02:59 hiawatha NetworkManager: <info> VPN plugin state changed: 3
Dec 28 20:02:59 hiawatha NetworkManager: <info> VPN connection 'townofarlington' (Connect) reply received.
Dec 28 20:02:59 hiawatha NetworkManager: <WARN> nm_vpn_connection_connect_cb(): VPN connection 'townofarlington' failed to connect: 'No VPN secrets!'.
Dec 28 20:02:59 hiawatha NetworkManager: <WARN> connection_state_changed(): Could not process the request because no VPN connection was active.
Dec 28 20:02:59 hiawatha NetworkManager: <info> Policy set 'Auto MtLaughmore' (wlan0) as default for routing and DNS.
roo

[Sayantan Das (sayantan13)]

Thanks Justin,
 I have managed to go a little further with your ideas. But still I am not able to connect. Here is the log from syslog

Dec 30 21:51:04 sayantan-laptop NetworkManager: <info> Starting VPN service 'org.freedesktop.NetworkManager.pptp'...
Dec 30 21:51:04 sayantan-laptop NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.pptp' started (org.freedesktop.NetworkManager.pptp), PID 7427
Dec 30 21:51:04 sayantan-laptop NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.pptp' just appeared, activating connections
Dec 30 21:51:04 sayantan-laptop NetworkManager: <info> VPN plugin state changed: 3
Dec 30 21:51:04 sayantan-laptop NetworkManager: <info> VPN connection 'office' (Connect) reply received.
Dec 30 21:51:04 sayantan-laptop pptp[7432]: nm-pptp-service-7427 log[main:pptp.c:314]: The synchronous pptp option is NOT activated
Dec 30 21:51:04 sayantan-laptop NetworkManager: SCPlugin-Ifupdown: devices added (path: /sys/devices/virtual/net/ppp0, iface: ppp0)
Dec 30 21:51:04 sayantan-laptop NetworkManager: SCPlugin-Ifupdown: device added (path: /sys/devices/virtual/net/ppp0, iface: ppp0): no ifupdown configuration found.
Dec 30 21:51:05 sayantan-laptop pptp[7438]: nm-pptp-service-7427 log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 1 'Start-Control-Connection-Request'
Dec 30 21:51:05 sayantan-laptop pptp[7438]: nm-pptp-service-7427 log[ctrlp_disp:pptp_ctrl.c:739]: Received Start Control Connection Reply
Dec 30 21:51:05 sayantan-laptop pptp[7438]: nm-pptp-service-7427 log[ctrlp_disp:pptp_ctrl.c:773]: Client connection established.
Dec 30 21:51:06 sayantan-laptop pptp[7438]: nm-pptp-service-7427 log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 7 'Outgoing-Call-Request'
Dec 30 21:51:06 sayantan-laptop pptp[7438]: nm-pptp-service-7427 log[ctrlp_disp:pptp_ctrl.c:858]: Received Outgoing Call Reply.
Dec 30 21:51:06 sayantan-laptop pptp[7438]: nm-pptp-service-7427 log[ctrlp_disp:pptp_ctrl.c:897]: Outgoing call established (call ID 0, peer's call ID 5671).
Dec 30 21:51:23 sayantan-laptop pptp[7438]: nm-pptp-service-7427 log[logecho:pptp_ctrl.c:677]: Echo Request received.
Dec 30 21:51:23 sayantan-laptop pptp[7438]: nm-pptp-service-7427 log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 6 'Echo-Reply'
Dec 30 21:51:36 sayantan-laptop NetworkManager: <info> VPN plugin failed: 1
Dec 30 21:51:36 sayantan-laptop NetworkManager: SCPlugin-Ifupdown: devices removed (path: /sys/devices/virtual/net/ppp0, iface: ppp0)
Dec 30 21:51:36 sayantan-laptop pptp[7432]: nm-pptp-service-7427 warn[decaps_hdlc:pptp_gre.c:204]: short read (-1): Input/output error
Dec 30 21:51:36 sayantan-laptop pptp[7432]: nm-pptp-service-7427 warn[decaps_hdlc:pptp_gre.c:216]: pppd may have shutdown, see pppd log
Dec 30 21:51:36 sayantan-laptop pptp[7438]: nm-pptp-service-7427 log[callmgr_main:pptp_callmgr.c:234]: Closing connection (unhandled)
Dec 30 21:51:36 sayantan-laptop pptp[7438]: nm-pptp-service-7427 log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 12 'Call-Clear-Request'
Dec 30 21:51:36 sayantan-laptop pptp[7438]: nm-pptp-service-7427 log[call_callback:pptp_callmgr.c:79]: Closing connection (...

[Igor Wojnicki (wojnicki)]

Bogus credentials with OpenVPN work fine, still it's a serious bug!

However the 'Connect automatically' option DOES NOT WORK. It seems that it does nothing, instead of bringing up the VPN upon login.

[Mickael MONSIEUR (mickael-monsieur)]

Hello,
I have the same problem with ubuntu karmic 9.10 fully updated...

Jan 27 15:05:02 mickael-laptop NetworkManager: <info> Starting VPN service 'org.freedesktop.NetworkManager.openvpn'...
Jan 27 15:05:02 mickael-laptop NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.openvpn' started (org.freedesktop.NetworkManager.openvpn), PID 9745
Jan 27 15:05:02 mickael-laptop NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.openvpn' just appeared, activating connections
Jan 27 15:05:02 mickael-laptop kernel: [19983.036671] tun: Universal TUN/TAP device driver, 1.6
Jan 27 15:05:02 mickael-laptop kernel: [19983.036677] tun: (C) 1999-2004 Max Krasnyansky <email address hidden>
Jan 27 15:05:02 mickael-laptop NetworkManager: <info> VPN plugin state changed: 3
Jan 27 15:05:02 mickael-laptop NetworkManager: <info> VPN connection 'smsaction' (Connect) reply received.
Jan 27 15:05:02 mickael-laptop NetworkManager: <WARN> nm_vpn_connection_connect_cb(): VPN connection 'smsaction' failed to connect: 'No VPN secrets!'.
Jan 27 15:05:02 mickael-laptop NetworkManager: <WARN> connection_state_changed(): Could not process the request because no VPN connection was active.
Jan 27 15:05:02 mickael-laptop NetworkManager: <info> (eth0): writing resolv.conf to /sbin/resolvconf
Jan 27 15:05:02 mickael-laptop NetworkManager: <info> Policy set 'Auto eth0' (eth0) as default for routing and DNS.
Jan 27 15:05:06 mickael-laptop NetworkManager: <info> VPN plugin state changed: 3
Jan 27 15:05:06 mickael-laptop NetworkManager: <info> VPN connection 'smsaction' (Connect) reply received.
Jan 27 15:05:06 mickael-laptop NetworkManager: <WARN> nm_vpn_connection_connect_cb(): VPN connection 'BEBRU' failed to connect: 'No VPN secrets!'.
Jan 27 15:05:06 mickael-laptop NetworkManager: <WARN> connection_state_changed(): Could not process the request because no VPN connection was active.
Jan 27 15:05:06 mickael-laptop NetworkManager: <info> (eth0): writing resolv.conf to /sbin/resolvconf
Jan 27 15:05:06 mickael-laptop NetworkManager: <info> Policy set 'Auto eth0' (eth0) as default for routing and DNS.
Jan 27 15:05:19 mickael-laptop NetworkManager: <debug> [1264601119.002570] ensure_killed(): waiting for vpn service pid 9745 to exit
Jan 27 15:05:19 mickael-laptop NetworkManager: <debug> [1264601119.002685] ensure_killed(): vpn service pid 9745 cleaned up

How should we do to stem this problem for developers of ubuntu?
Thank you in advance,
Mickael.