[SRU] Virtual private network connection fails after distribution upgrade due to outdated Network Manager configuration files

[Prem Anand]

[Impact]
* People who are using VPN services (of any kind, using vpnc, openvpn, pptp, etc.

[Test Case]
HOW TO REPRODUCE
1. Upgrade to a newer Ubuntu release.
2. Using the Network Manager application, try to start a virtual private network connection.

EXPECTED BEHAVIOUR
- The connection to complete successfully.

ACTUAL BEHAVIOUR
- The current configuration files, created by a previous network manager installation in the gconf user home folder, makes the application to misbehave; returning a log like this:

[Regression Potential]
May cause Gnome-Shell detection to give up prematurely.

[PPA with a Possible Solution]
Please see the https://bugs.launchpad.net/ubuntu/+source/network-manager-vpnc/+bug/1297849/comments/107 on information how to try the PPA with a solution to the bug that has the patch https://bugs.launchpad.net/ubuntu/+source/network-manager-vpnc/+bug/1297849/+attachment/4253965/+files/network-manager-applet-1297849.patch applied.

[Additional information]
Mar 26 13:23:31 hprem-rmbp NetworkManager[855]: <info> Starting VPN service 'vpnc'...
Mar 26 13:23:31 hprem-rmbp NetworkManager[855]: <info> VPN service 'vpnc' started (org.freedesktop.NetworkManager.vpnc), PID 24419
Mar 26 13:23:31 hprem-rmbp NetworkManager[855]: <info> VPN service 'vpnc' appeared; activating connections
Mar 26 13:23:31 hprem-rmbp NetworkManager[855]: <error> [1395840211.74057] [nm-vpn-connection.c:1374] get_secrets_cb(): Failed to request VPN secrets #2: (6) No agents were available for this request.
Mar 26 13:23:31 hprem-rmbp NetworkManager[855]: <info> Policy set 'blizzard' (wlan0) as default for IPv4 routing and DNS.
Mar 26 13:23:31 hprem-rmbp NetworkManager[855]: <error> [1395840211.74406] [nm-system.c:1266] nm_system_replace_default_ip6_route(): (wlan0): failed to set IPv6 default route: -7
Mar 26 13:23:31 hprem-rmbp NetworkManager[855]: <info> Policy set 'blizzard' (wlan0) as default for IPv6 routing and DNS.
Mar 26 13:23:36 hprem-rmbp NetworkManager[855]: <info> VPN service 'vpnc' disappeared

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: network-manager-vpnc 0.9.8.6-1ubuntu2
Uname: Linux 3.13.0-031300-generic x86_64
NonfreeKernelModules: wl
ApportVersion: 2.13.3-0ubuntu1
Architecture: amd64
CurrentDesktop: Unity
Date: Wed Mar 26 13:26:42 2014
InstallationDate: Installed on 2014-01-17 (67 days ago)
InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Alpha amd64+mac (20140115)
SourcePackage: network-manager-vpnc
UpgradeStatus: No upgrade log present (probably fresh install)

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[E. Lefty Kreouzis (lefty-kreouzis)]

This also affects openvpn VPNs not only vpnc

Apr 19 08:37:26 localhost NetworkManager[975]: message repeated 3 times: [ <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted]
Apr 19 08:38:21 localhost NetworkManager[975]: SCPlugin-Ifupdown: devices removed (path: /sys/devices/virtual/net/tun0, iface: tun0)
Apr 19 08:41:01 localhost NetworkManager[975]: <info> Starting VPN service 'openvpn'...
Apr 19 08:41:01 localhost NetworkManager[975]: <info> VPN service 'openvpn' started (org.freedesktop.NetworkManager.openvpn), PID 8118
Apr 19 08:41:01 localhost NetworkManager[975]: <info> VPN service 'openvpn' appeared; activating connections
Apr 19 08:41:01 localhost NetworkManager[975]: <error> [1397882461.390343] [nm-vpn-connection.c:1374] get_secrets_cb(): Failed to request VPN secrets #2: (6) No agents were available for this request.
Apr 19 08:41:01 localhost NetworkManager[975]: <info> Policy set 'Peter' (wlan0) as default for IPv4 routing and DNS.
Apr 19 08:41:06 localhost NetworkManager[975]: <info> VPN service 'openvpn' disappeared

Same error message: [nm-vpn-connection.c:1374] get_secrets_cb(): Failed to request VPN secrets #2: (6) No agents were available for this request.

[E. Lefty Kreouzis (lefty-kreouzis)]

I created a new login and the VPNC VPN was started properly - this must have something to do with the upgrade and the old network-manager-vpnc and network-manager-openvpn settings.

Where are they kept?

[E. Lefty Kreouzis (lefty-kreouzis)]

When I log in to the new account and start a VPN after this I can start and stop VPNs even from my old account something doesn't start right

[Mike Seda (x-mike-z)]

I am also experiencing the following after upgrading from 13.10 to 14.04:
get_secrets_cb(): Failed to request VPN secrets #2: (6) No agents were available for this request.

I can connect via command-line (openvpn --config client.ovpn). However, having VPN client integrated into the GUI is highly desirable - since /etc/resolv.conf manipulation is handled with that method.

Please fix at your earliest convenience.

FYI, this issue seems to be related to Bug #1247682:
https://bugs.launchpad.net/ubuntu/+source/network-manager-openconnect/+bug/1247682

[Mike Seda (x-mike-z)]

I have resolved the issue on my box by installing resolvconf (and it's dependency, ubuntu-minimal).

[Mike Seda (x-mike-z)]

This bug has just reappeared for me. It seems to have occured after the last 14.04 patch set. I am fully up to date with patches as of right now (2014-05-02 11:20).

[CUnknown (christiaanunknown)]

It seems that exporting the VPN config with the export button in the edit window of the VPN connection is also broken.
Maybe this is related?

It gives an error 'unknown error'.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Mkchan (mkchan)]

I am also seeing this.
I can confirm that vpn works when creating a brand new Unity login user

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Babar (babarhaq)]

Same issue on 14.04. In my case a restart mostly fixes it.

[Anton Anikin (anton-anikin)]

I have the same problem on Ubuntu 14.10

[Kyle Stevens (kstevens715)]

Also experiencing the same thing on 14.04.

[Kyle Stevens (kstevens715)]

I was able to work around this bug by deleting the files in ~/.local/share/keyrings and then re-entering the credentials.

[diabloneo (diabloneo)]

sorry, just misclick. Change type back to 'Public'

[Brian Hart (hartb-austin)]

Also seeing this on Xubuntu 14.04, upgraded from 13.10.

Restart doesn't fix it. I don't have a keyrings file or directory in ~/.local/share/.

If I right click on nm-applet, then Edit Connections, then select a VPN and click Edit, a small edit panel comes up but remains blank/greyed-out for about a minute or so. Then after about a minute, the edit panel is replaced by larger panel with all the data populated and controls enabled.

[gnustavo (gnustavo)]

The problem was "solved" for me by renaming the $HOME/.gconf directory and restarting the Gnome session.

I don't know what that directory holds but I haven't noticed any side effect besides the VPN working again.

[Javierrios (jrios)]

Yesterday I was make upgrade ubuntu 13.10 to Ubuntu 14.04 and now vpn don't work ... And I changed the file $home/.gconf and $home/.local/share and the problem i can't fix ... any idea ?

[Javierrios (jrios)]

The problem is resolved .. I send the e-mail gnustavo and he send me the step for resolved (Thanks !!!)

The Steps

1) Create new user administrador
2) Loggin with new user
3) delete .gconf into the your $home
4) logout
5) Loggin your user
6) the network-manager vpnc work

[Stefano Bagnatica (thepisu)]

I confirm that the problem is solved renaming .gconf directory (from terminal mv .gconf gconf-backup), and doing logout and login.

@jrios: there is no need to create another admin user, as your user itself can move / delete its .gconf directory.

Would be good to find why this was needed... as I think that this operation could lose some other configs..

[Petr Kubánek (petr-kubanek)]

The issue seems to be resolved by the latest Network updates - my VPNs connections were not working yesterday, are back working today. I did not change any settings, I just apply available updates.

[Olivier Godart (olivier-godart-gmail)]

Actually no. I though it was fixed with the update (it was working), but after a reboot, it's broken again!

[Petr Kubánek (petr-kubanek)]

It works for me even after reboot.

[tallien (tallien)]

It is still not working for me. I am using vpnc. None of the updates has made any difference for me. When I click on the VPN profile that I created previously, nothing happens. The connection icon doesn't change, and no connection is made. I am able to edit profiles but not actually make a connection. Deleting .gconf didn't work for me, but I may have messed up when I tried that fix. Will try again and update if it works.

[tallien (tallien)]

I deleted the .gconf folder, shut down my PC and restarted. I was able to get a VPN connection established. But the Disconnect option for the VPN connection failed to work. I clicked on it and nothing happened. The only way to disconnect from the VPN was to use the main Disconnect option and disconnect from my underlying ethernet connection.

After that, all further attempts to connect to a VPN failed the same way as before (click on connect to VPN, nothing happens). Deleting .gconf again and logging in and out allowed me to connect again, and once again I had to disconnect the ethernet connection in order to stop the VPN connection, and then all further attempts to make VPN connections failed again just like before.

Would anyone happen to know if there is a CLI command for connecting and disconnecting to VPNs via vpnc that could be used until this is fixed?

[Lal Samuel Varghese (lalsam)]

Just put all your vpn parameters in /etc/vpnc/default.conf and then do "sudo vpnc" to connect and "sudo vpnc-disconnect" to disconnect.

[tallien (tallien)]

Thanks Lal! I found some more info on what you said at http://wiki.centos.org/HowTos/vpnc and tried it out.
It works, but unfortunately this method does not seem to allow me to access certain functions on the system I need to connect to. Probably due to DNS issues. I found some info on that on the Gentoo wiki and will continue to experiment.
In the meantime the applet controls are still not working. It seems for me they only work the first time after deleting .gconf, and after vpnc is used once and a fresh config file is written, it stops working again. Hopefully there will be a fix for this soon.

[E. Lefty Kreouzis (lefty-kreouzis)]

I noticed the following - in the login sceen if I wait for the WiFi network connection to be established then once I log in I can start/stop VPN connections

If I log in before the connection is established then I am not allowed to start/stop VPN connections

This is supported by the fact that I have created an extra user login - if I can't start/stop VPN connections with my normal user id, if I switch to the extra login I can start/stop them

[E. Lefty Kreouzis (lefty-kreouzis)]

Further information -

If I find I can't start a VPN connection and I log out and log in again then VPN connections work again.

There seems to be some kind of race issue between log in and network connectivity. I don't have the first clue on where to look though

[Francis Avila (francisga)]

This also affected me.

When I attempt to connect to a VPN using the network connection icon in the system try, nothing would happen. (Literally nothing: no error message, no ui changes, no "attempting to connect" icon animation, etc.)

Syslog:

Jul 21 10:38:34 hospitium NetworkManager[784]: <info> Starting VPN service 'vpnc'...
Jul 21 10:38:34 hospitium NetworkManager[784]: <info> VPN service 'vpnc' started (org.freedesktop.NetworkManager.vpnc), PID 5860
Jul 21 10:38:34 hospitium NetworkManager[784]: <info> VPN service 'vpnc' appeared; activating connections
Jul 21 10:38:34 hospitium NetworkManager[784]: <error> [1405957114.724275] [nm-vpn-connection.c:1374] get_secrets_cb(): Failed to request VPN secrets #2: (6) No agents were available for this request.
Jul 21 10:38:34 hospitium NetworkManager[784]: <info> Policy set 'Ethernet DHCP' (eth0) as default for IPv4 routing and DNS.
Jul 21 10:38:40 hospitium NetworkManager[784]: <info> VPN service 'vpnc' disappeared

The minimal workaround I used was this:

1. Delete ~/.gconf/apps/nm-applet/%gconf.xml (file attached).
2. Log out then log back in.

So far the file has not reappeared.

[James Troup (elmo)]

Seeing the same thing on Ubuntu 14.04 with network-manager-pptp. The workaround in #34 also worked for me too.

[tallien (tallien)]

Looks like my case is a little more problematic than most other posters on this thread.

Re. #32 I am not using WiFi. However I have tried waiting a long time before logging in just to test this and it makes no difference for me. My ethernet connection is usually up almost instantaneously anyway.

Re. #34, the file reappears for me after each first new use upon logging back in. In order to make it work a second time I have to again delete the file and log out/in again. And disconnecting never works from the menu, even on the first use after login.

[Benjamin Halbrock (kontakt-bennis-blog)]

Same problem with ubuntu 14.04 and networkmanager-openvpn, but th workaround in #34 doesn't work for me.

If any logs are needed, pls tell me which

[Stefanotis (stefan-brasse)]

Same problem here. I can successfully connect to VPN Network, but immediatelly after being connected, the network-manager restarts. Workaround #34 had no effect.

Aug 5 16:50:57 stef-notebook openconnect[12306]: Established DTLS connection (using OpenSSL)
Aug 5 16:50:58 stef-notebook NetworkManager[11870]: <info> VPN connection 'Uni Marburg' (IP Config Get) complete.
Aug 5 16:50:58 stef-notebook NetworkManager[11870]: <info> Policy set 'friedlnet' (wlan0) as default for IPv4 routing and DNS.
Aug 5 16:50:58 stef-notebook kernel: [ 6261.956506] NetworkManager[11870]: segfault at 740ddf60 ip 00007f030ff57539 sp 00007fffd71a9db8 error 4 in libdbus-1.so.3.7.6[7f030ff31000+44000]
Aug 5 16:50:58 stef-notebook NetworkManager[12322]: <info> NetworkManager (version 0.9.8.8) is starting...

[Olivier Godart (olivier-godart-gmail)]

@ #38 : your problem is different

[adasiko (adasiko256)]

#34

"The minimal workaround I used was this:
1. Delete ~/.gconf/apps/nm-applet/%gconf.xml (file attached).
2. Log out then log back in.
So far the file has not reappeared."

Yes, it's working. But it breaks by itself :(

[Launchpad Janitor (janitor)]

This bug was fixed in the package network-manager-applet - 0.9.10.1-0ubuntu6

---------------
network-manager-applet (0.9.10.1-0ubuntu6) wily; urgency=medium

  * Fix VPNs unable to connect before re-login. (LP: #1297849)

 -- Pavel Boldin (davinchi) <email address hidden> Wed, 22 Jul 2015 11:17:38 -0400

[Lonnie Lee Best (launchpad-startport)]

I see that the status is "Fix Released". Does this mean if I upgraded from 14.04 to 15.04 (right now), I would not experience this bug anymore?

[Gianfranco Costamagna (costamagnagianfranco)]

Nope, it means it is fixed in the development release, aka wily or 15.10.
An SRU should followup for a fix in the currently supported releases.

Fixing in the dev release is the first step.

cheers,

G.

[Brian Murray (brian-murray)]

Hello Prem, or anyone else affected,

Accepted network-manager-applet into trusty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/network-manager-applet/0.9.8.8-0ubuntu4.4 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Lonnie Lee Best (launchpad-startport)]

14.04 is Trusty, right? Well, 14.04 doesn't exhibit this bug. 14.10 does, and after upgrading to 14.10 I had to go back to 14.04 because of this bug. 15.04 did not exhibit this bug either (until a couple of months after release), then there too I had to downgrade to 14.04 again to avoid this bug.

Perhaps this fix won't hurt (the working fine) 14.04, but I thought I should at least restate my experience with this bug, in light of the previous message, that emphasizes Trusty, which (for me) I don't ever recall ever having this bug in 14.04. I'm using 14.04 right now, and do not experience this bug.

[Audun Gangsto (audun-m)]

Me and the users in my company are still seeing this bug on 14.04

We really appreciate the effort to fix this, and we will start testing the proposed package and let you know about the results.

[Pavel Boldin (pboldin)]

Can you please provide the logs?

[D (360-dennis)]

i too see this bug, even after installing the private fix from pavel's ppa. I _think_ (i'm not sure) i see this bug on new wifi connections (where i haven't connected before). do you need logs from my system too? I'm on 15.04

[Lonnie Lee Best (launchpad-startport)]

I can also confirm that Pavel's patch works. Here are the steps I did:

Patch for Ubuntu 15.04 (vivid):

1) Open the sources file using the nano file editor:
sudo nano /etc/apt/sources.list

2) Add these two lines to the bottom of the /etc/apt/sources.list file:

deb http://ppa.launchpad.net/pboldin/nm/ubuntu vivid main
deb-src http://ppa.launchpad.net/pboldin/nm/ubuntu vivid main

3) Hold down ctrl and press o and then press enter. Now hold down ctrl+x, to exit nano.

4) Enter these command:
sudo apt-get update ; sudo apt-get upgrade

5) Reboot your computer.

Why is this patch having such a hard time making it into the main repositories?

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Lonnie Lee Best (launchpad-startport)]

@pboldin

I've been running your patch repository in Ubuntu 15.04, and my "saved" credentials keep getting forgotten for vpnc connections:

https://bugs.launchpad.net/bugs/1465348

Is it possible that this could be caused by your patch?

[Pavel Boldin (pboldin)]

It could be but I will require logs from all the services to be sure.

I think I need to create a log-gathering script.

[Kostadin Stoilov (kmstoilov)]

Affected by this bug on up to date Ubuntu 14.04.

Workaround in #40 solves the issue.

Syslog:

Oct 4 16:39:13 kostadin-Ubuntu NetworkManager[1032]: <info> Starting VPN service 'openvpn'...
Oct 4 16:39:13 kostadin-Ubuntu NetworkManager[1032]: <info> VPN service 'openvpn' started (org.freedesktop.NetworkManager.openvpn), PID 8637
Oct 4 16:39:13 kostadin-Ubuntu NetworkManager[1032]: <info> VPN service 'openvpn' appeared; activating connections
Oct 4 16:39:13 kostadin-Ubuntu NetworkManager[1032]: <error> [1443965953.992100] [nm-vpn-connection.c:1374] get_secrets_cb(): Failed to request VPN secrets #2: (6) No agents were available for this request.
Oct 4 16:39:18 kostadin-Ubuntu NetworkManager[1032]: <info> VPN service 'openvpn' disappeared

[Evan Broder (broder)]

@brian-murray: I just installed the package from proposed on trusty and it seems to have improved things, although there's a 5-10 second delay after nm-applet starts up where it hasn't registered itself as a secrets provider. Still, this seems to be an improvement in behavior.

[Launchpad Janitor (janitor)]

This bug was fixed in the package network-manager-applet - 0.9.8.8-0ubuntu4.4

---------------
network-manager-applet (0.9.8.8-0ubuntu4.4) trusty; urgency=medium

  * Fix VPNs unable to connect before re-login. (LP: #1297849)

 -- Pavel Boldin (davinchi) <email address hidden> Wed, 22 Jul 2015 11:17:38 -0400

[Chris J Arges (arges)]

The verification of the Stable Release Update for network-manager-applet has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

[Lonnie Lee Best (launchpad-startport)]

Is this bug fixed in Ubuntu 15.10? I'm considering upgrading from 14.04 to 15.10, but I don't want to do it if doing so will require me to address this bug again.

[D (360-dennis)]

I'm sorry to report the bug still occurs in 15.10. I installed a fresh copy on my XPS13 and i had to click 13 times on VPN to start it on a unknown wifi network. If you need my logs, let me know. I still monitor this thread.

[Nicolas Diogo (nicolasdiogo)]

hi,

It has appeared after months using 15.10

I added a number of VPN connection and now all of them are failing ....

It also highlights the short-coming in importing multiple VPN connections and setting their username and password

thanks,

[Martin Pitt (pitti)]

Hello Prem, or anyone else affected,

Accepted network-manager-openconnect into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/network-manager-openconnect/1.2.0-0ubuntu0.16.04.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Jan Henke (jhe)]

I have tested the proposed version 1.2.0-0ubuntu0.16.04.1 of network-manager-openconnect and it fixed the problems for me.

[Aron Xu (happyaron)]

Works for me, marking as verification-done.

[D (360-dennis)]

I'm sorry, i read https://wiki.ubuntu.com/Testing/EnableProposed but i can't figure out how to install the proposed package. I tried
- Create the file /etc/apt/preferences.d/proposed-updates with this content:
Package: *
Pin: release a=xenial-proposed
Pin-Priority: 400
sudo apt-get upgrade -s
i got "network-manager-gnome (1.2.0-0ubuntu0.16.04.3 Ubuntu:16.04/xenial-updates [amd64])"
is that the correct package? It says
"network-manager-openconnect 1.2.0-0ubuntu0.16.04.1" on
https://launchpad.net/ubuntu/+source/network-manager-openconnect/1.2.0-0ubuntu0.16.04.1
- sudo aptitude -t xenial-proposed
does not work for me, but im on 16.04..
After installing aptitude, it gave me
"The Value 'xenial-proposed' is invalid for APT:: Default-Release as such a release is not available in the sources"

I'm thinking the page about Testing/EnabledProposed needs an update (checkbox-gtk does not work for me too for uploading the hardware profile). In the meantime, could some tell this newbielinux how to install the proposed package? And how to uninstall it after testing?

[Mo (alim0x)]

@6-dennis: Maybe you can try

System Settings - Software & Updates - Developer Options

There is an option of 'xenial-proposed'

[[e-mail] (khoonirobo)]

In Xenial

on testing

network-manager-openconnect
network-manager-openconnect-gnome

Works fine.

[Launchpad Janitor (janitor)]

This bug was fixed in the package network-manager-openconnect - 1.2.0-0ubuntu0.16.04.1

---------------
network-manager-openconnect (1.2.0-0ubuntu0.16.04.1) xenial; urgency=medium

  * SRU to 1.2.0 release to match NM version (LP: #1297849)

 -- Aron Xu <email address hidden> Fri, 27 May 2016 16:09:01 +0800

[ubuntu user (aaadas)]

Problem pops up again for me after upgrading from 15.10 to 16.04.
This time error message is a bit different:

<error> [1468865322.8065] vpn-connection[0x29d15b0,aaaa,"XXX",0]: Failed to request VPN secrets #3: No agents were available for this request.

Ubuntu 16.04
dpkg --list |grep openconnect
ii libopenconnect5:amd64 7.06-2build2 amd64 open client for Cisco AnyConnect VPN - shared library
ii network-manager-openconnect 1.2.0-0ubuntu0.16.04.1 amd64 network management framework (OpenConnect plugin)
ii network-manager-openconnect-gnome 1.2.0-0ubuntu0.16.04.1 amd64 network management framework (OpenConnect plugin GNOME GUI)
ii openconnect 7.06-2build2 amd64 open client for Cisco AnyConnect VPN

Connection from command line is working.
I tried to recreate connection and reinstalling. What else can I try?

[Ramonskie (ramonskie)]

same issue here stopped working since a few days ago
im on 16.04 as wel with

network-manager-openconnect:
  Installed: 1.2.0-0ubuntu0.16.04.1

[Vasili Burdo (vburdo)]

(repost from bug #1247682)

Hi, same problem after upgrade to Xenial.
Sometimes VPN connect succeeds, but most often it fails.
Using openconnect from command line always works.

Here are debug logs for both failed and successful and connection attempts:

-------------------------FAILED ATTEMPT:BEGIN------------------------
Jul 27 13:26:02 myubuntu NetworkManager[856]: <debug> [1469615162.5877] active-connection[0x293b400]: set device "eno1" [0x28db5f0]
Jul 27 13:26:02 myubuntu NetworkManager[856]: <debug> [1469615162.5877] device[0x28db5f0] (eno1): add_pending_action (1): 'activation::0x293b400'
Jul 27 13:26:02 myubuntu NetworkManager[856]: <debug> [1469615162.5877] active-connection[0x293b400]: constructed (NMVpnConnection, version-id 10)
Jul 27 13:26:02 myubuntu NetworkManager[856]: <debug> [1469615162.5878] auth: call[435]: CheckAuthorization(org.freedesktop.NetworkManager.network-control), subject=unix-process[pid=12623, uid=1000, start=23699935]
Jul 27 13:26:02 myubuntu NetworkManager[856]: <debug> [1469615162.5885] auth: call[435]: CheckAuthorization succeeded: (is_authorized=1, is_challenge=0)
Jul 27 13:26:02 myubuntu NetworkManager[856]: <debug> [1469615162.5889] active-connection[0x293b400]: set state activating (was unknown)
Jul 27 13:26:02 myubuntu NetworkManager[856]: <debug> [1469615162.5889] active-connection[0x293b400]: check-master-ready: not signalling (state activating, no master)
Jul 27 13:26:02 myubuntu NetworkManager[856]: <info> [1469615162.5890] audit: op="connection-activate" uuid="ab76ecac-1eab-4b32-86c7-6524528c5f89" name="Testvpn.CISCO" pid=12623 uid=1000 result="success"
Jul 27 13:26:02 myubuntu NetworkManager[856]: <info> [1469615162.5969] vpn-connection[0x293b400,ab76ecac-1eab-4b32-86c7-6524528c5f89,"Testvpn.CISCO",0]: Started the VPN service, PID 2409
Jul 27 13:26:02 myubuntu NetworkManager[856]: <info> [1469615162.6027] vpn-connection[0x293b400,ab76ecac-1eab-4b32-86c7-6524528c5f89,"Testvpn.CISCO",0]: Saw the service appear; activating connection
Jul 27 13:26:02 myubuntu NetworkManager[856]: <debug> [1469615162.6028] vpn-connection[0x293b400,ab76ecac-1eab-4b32-86c7-6524528c5f89,"Testvpn.CISCO",0]: requesting VPN secrets pass #1
Jul 27 13:26:02 myubuntu NetworkManager[856]: <debug> [1469615162.6031] Secrets requested for connection /org/freedesktop/NetworkManager/Settings/2 (Testvpn.CISCO/vpn)
Jul 27 13:26:02 myubuntu NetworkManager[856]: <debug> [1469615162.6032] settings-connection[0x28ad9f0,ab76ecac-1eab-4b32-86c7-6524528c5f89]: (vpn:0x2a421b0) secrets requested flags 0x80000004 hints '(none)'
Jul 27 13:26:02 myubuntu NetworkManager[856]: <debug> [1469615162.6035] agent-manager: ([0x2a421b0/"Testvpn.CISCO"/"vpn"]) system settings secrets sufficient
Jul 27 13:26:02 myubuntu NetworkManager[856]: <debug> [1469615162.6038] settings-connection[0x28ad9f0,ab76ecac-1eab-4b32-86c7-6524528c5f89]: (vpn:0x28ec700) existing secrets returned
Jul 27 13:26:02 myubuntu NetworkManager[856]: <debug> [1469615162.6039] settings-connection[0x28ad9f0,ab76ecac-1eab-4b32-86c7-6524528c5f89]: (vpn:0x28ec700) secrets request completed
Jul 27 13:26:02 myubuntu NetworkManager[856]: <debug> [1469615162.6044] settings-connection[0x28ad9f0,ab...

[Freak (rrtaft)]

There seems to be another issue causing what was mentioned in the last 3 posts not related to this bug. Once the window is open to enter your credentials, if you don't fill them out quick enough, you can get the 'Failed to request VPN secrets #3: No agents were available for this request.'. This includes fresh installs of Xenial, we have four Mint 18 users that are experiencing this. It appears to work 'sometimes', then a few users discovered you just have to login really quick for it to work. This is with network-manager-openconnect 1.2.0-0ubuntu0.16.04.1

[Vasili Burdo (vburdo)]

Hm,

I tried to upgrade network-manager-openconnect and network-manager-openconnect-gnome to Yakkety version (i.e. 1.2.2-1) - downloaded .debs from https://launchpad.net/ubuntu/+source/network-manager-openconnect/

First impression, looks like it fixes the problem.
At least 3 connect attempts with varying delays in GUI go smooth.

And it looks like witchery, because .diff shows there was no code changes between Xenial and Yakkety - only metadata fixes.

Anyways, let's wait couple of days. Will keep this thread updated.

[Ovidiu-Florin BOGDAN (ovidiu-florin)]

I'm also experiencing this after an upgrade from Xenial to Yakety (Kubuntu)

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Henry Primeau (hprimeau)]

Running 'killall nm-applet; nohup nm-applet &' in Terminal fixed the VPN connection.

Unfortunately, need to do this each time the computer is shutdown and restarted.

[Sander Alberink (alberink-stampfini)]

I'm experiencing the same problem: updated to Artful Beta to find that my VPN connection will not activate. The workaround details in https://bugs.launchpad.net/ubuntu/+source/network-manager-openvpn/+bug/1297849/comments/195 works, but needs to be done everytime.

[Thomas (tombl)]

Same for me. My VPN connection no longer works since upgrading from 17.04 to 17.10. The work-around `killall nm-applet; nohup nm-applet &` "fixes" it temporarily...