9

In the past I could connect to a certain Cisco VPN server. I've been away travelling for 7 weeks, and now I'm back home, but no longer able to connect to the VPN server. Today the server suddenly asks me to run a 'Cisco Secure Desktop' trojan, and I've configured OpenConnect to do this (both via a GUI dialog, and the --csd-user command line option to openconnect), still I'm no longer able to get the VPN connection working.

The VPN connection log ends with these four lines repeated over and over again:

GET https://vpn.server.com/+CSCOE+/sdesktop/wait.html
SSL negotiation with vpn.server.com
Connected to HTTPS on vpn.server.com
Refreshing +CSCOE+/sdesktop/wait.html after 1 second...

Do you have any idea about what's happening or how I can fix this?

Would you guess that the problem is a VPN server side configuration change? The 'Cisco Secure Desctop' script perhaps? The VPN server has never asked me to run the 'Cisco Secure Desktop' script before, when I was able to connect. — Or do you think my OS has upgraded OpenConnect to a somehow incompatible version?

"Refreshing .../sdesktop/wait.html", what's that, why? And +CSCOE+, sounds weird.

My OS: Linux Mint 17. OpenConnect version v5.02. Other people are able to connect to the VPN server — they use Mac or Windows, not Linux, though.

Here's the full OpenConnect log:

POST https://vpn.server.com/
Attempting to connect to server 111.222.333.444:443
Using client certificate 'My-Full-Name'
Adding supporting CA 'TC TrustCenter Class 2 L1 CA XI'
SSL negotiation with vpn.server.com
Connected to HTTPS on vpn.server.com
Got HTTP response: HTTP/1.0 302 Object Moved
GET https://vpn.server.com/
Attempting to connect to server 111.222.333.444:443
SSL negotiation with vpn.server.com
Connected to HTTPS on vpn.server.com
Got HTTP response: HTTP/1.0 302 Object Moved
GET https://vpn.server.com/+webvpn+/index.html
SSL negotiation with vpn.server.com
Connected to HTTPS on vpn.server.com
GET https://vpn.server.com/CACHE/sdesktop/install/binaries/sfinst
GET https://vpn.server.com/+CSCOE+/sdesktop/wait.html
Refreshing +CSCOE+/sdesktop/wait.html after 1 second...
GET https://vpn.server.com/+CSCOE+/sdesktop/wait.html
SSL negotiation with vpn.server.com
Connected to HTTPS on vpn.server.com
Refreshing +CSCOE+/sdesktop/wait.html after 1 second...
GET https://vpn.server.com/+CSCOE+/sdesktop/wait.html
SSL negotiation with vpn.server.com
Connected to HTTPS on vpn.server.com
Refreshing +CSCOE+/sdesktop/wait.html after 1 second...
GET https://vpn.server.com/+CSCOE+/sdesktop/wait.html
SSL negotiation with vpn.server.com
Connected to HTTPS on vpn.server.com
Refreshing +CSCOE+/sdesktop/wait.html after 1 second...
GET https://vpn.server.com/+CSCOE+/sdesktop/wait.html
SSL negotiation with vpn.server.com
Connected to HTTPS on vpn.server.com
Refreshing +CSCOE+/sdesktop/wait.html after 1 second...
(... continues forever)

I read here that I could wrap the 'Cisco Secure Desktop' script in a shell script, via the --csd-wrapper option; the suggested script looks like so:

#!/bin/bash -x
exec 2>&1 > /dev/null
CSD_BINARY="$1"
shift
$CSD_BINARY "$@"

This didn't have any effect though.

I've also tested the --no-xmlpost flag, as suggested here, no effect.

Someone suggest to install 32 bit support, but apparently my OS already has that:

$ dpkg --print-foreign-architectures
i386

Here is someone else who has encountered the same problem. It's a ServerFault question, but it was apparently deleted at ServerFault, off-topic over there I'd guess. There were no answers to the question.

Edit With the -v (verbose) flag, openconnect keeps repeating these lines:

$ openconnect -v -c cert.pem --csd-user=kajmagnus vpn.example.com
...
GET https://vpn.example.com/+CSCOE+/sdesktop/wait.html
SSL negotiation with vpn.example.com
Connected to HTTPS on vpn.example.com
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: Close
Date: Thu, 06 Nov 2014 11:10:18 GMT
HTTP body chunked (-2)
Refreshing +CSCOE+/sdesktop/wait.html after 1 second...
Improve this question
1

3 Answers 3

Reset to default
3

The problem is that the VPN server has been modified to no longer support Linux, and all old certificates have been invalidated, I just found out.

So I think there were two problems causing the weird error messages: 1) Linux not supported, and 2) wrong certificate.

Improve this answer
1

I had a similar problem but was able to get my Fedora Core 25 machine to connect to work's VPN by following an answer given on Ask Ubuntu. I know this is an old question, but since it still comes up early in search engines, I wanted to post something that forwards to a solution.

Unless you edited the output from openconnect, your problem might have been that you followed the examples too closely. You were trying to connect to "vpn.example.com" instead of your corporate VPN server.

Improve this answer
2
  • Hi David, actually I've posted an answer on this page already, clarifying what turned out to be the problem in my case, here: superuser.com/a/836703/95772 (the problem was not typing example.com literally — the reason I edited the output, is I didn't want the name of the related company to appear in this question)
    – KajMagnus
    Commented Mar 12, 2017 at 12:44
  • I saw your answer, but since I had the same output as you had (albeit a different server), I was hoping that the link I provided would help you, like it helped me. Even if it doesn't, it may help other people like me who get the same output as you got, but whose AnyConnect server is compatible with GNU/Linux. For what it's worth, I switched my functional csd-wrapper.sh to match what you used and got the same output as you. It's possible that the openconnect team fixed something in the intervening two years.
    – David Costanzo
    Commented Mar 14, 2017 at 0:49
0

My organization updated the Cisco VPN server at midnight last night, and being online at the time, lost connectivity to the project I was in, losing 2 hours of work.

Not pleased, I started looking for a solution.
I discovered that NetworkManager has an openconnect plugin, and tried it. No success. But, I did a search (sudo apt search openconnect) and found there is another plugin called network-manager-openconnect-gnome and installed it.

There are a lot more options, and I was able to come up with a combination that worked.

If you point your cursor at the "Save" button, which was grayed-out.

It tells you what's invalid about your config, which in my case was Proxy. In the gnome version, there is a proxy tab, and a proxy setting on the main page, too. Try various combinations that apply to your previously working setup of openconnect.
And good luck. For my setup, on the main page, or Identity page, the proxy field is blank.

I'm using wpad.dat/wpad on the Proxy tab in the settings, but that never worked here. I also manually configure the proxy settings in the general network setup.
Furthermore, I have to use a considerable number of "no-proxy" entries to get everything to work I need access to.

Improve this answer
1
  • 2
    Could you perhaps use some formatting, use of carriage returns, etc, to make this wall o' text a bit more clear?
    – music2myear
    Commented May 1 at 22:18

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .