Regression: openconnect VPN does not work anymore

Bug #1247682 reported by Dima Ryazanov
122
This bug affects 26 people
Affects Status Importance Assigned to Milestone
network-manager-openconnect (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

I can't connect to VPN after upgrading to 13.10. I'm using KDE; I select the VPN connection, click connect, and nothing happens. No error messages.

In /var/log/syslog, I see:

Nov 3 14:33:22 dima-xps NetworkManager[830]: <info> Starting VPN service 'openconnect'...
Nov 3 14:33:22 dima-xps NetworkManager[830]: <info> VPN service 'openconnect' started (org.freedesktop.NetworkManager.openconnect), PID 9757
Nov 3 14:33:22 dima-xps NetworkManager[830]: <info> VPN service 'openconnect' appeared; activating connections
Nov 3 14:33:22 dima-xps NetworkManager[830]: <error> [1383518002.383197] [nm-vpn-connection.c:1374] get_secrets_cb(): Failed to request VPN secrets #3: (6) No agents were available for this request.

I don't know what that means, but at the very minimum, there has to be some sort of feedback in the UI.

ProblemType: Bug
DistroRelease: Ubuntu 13.10
Package: network-manager-openconnect 0.9.8.0-1ubuntu2
ProcVersionSignature: Ubuntu 3.8.0-29.42-generic 3.8.13.5
Uname: Linux 3.8.0-29-generic x86_64
ApportVersion: 2.12.5-0ubuntu2.1
Architecture: amd64
Date: Sun Nov 3 14:32:54 2013
EcryptfsInUse: Yes
InstallationDate: Installed on 2013-04-05 (212 days ago)
InstallationMedia: Kubuntu 12.10 "Quantal Quetzal" - Release amd64 (20121017.1)
MarkForUpload: True
SourcePackage: network-manager-openconnect
UpgradeStatus: Upgraded to saucy on 2013-10-24 (10 days ago)

Revision history for this message
Dima Ryazanov (dima-gmail) wrote :
Revision history for this message
Mike Miller (mtmiller) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. Can you test connecting to your VPN with openconnect on the command line to help identify if this is the same as other similar bugs reported recently?

1. Can you connect with "sudo openconnect -v VPN-URL", tell us whether it succeeds or not, and paste the output here? You can sanitize the output to remove IP addresses and host names if you want.

2. Can you connect with "sudo openconnect -v --no-xmlpost VPN-URL" and report the same as above?

See also bug #1202204, #1225276, and #1229195.

Changed in network-manager-openconnect (Ubuntu):
status: New → Incomplete
Revision history for this message
Dima Ryazanov (dima-gmail) wrote :

I don't think it succeeded; it's complaining about a username and password. I don't actually have those; I have a certificate and a key .pem files, but don't know how to specify them. Also, I gave it a --cafile option cause it was complaining about the server certificate otherwise.

1.

POST https://[HOSTNAME]/
Attempting to connect to server [IP]:443
SSL negotiation with [HOSTNAME]
Connected to HTTPS on [HOSTNAME]
Got HTTP response: HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Cache-Control: no-cache
Pragma: no-cache
Connection: Keep-Alive
Date: Sun, 03 Nov 2013 23:26:07 GMT
X-Aggregate-Auth: 1
HTTP body chunked (-2)
Server requested SSL client certificate; none was configured
POST https://[HOSTNAME]/
Got HTTP response: HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Cache-Control: no-cache
Pragma: no-cache
Connection: Keep-Alive
Date: Sun, 03 Nov 2013 23:26:07 GMT
X-Aggregate-Auth: 1
HTTP body chunked (-2)
XML response has no "auth" node
GET https://[HOSTNAME]/
SSL negotiation with [HOSTNAME]
Connected to HTTPS on [HOSTNAME]
Got HTTP response: HTTP/1.0 302 Object Moved
Content-Type: text/html
Content-Length: 0
Cache-Control: no-cache
Pragma: no-cache
Connection: Close
Date: Sun, 03 Nov 2013 23:26:07 GMT
Location: /+webvpn+/index.html
Set-Cookie: tg=; expires=Thu, 01 Jan 1970 22:00:00 GMT; path=/; secure
HTTP body length: (0)
GET https://[HOSTNAME]/+webvpn+/index.html
SSL negotiation with [HOSTNAME]
Connected to HTTPS on [HOSTNAME]
Got HTTP response: HTTP/1.1 200 OK
Transfer-Encoding: chunked
Content-Type: text/xml
Cache-Control: max-age=0
Set-Cookie: webvpn=; expires=Thu, 01 Jan 1970 22:00:00 GMT; path=/; secure
Set-Cookie: webvpnc=; expires=Thu, 01 Jan 1970 22:00:00 GMT; path=/; secure
Set-Cookie: webvpnlogin=1; secure
X-Transcend-Version: 1
HTTP body chunked (-2)
Please enter your username and password.
Certificate Validation Failure
Failed to obtain WebVPN cookie

2.

GET https://[HOSTNAME]/
Attempting to connect to server [IP]:443
SSL negotiation with [HOSTNAME]
Connected to HTTPS on [HOSTNAME]
Got HTTP response: HTTP/1.0 302 Object Moved
Content-Type: text/html
Content-Length: 0
Cache-Control: no-cache
Pragma: no-cache
Connection: Close
Date: Sun, 03 Nov 2013 23:32:22 GMT
Location: /+webvpn+/index.html
Set-Cookie: tg=; expires=Thu, 01 Jan 1970 22:00:00 GMT; path=/; secure
HTTP body length: (0)
GET https://[HOSTNAME]/+webvpn+/index.html
SSL negotiation with [HOSTNAME]
Connected to HTTPS on [HOSTNAME]
Got HTTP response: HTTP/1.1 200 OK
Transfer-Encoding: chunked
Content-Type: text/xml
Cache-Control: max-age=0
Set-Cookie: webvpn=; expires=Thu, 01 Jan 1970 22:00:00 GMT; path=/; secure
Set-Cookie: webvpnc=; expires=Thu, 01 Jan 1970 22:00:00 GMT; path=/; secure
Set-Cookie: webvpnlogin=1; secure
X-Transcend-Version: 1
HTTP body chunked (-2)
Please enter your username and password.
Certificate Validation Failure
Failed to obtain WebVPN cookie

Revision history for this message
Mike Miller (mtmiller) wrote :

OK, see "man openconnect" for the options for certificate files.

Use the option -c CERTFILE for your user certificate and -k KEYFILE for your private key. Add those options to the ones above to try to connect both with and without the --no-xmlpost option.

Revision history for this message
Dima Ryazanov (dima-gmail) wrote :
Download full text (5.8 KiB)

Thanks, that worked! (Both with and without --no-xmlpost).

So I'm guessing the bug is just the NetworkManager failing to talk to KDE's applet? (At least, I've seen it fail in other ways - when asking for wifi password, etc.)

1.

POST https://[HOSTNAME]/
Attempting to connect to server [IP]:443
Using certificate file Documents/myvpncert.pem
Using private key file Documents/myvpnkey.pem
Enter PEM pass phrase:
Using client certificate 'dima'
Adding supporting CA '[...]'
SSL negotiation with [HOSTNAME]
Connected to HTTPS on [HOSTNAME]
Got HTTP response: HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Cache-Control: no-cache
Pragma: no-cache
Connection: Keep-Alive
Date: Tue, 05 Nov 2013 07:30:12 GMT
X-Aggregate-Auth: 1
HTTP body chunked (-2)
XML POST enabled
Please enter your username and password.
Username:dima
Password:
POST https://[HOSTNAME]/
Got HTTP response: HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Cache-Control: no-cache
Pragma: no-cache
Connection: Keep-Alive
Date: Tue, 05 Nov 2013 07:30:18 GMT
X-Aggregate-Auth: 1
HTTP body chunked (-2)
Enter your Google Authenticator Code:
Response:
POST https://[HOSTNAME]/
Got HTTP response: HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Cache-Control: no-cache
Pragma: no-cache
Connection: Keep-Alive
Date: Tue, 05 Nov 2013 07:30:25 GMT
X-Aggregate-Auth: 1
HTTP body chunked (-2)
TCP_INFO rcv mss 1368, snd mss 1368, adv mss 1448, pmtu 1500
Got CONNECT response: HTTP/1.1 200 OK
X-CSTP-Version: 1
X-CSTP-Address: 172.16.70.103
X-CSTP-Netmask: 255.255.255.0
X-CSTP-DNS: 172.16.128.6
X-CSTP-DNS: 172.17.8.6
X-CSTP-Lease-Duration: 86400
X-CSTP-Session-Timeout: 86400
X-CSTP-Idle-Timeout: 3600
X-CSTP-Disconnected-Timeout: 3600
X-CSTP-Default-Domain: [...]
X-CSTP-Split-Include: [...]
X-CSTP-Keep: true
X-CSTP-Tunnel-All-DNS: false
X-CSTP-DPD: 30
X-CSTP-Keepalive: 15
X-CSTP-MSIE-Proxy-Lockdown: true
X-CSTP-Smartcard-Removal-Disconnect: true
X-DTLS-Session-ID: 8F18733B5600E14033EB94C391F2B88A1725CCDB92A148E76F83484DA8C74087
X-DTLS-Port: 443
X-DTLS-Keepalive: 15
X-DTLS-DPD: 30
X-CSTP-MTU: 1355
X-DTLS-CipherSuite: AES128-SHA
X-CSTP-Routing-Filtering-Ignore: false
X-CSTP-Quarantine: false
X-CSTP-Disable-Always-On-VPN: false
X-CSTP-TCP-Keepalive: true
X-CSTP-Post-Auth-XML: <elided>
CSTP connected. DPD 30, Keepalive 15
DTLS option X-DTLS-Session-ID : 8F18733B5600E14033EB94C391F2B88A1725CCDB92A148E76F83484DA8C74087
DTLS option X-DTLS-Port : 443
DTLS option X-DTLS-Keepalive : 15
DTLS option X-DTLS-DPD : 30
DTLS option X-DTLS-CipherSuite : AES128-SHA
DTLS initialised. DPD 30, Keepalive 15
Connected tun0 as 172.16.70.103, using SSL

2.

GET https://[HOSTNAME]/
Attempting to connect to server [IP]:443
Using certificate file Documents/myvpncert.pem
Using private key file Documents/myvpnkey.pem
Enter PEM pass phrase:
Using client certificate 'dima'
Adding supporting CA '[...]'
SSL negotiation with [HOSTNAME]
Connected to HTTPS on [HOSTNAME]
Got HTTP response: HTTP/1.0 302 Object Moved
Content-Type: text/html
Content-Length: 0
Cache-Control: no-cache
Pragma: no-cache
Connection: Close
Date: Tue, 05 Nov 2013 07:34:10 GMT
L...

Read more...

Revision history for this message
Mike Miller (mtmiller) wrote :

Yes, most likely. Unfortunately I don't have a Kubuntu setup to test with at the moment so I can't try this for myself, perhaps someone else can.

Were you able to configure your user certificate and key file in the KDE applet properly when setting up the connection?

You might try getting some debug logs out of NetworkManager while attempting to connect to your VPN using the information at https://wiki.ubuntu.com/DebuggingNetworkManager.

Revision history for this message
Funky Future (funky-future) wrote :
Download full text (13.4 KiB)

I experience the same using network-manager-openconnect-gnome within Cinnamon 2.0.12. another difference in my case is, i use no certificate, but user/password-credentials to authentificate.
connecting with openconnect as suggested in comment #2 works.

here's the part of the syslog, when i fail to connect:
Nov 13 13:53:52 hostname NetworkManager[1218]: <info> logging: level 'DEBUG' domains 'PLATFORM,RFKILL,ETHER,WIFI,BT,MB,DHCP4,DHCP6,PPP,IP4,IP6,AUTOIP4,DNS,VPN,SHARING,SUPPLICANT,AGENTS,SETTINGS,SUSPEND,CORE,DEVICE,OLPC,WIMAX,INFINIBAND,FIREWALL,ADSL,BOND,VLAN,BRIDGE'
Nov 13 13:53:58 hostname NetworkManager[1218]: <info> Starting VPN service 'openconnect'...
Nov 13 13:53:58 hostname NetworkManager[1218]: <info> VPN service 'openconnect' started (org.freedesktop.NetworkManager.openconnect), PID 21155
Nov 13 13:53:58 hostname NetworkManager[1218]: <info> VPN service 'openconnect' appeared; activating connections
Nov 13 13:53:58 hostname NetworkManager[1218]: <debug> [1384347238.429080] [nm-vpn-connection.c:1413] get_secrets(): (8958a0b8-5894-4920-883e-1451d1cc8c52/vpn-provider) requesting VPN secrets pass #1
Nov 13 13:53:58 hostname NetworkManager[1218]: <debug> [1384347238.429231] [nm-agent-manager.c:1058] nm_agent_manager_get_secrets(): Secrets requested for connection /org/freedesktop/NetworkManager/Settings/0 (vpn)
Nov 13 13:53:58 hostname NetworkManager[1218]: <debug> [1384347238.429268] [nm-settings-connection.c:864] nm_settings_connection_get_secrets(): (8958a0b8-5894-4920-883e-1451d1cc8c52/vpn:1) secrets requested flags 0x80000004 hint '(null)'
Nov 13 13:53:58 hostname NetworkManager[1218]: <debug> [1384347238.429819] [nm-agent-manager.c:973] get_start(): (0x10e6a50/vpn) system settings secrets sufficient
Nov 13 13:53:58 hostname NetworkManager[1218]: <debug> [1384347238.429841] [nm-settings-connection.c:721] agent_secrets_done_cb(): (8958a0b8-5894-4920-883e-1451d1cc8c52/vpn:1) existing secrets returned
Nov 13 13:53:58 hostname NetworkManager[1218]: <debug> [1384347238.429852] [nm-settings-connection.c:727] agent_secrets_done_cb(): (8958a0b8-5894-4920-883e-1451d1cc8c52/vpn:1) secrets request completed
Nov 13 13:53:58 hostname NetworkManager[1218]: <debug> [1384347238.431959] [nm-settings-connection.c:767] agent_secrets_done_cb(): (8958a0b8-5894-4920-883e-1451d1cc8c52/vpn:1) new agent secrets processed
Nov 13 13:53:58 hostname NetworkManager[1218]: <debug> [1384347238.431995] [nm-vpn-connection.c:1379] get_secrets_cb(): (8958a0b8-5894-4920-883e-1451d1cc8c52/vpn-provider) asking service if additional secrets are required
Nov 13 13:53:58 hostname NetworkManager[1218]: <info> VPN plugin state changed: init (1)
Nov 13 13:53:58 hostname NetworkManager[1218]: <debug> [1384347238.433939] [nm-vpn-connection.c:1340] plugin_need_secrets_cb(): (8958a0b8-5894-4920-883e-1451d1cc8c52/vpn-provider) service indicated additional secrets required
Nov 13 13:53:58 hostname NetworkManager[1218]: <debug> [1384347238.433986] [nm-vpn-connection.c:1413] get_secrets(): (8958a0b8-5894-4920-883e-1451d1cc8c52/vpn-provider) requesting VPN secrets pass #2
Nov 13 13:53:58 hostname NetworkManager[1218]: <debug> [1384347238.434133] [nm-agent-manager.c:1058] nm_agent_ma...

Changed in network-manager-openconnect (Ubuntu):
status: Incomplete → New
Revision history for this message
Mike Miller (mtmiller) wrote :

@Funky, which command in comment #2 works for you, or do both commands work?

Changed in network-manager-openconnect (Ubuntu):
status: New → Incomplete
Revision history for this message
Dima Ryazanov (dima-gmail) wrote :

Actually, it works again... I guess an update to NetworkManager or KDE or something fixed it.

Revision history for this message
Mike Miller (mtmiller) wrote :

This bug report is being closed due to your last comment regarding this being fixed with an update. For future reference you can manage the status of your own bugs by clicking on the current status in the yellow line and then choosing a new status in the revealed drop down box. You can learn more about bug statuses at https://wiki.ubuntu.com/Bugs/Status. Thank you again for taking the time to report this bug and helping to make Ubuntu better. Please submit any future bugs you may find.

Changed in network-manager-openconnect (Ubuntu):
status: Incomplete → Invalid
Revision history for this message
Jaceq (dzacek83) wrote :

This is still the case for me.

In logs I get:
Jan 13 10:01:38 HP NetworkManager[879]: <info> Starting VPN service 'openconnect'...
Jan 13 10:01:38 HP NetworkManager[879]: <info> VPN service 'openconnect' started (org.freedesktop.NetworkManager.openconnect), PID 3799
Jan 13 10:01:38 HP NetworkManager[879]: <info> VPN service 'openconnect' appeared; activating connections
Jan 13 10:01:50 HP NetworkManager[879]: <error> [1389603710.602692] [nm-vpn-connection.c:1374] get_secrets_cb(): Failed to request VPN secrets #3: (6) No agents were available for this request.

I can connect on console with: sudo openconnect -v <URL> --no-xmlpost
I just did full update now, I have:
openconnect: 5.01-1
network-manager-openconnect: 0.9.8.0-1ubuntu2

Jaceq (dzacek83)
Changed in network-manager-openconnect (Ubuntu):
status: Invalid → Incomplete
status: Incomplete → New
Revision history for this message
Mike Miller (mtmiller) wrote :

Hi Jaceq, are you able to connect on the console with

  sudo openconnect -v <URL>

without the --no-xmlpost option?

If you are able to connect both with and without --no-xmlpost, then please also report whether you are using nm-applet, gnome-shell, or KDE's plasma-widget-networkmanagement.

If you are able to connect with --no-xmlpost but not without that option, then please see bug #1229195 which is specifically about the error you are having.

Changed in network-manager-openconnect (Ubuntu):
status: New → Incomplete
Revision history for this message
Jaceq (dzacek83) wrote :

Hi,

I am unable to connect without --no-xmlpost

I am using KDE;s plastma-widget-networkmanagemnt

I have browsed linked bug and it seems that this is my problem.
I will try to find package 5.02-1 ( I have 5.01-1).

Thanks!

Revision history for this message
Mike Miller (mtmiller) wrote :

Thanks for replying and confirming that bug #1229195 describes the problem you are having. I'm setting this bug status back to invalid since the original reporter's problem has been resolved by upgrades or configuration changes.

Changed in network-manager-openconnect (Ubuntu):
status: Incomplete → Invalid
Revision history for this message
Anton Anikin (anton-anikin) wrote :

I have the same problem on Ubuntu 14.04...

Revision history for this message
Anton Anikin (anton-anikin) wrote :

openconnect:amd64/trusty 5.02-1
network-manager:amd64/trusty 0.9.8.8

Changed in network-manager-openconnect (Ubuntu):
status: Invalid → Confirmed
Revision history for this message
Mike Miller (mtmiller) wrote :

Hi Anton, you say you have the same problem. Do you mean that you are unable to connect with openconnect using the KDE networking VPN widget, but you are able to connect with openconnect on the command line? Please clarify the specific symptoms that you are experiencing that lead you to believe that this bug is still present? Thanks.

Changed in network-manager-openconnect (Ubuntu):
status: Confirmed → Incomplete
Revision history for this message
Jaceq (dzacek83) wrote :

And I am back here.
So the --no-xmlpost has been resolved, and now I can connect on console without --no-xmlpost option....
Yet, I am unable to connect via UI (in KDE / plasma).
I get following log entries:

With GUI I get this in log:
POST https://XXX/
Attempting to connect to server XXX:443
SSL negotiation with XXX
Connected to HTTPS on XXX
XML POST enabled

In syslog I have:
Jan 22 14:31:05 HP NetworkManager[844]: <info> Starting VPN service 'openconnect'...
Jan 22 14:31:05 HP NetworkManager[844]: <info> VPN service 'openconnect' started (org.freedesktop.NetworkManager.openconnect), PID 6997
Jan 22 14:31:05 HP NetworkManager[844]: <info> VPN service 'openconnect' appeared; activating connections
Jan 22 14:31:05 HP NetworkManager[844]: <info> VPN plugin state changed: init (1)
Jan 22 14:31:36 HP NetworkManager[844]: <error> [1390397496.727336] [nm-vpn-connection.c:1374] get_secrets_cb(): Failed to request VPN secrets #3: (6) No agents were available for this request.
Jan 22 14:31:36 HP NetworkManager[844]: <info> Policy set 'DHCP' (eth0) as default for IPv4 routing and DNS.
Jan 22 14:31:41 HP NetworkManager[844]: <info> VPN service 'openconnect' disappeared

My packages:
dpkg -l | grep openconnect
ii libopenconnect2:amd64 5.02-1 amd64 open client for Cisco AnyConnect VPN - shared library
ii network-manager-openconnect 0.9.8.0-1ubuntu2 amd64 network management framework (OpenConnect plugin)
ii openconnect 5.02-1 amd64 open client for Cisco AnyConnect VPN

Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for network-manager-openconnect (Ubuntu) because there has been no activity for 60 days.]

Changed in network-manager-openconnect (Ubuntu):
status: Incomplete → Expired
Revision history for this message
Jaceq (dzacek83) wrote :

This seems to still exist, anyone else having this issue?

Changed in network-manager-openconnect (Ubuntu):
status: Expired → New
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in network-manager-openconnect (Ubuntu):
status: New → Confirmed
Revision history for this message
kouakou (kj684258) wrote :

Started having this issue after upgrading to 14.04.

Revision history for this message
Mike Miller (mtmiller) wrote :

Are all the users confirming this connection failure using KDE / Kubuntu and using the KDE Plasma widget to connect with OpenConnect?

Revision history for this message
Tobias Kuhn (tkuhn) wrote :

I am having the same problem. It appeared after upgrading to 14.04. I am using the standard VPN under Unity...

Tobias Kuhn (tkuhn)
tags: added: trusty
Revision history for this message
Mike Miller (mtmiller) wrote :

So @tkuhn you are able to connect to your VPN using openconnect on the command line and the VPN connection works? It only fails to connect when using the NM GUI in the Unity menu bar? See comment #2. The command will be something like "sudo openconnect -v [certificate options] vpn-host".

Revision history for this message
Tobias Kuhn (tkuhn) wrote :

Now, it's working again for me! Could be because I installed the latest Ubuntu updates today, or because I am in a different wireless network now... I have to try it again tomorrow in the other network.

Revision history for this message
Tobias Kuhn (tkuhn) wrote :

I am no longer affected. It works now for me, no matter which network I am in. Yesterday it didn't, even after restarting Ubuntu. Could it be that yesterday's Ubuntu update solved the issue?

Revision history for this message
Paul Streitman (rtmpaul) wrote :

I have this issue after upgrading to Trusty from Saucy with either XFCE or Gnome 3. I can connect to the VPN manually from the command line but it fails when I try to do it through the network manager applet.

Revision history for this message
vaivaswatha (vaivaswatha) wrote :

I have this issue on lubuntu through the standard network-manager applet. It works fine on command line.

Revision history for this message
Nikola Vidovic (dzany) wrote :

I have the same problem as vaivaswatha.

Revision history for this message
Sami Pietila (sampie) wrote :

On my ubuntu 14.04 desktop, running following commands cured the problem:
1. "sudo apt-get remove --purge network-manager-gnome"
reboot
2. "sudo apt-get install network-manager-gnome"
logout/login

Revision history for this message
Christianus Pistorius (carbeck) wrote :

I have a completely new installation of Kubuntu 14.04 here, and Gnome dependencies for Network Manager aren't installed. In so far, I can't have any faulty old configuration files. Also compare http://forum.ubuntuusers.de/topic/openconnect-mit-nm-plasma-fuehrt-zu-segfault-i/ – the OP is in German, but I included a lot of console output that will hopefully be helpful.

Revision history for this message
Olivier Godart (olivier-godart-gmail) wrote :

Sami, your workaround (#32) works, but doesn't survive a reboot: problem reoccurs.

Revision history for this message
Christianus Pistorius (carbeck) wrote :

Tried #32 with plasma-nm instead of network-manager-gnome on Kubuntu 14.04 (32-bit), but it still doesn't work for me.

Revision history for this message
Steve O (stratus-ss) wrote :

I am posting here because I do not have a problem with network-manager-vpnc. My issue is that on 2 computers which were *fresh* installs and not upgrades, if I go to try and launch an openconnect session, it dies almost immediately. If I use "sudo openconnect <hostname>" I connect just fine.

Log files to follow later

Revision history for this message
Steve O (stratus-ss) wrote :

Couldnt edit the original post: These are both Ubuntu-Gnome 14.04 64 Bit releases

Revision history for this message
Trent Lloyd (lathiat) wrote :
Revision history for this message
cyberwill (wilson-g) wrote :

Hello!
I´ve got the same problem using 15.04 Ubuntu version. It worked well until yesterday. Only using my broadband.

Revision history for this message
Vasili Burdo (vburdo) wrote :
Download full text (25.4 KiB)

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,ab76ecac-1eab-4b32-86c7-652...

Revision history for this message
Tom Carroll (h-thomas-carroll) wrote :

I disagree with the duplicate status.

From my debug logs and the above attached patches, a timeout is expiring.

The key artifact is

NetworkManager[14599]: <debug> [1476879550.3835] agent-manager: req[0xb9f6c0, :1.43/org.freedesktop.nm-applet/1000]: agent failed secrets request [0x7f13f8006270/"My VPN"/"vpn"]: Timeout was reached
NetworkManager[14599]: <debug> [1476879550.3837] settings-connection[0xb528f0,b7ea4f0f-f388-4225-ae66-536753417125]: (vpn:0xbc7180) secrets request error: No agents were available for this request.

The problem arises that the dbus timeout expires waiting for user to input username and password. This happens as the timeout includes the time for cstub to execute. The attached patch, which borrows from NetworkManager 1.4.2, increases the timeout to allow for more time for cstub to execute and the user to provide input.

Revision history for this message
Tom Carroll (h-thomas-carroll) wrote :

More information:

dpkg -l network-manager
network-manager 1.2.2-0ubuntu0.16.04.3

lsb_release -a
No LSB modules are available.
Distributor ID: LinuxMint
Description: Linux Mint 18 Sarah
Release: 18
Codename: sarah

Revision history for this message
Tom Carroll (h-thomas-carroll) wrote :

Default timeout is 25s, increased to 120s

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.