Connecting to VPN times out after 25 seconds if login credentials not entered

[Viktor Pal]

Connecting to OpenConnect VPN through the Gnome GUI fails because NetworkManager times out while requesting credentials through the GUI form in Ubuntu 16.04.

It worked (is working on other computers I'm working on) fine from Ubuntu 12.04-15.10.

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: network-manager-openconnect 1.0.2-1build1
ProcVersionSignature: Ubuntu 4.4.0-21.37-generic 4.4.6
Uname: Linux 4.4.0-21-generic x86_64
ApportVersion: 2.20.1-0ubuntu2
Architecture: amd64
CurrentDesktop: GNOME
Date: Tue Apr 26 22:06:41 2016
SourcePackage: network-manager-openconnect
UpgradeStatus: No upgrade log present (probably fresh install)

[Viktor Pal (deere)]

I can create the connection and I can also see it i the list in Gnome, but when I enter my credentials it just doesn't connect and there is no error message shown or written to the logs.

[Mike Miller (mtmiller)]

So to clarify, you are reporting that you are able to create and edit OpenConnect VPN connections, but connecting does not work. That is much different from the links you refer to, which mostly seem to be about #1571300.

Can you confirm that the bug you experience is different from #1571300?

[Viktor Pal (deere)]

I also realized that meanwhile and removed the links from the comment.
So, yes I can see and edit the connections in "gnome-control-center network" and can also initiate the connection.
The usual window pops up asking for my connections after I provide them and click on login the window disappears and nothing happens.
I'm using gnome-shell.
Connecting form command line works.

[Mike Miller (mtmiller)]

Please take a look at https://wiki.ubuntu.com/DebuggingNetworkManager and try to submit some logs that show NetworkManager's error message when trying to connect to the VPN.

[Mike Miller (mtmiller)]

Now that the latest version is published, can you try updating to 1.2.0-1 from the yakkety repository and see if it resolves your connection problems?

Packages are available from https://launchpad.net/ubuntu/+source/network-manager-openconnect/1.2.0-1

[Julien Olivier (julo)]

I've just tested this new version and it doesn't help.

[Viktor Pal (deere)]

I installed these packages from https://launchpad.net/ubuntu/+source/network-manager-openconnect/1.2.0-1/+build/9644953 and restarted network manager daemon and still all the same:
network-manager-openconnect_1.2.0-1_amd64.deb
network-manager-openconnect-gnome_1.2.0-1_amd64.deb

Additional info:
When the login fails the authentication window does not close and reports failed login.
So it can report failed logins, but when login succeeds the situation is as described above.

[Viktor Pal (deere)]

Why is this bug incomplete? What additional information do you need?

I'm happy to provide you anything I'm able to to get this fixed.
This is a critical bug (at least for me) that destroys productivity and prevents users to do daily work on Linux.
And the most annoying thing is that this was working for several years (at least 5) mostly properly and now it just doesn't.
I can live with this for some time and use command line, but I really hope that this bug will be taken seriously in an LTS release.

Thanks a lot and sorry for my words but I'm really disappointed.

[Mike Miller (mtmiller)]

Viktor, thanks for following up. If you'd like to help resolve this, some debug logs from NetworkManager would be helpful.

Are any messages shown if you run "nmcli con up VPN-NAME"? Does the connection fail in the same way?

I am unable to reproduce in a freshly installed 16.04 system with the NM-openconnect 1.2.0 version pulled from the 16.10 repository.

[Julien Olivier (julo)]

Mike: here's what I get using nmcli:

juloliv@juloliv:~$ LANG=C nmcli --ask con up XXX
POST https://sslvpn.XXX-en.com/
Attempting to connect to server X.X.X.X:443
SSL negotiation with sslvpn.XXX.com
Connected to HTTPS on sslvpn.XXX.com
Got HTTP response: HTTP/1.0 302 Temporary moved
GET https://sslvpn.XXX.com/
Attempting to connect to server X.X.X.X:443
SSL negotiation with sslvpn.XXX.com
Connected to HTTPS on sslvpn.XXX.com
Got HTTP response: HTTP/1.0 302 Temporary moved
GET https://sslvpn.XXX.com/+webvpn+/index.html
SSL negotiation with sslvpn.XXX.com
Connected to HTTPS on sslvpn.XXX.com
Please enter your username and password.
Username:XXX
Password:
POST https://sslvpn.XXX.com/+webvpn+/index.html
Error: Connection activation failed: the VPN service returned invalid configuration.

This used to work flawlessly before.

[Mike Miller (mtmiller)]

Viktor: Do you see the same as Julien?

Julien: Can you provide NetworkManager logs with debug logging enabled?

[Viktor Pal (deere)]

Greetings,

I successfully (accidentally) caught and reproduced the issue.
All the commands were run as regular non-root user.

1.) So what I first did is:
###############################################
$ nmcli con up VPN-NAME
A password is required to connect to 'VPN-NAME'.
Warning: password for 'vpn.secrets.gateway' not given in 'passwd-file' and nmcli cannot ask without '--ask' option.
Error: Connection activation failed: no valid VPN secrets.
###############################################

What happened here is that the graphical credentials form showed up.
I started to type in my PIN and then opened the RSA app on my phone started to type in the TOKEN and meanwhile I got this error (you see above):
"Error: Connection activation failed: no valid VPN secrets."

2.) Then I got suspicions. Waited for the next TOKEN, typed the PIN and TOKEN into a text file, ran the same command, immediately copy pasted the PIN+TOKEN from the text file and it worked.

###############################################
$ nmcli con up VPN-NAME
A password is required to connect to 'VPN-NAME'.
Warning: password for 'vpn.secrets.gateway' not given in 'passwd-file' and nmcli cannot ask without '--ask' option.
VPN connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/3)
###############################################

3.) + 4.) I reproduced the same steps from the graphical interface with the same results.

So I was finally able to log in from gnome network app by being quick enough with the prepared credentials.

Please note that I never used the --ask option.

It pretty much seems that this is a timeout issue, NM times out while waiting for the credentials too early, if you are quick enough you are able to log in though.

I also removed and reinstalled those packages from the 16.04 repo and restarted network manager:
ii libopenconnect5:amd64 7.06-2build2 amd64 open client for Cisco AnyConnect VPN - shared library
ii network-manager-openconnect 1.0.2-1build1 amd64 network management framework (OpenConnect plugin)
ii network-manager-openconnect-gnome 1.0.2-1build1 amd64 network management framework (OpenConnect plugin GNOME GUI)
ii openconnect 7.06-2build2 amd64 open client for Cisco AnyConnect VPN

And it still keeps working.

I hope this helps.

[Mike Miller (mtmiller)]

Ok, so Viktor's bug is about timeout behavior when connecting with network-manager-openconnect using an RSA token.

Viktor: Would you update the description to reflect that, and also say which version of Ubuntu or of NetworkManager you were using previously when it did not have this problem? You might also want to report this upstream at https://bugzilla.gnome.org/enter_bug.cgi?product=NetworkManager&component=VPN:%20openconnect.

Julien: It looks like your bug is different, would you file a new bug report for your specific connection failure, and provide NetworkManager debug logs as requested?

[Mike Miller (mtmiller)]

So it looks like you are getting a failure in Ubuntu 16.04 but success in Ubuntu 15.10, even while both are using the same version of network-manager-openconnect, 1.0.2-1build1. So it's more likely that this is a change in the network-manager package between version 1.0.4 and 1.1.93 (aka 1.2-rc1),

I can't help much more with this bug, I can only help triage and point you in the right direction to continue working to resolve this. You should try either mailing the NetworkManager development list https://mail.gnome.org/mailman/listinfo/networkmanager-list or report a bug upstream at https://bugzilla.gnome.org/enter_bug.cgi?product=NetworkManager.

[Viktor Pal (deere)]

Okay, just to have some technical evidence here, the difference between the timeouts on 15.10 and 16.04.
What did was that I just ran these commands and did input nothing in the credentials GUI and waited until it times out.

15.10:
$ time nmcli con up VPN-NAME
Error: Timeout 90 sec expired.

real 1m30.583s
user 0m0.072s
sys 0m0.016s

16:04:
$ time nmcli con up VPN-NAME
A password is required to connect to 'VPN-NAME'.
Warning: password for 'vpn.secrets.gateway' not given in 'passwd-file' and nmcli cannot ask without '--ask' option.
Error: Connection activation failed: no valid VPN secrets.

real 0m25.185s
user 0m0.044s
sys 0m0.020s

[Mike Miller (mtmiller)]

I can confirm a 25 second timeout by trying to connect to a VPN, either OpenConnect or OpenVPN, and not entering my password at the prompt. I am not sure where this timeout comes from, but it is independent of any VPN service, so updating summary again and reassigning to network-manager.

[Sebastien Bacher (seb128)]

Could somebody upstream that bug on bugzilla.gnome.org?

[Viktor Pal (deere)]

Will do that in the next days.

[Julien Olivier (julo)]

Mike, here's what I get in /var/log/syslog after trying to connect to the VPN. Could you tell me if this is the same bug or if I need to file another one?

[Dmitry-a-durnev (dmitry-a-durnev)]

I confirm the same issue with 25s timeout - if I type login/password quickly enough, then vpn connection(openconnect, nmcli 1.2.0-1) is successfully established. Maybe some known workaround exists?

[Viktor Pal (deere)]

Upstream bug: https://bugzilla.gnome.org/show_bug.cgi?id=767667

[Ivan (ivan-zderadicka)]

Hi,
for me this bug is absolutely critical - because it I'm not able to type in credentials since majority of time is taken by connection to server - so I have something like 5-7 secs to write credentials.
So basically now I cannot use VPN which is absolutely critical for me.
It works fine in 14.04, so why it's broken now - can you fix it with priority?
Thanks

[Jeremy Hoyland (jhoyland)]

I have also hit this bug in latest version of Linux Mint 18. I can confirm that the timeout has somehow reverted to 25 seconds, while previous versions of network manager allowed much longer.

Note that the timeout is overall from the moment of the first POST to the VPN address.

Our corporate VPN gateway redirects to the nearest VPN available. Assigning this new redirect takes almost all of the 25 seconds. Occasionally one can type in username/password and get in under the 25 sec bar. If the 25 seconds started from the actual VPN negotiation it would work just fine.

Using the command:
sudo openconnect -u myusername mycorporate.accessaddress.com

..allows me to launch my vpn session manually. It also prints out the redirect address, and I can then create a new network-manager vpn connection with this address, which connects much faster. I am using this as a workaround for the time being.

[Tom Carroll (h-thomas-carroll)]

I'm affected by this problem too. The attached patch resolves the problem by increasing the timeout network manager waits for password input.

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "increase waiting time for secret input" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]