Openconnect will not connect under Saucy -- openssl problem?

[Mike Stucka]

I'd been stable under 13.04, but the installed version of openconnect 5.01 is broken under 13.10.

Under 13.10, I've confirmed openconnect works on an older version (4.08) that I compiled from source.

With the stock 5.01, I get "Login failed: Your account does not have VPN rights" under commandline and under network manager.

I'm wondering if part of the problem comes from an error message if I try to compile 5.01 from source:
checking for known-broken versions of OpenSSL... yes
configure: error: This version of OpenSSL is known to be broken with Cisco DTLS.
See http://rt.openssl.org/Ticket/Display.html?id=2984&user=guest&pass=guest
Add --without-openssl-version-check to configure args to avoid this check, or
perhaps consider building with GnuTLS instead.

Unfortunately, the packaged openssl (1.0.1e) of February 2013 is the most recent version, so there's nothing newer to test against.

Mike

ProblemType: Bug
DistroRelease: Ubuntu 13.10
Package: openconnect 5.01-1
ProcVersionSignature: Ubuntu 3.11.0-8.15-generic 3.11.1
Uname: Linux 3.11.0-8-generic i686
ApportVersion: 2.12.4-0ubuntu1
Architecture: i386
Date: Mon Sep 23 09:28:14 2013
InstallationDate: Installed on 2013-05-22 (123 days ago)
InstallationMedia: Xubuntu 12.04.2 LTS "Precise Pangolin" - Release i386 (20130213)
MarkForUpload: True
SourcePackage: openconnect
UpgradeStatus: Upgraded to saucy on 2013-09-20 (2 days ago)

[Mike Stucka (mstucka)]

I get the same problem if I compile 5.01 manually by forcing GnuTLS (configure with options including --with-gnutls --without-openssl-version-check).

[Launchpad Janitor (janitor)]

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

[Mike Miller (mtmiller)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. Unfortunately I am unable to reproduce this connection failure with this version of openconnect and the VPN gateway that I use. There is definitely not the speculated problem with the OpenSSL library as compiled for Ubuntu, it already has the patch from the referenced upstream bug report applied. You have not mentioned what the error message is or in what way openconnect is broken. Can you provide some more information to help us work on this problem?

1) Can you provide the full output of attempting to connect with "openconnect --verbose"? You can sanitize host names or addresses if you like.

2) Are you able to connect to the VPN gateway with "openconnect --no-xmlpost"?

3) Are you able to connect to the VPN gateway using the Cisco AnyConnect client?

[Mike Miller (mtmiller)]

Also

4) Are you still able to connect to the VPN gateway using an older version of openconnect? Either using an earlier Ubuntu release or by compiling an older version of openconnect from source?

[Mike Stucka (mstucka)]

Preface: I've had this problem with the one server, but VMs on two different machines and one Xubuntu machine.

4) Yes, it works if I compile openconnect 4.08 from source. When I compile openconnect 5 from source using gnutls, I get the identical error as the Ubuntu-distributed version. Oddly, sometimes the error message seems to have stray random characters around it. But not always, and they can be at the end or beginning of the string. Could Unicode problems somehow be in play?

3) No, hadn't tried Cisco client -- a Windows version of the thing won't install on my work machine and the forums all say to reimage Windows, so I don't want to introduce that when I don't have to.

2) --no-xmlpost is working! Yay! Dunno what this means, but I'm most grateful.

1)root@mikelight:~# openconnect --verbose serverserver
POST https://serverserver
Attempting to connect to server 1somethingsomething:443
SSL negotiation with serverserver
Connected to HTTPS on serverserver
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: Sat, 05 Oct 2013 12:19:46 GMT
X-Aggregate-Auth: 1
HTTP body chunked (-2)
XML POST enabled
GROUP: [1-....:7-something
Username:domain\user
Password:
POST https://serverserver/
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: Sat, 05 Oct 2013 12:19:56 GMT
X-Aggregate-Auth: 1
HTTP body chunked (-2)
Login failed: Your account does not have VPN rights
GROUP:

[Mike Miller (mtmiller)]

Good to see that specifying the --no-xmlpost option solves this problem for you. Is that an acceptable solution for you?

If you are running openconnect via the NetworkManager connection tool, this option is not yet exposed in the connection editor. So you'll have to use openconnect on the command line to add this option for now.

[Mike Stucka (mstucka)]

OK, so maybe we need to merge this with bug 1202204, or at least refer.

But per http://www.infradead.org/openconnect/manual.html , the need for this is a bug. Does it make sense to distribute this with a bug, with no GUI workaround, as the default?

[Vince N (libertyshadow)]

From the --dump-http output, it seems that the XML transaction is selecting incorrect tunnel-group and group-alias.

I attempted to patch a --no-xmlpost option into network-manager-openconnect, but in the process I figured out a strange workaround...

I am currently instructing my Ubuntu 13.10 users to press the 'connect' button in network-manager-openconnect TWICE RAPIDLY. For some reason, after the SSL socket is closed unexpectedly during the first connection attempt, the second attempt doesn't use XML Post, and authentication succeeds.

[Kevin Cernekee (cernekee)]

> I attempted to patch a --no-xmlpost option into network-manager-openconnect

FWIW, I submitted a patch[1] to add an openconnect_set_xmlpost() library function (for unrelated reasons tied to CSD/Hostscan). So on the GUI side you would just need a checkbox in the glade xml, code to save/restore/export/import the setting, and code to call the library function with the right value.

However, a better long-term solution for the group alias problem is to have the library resend the initial XML POST request with a different authgroup name when needed. Then somehow re-render the form.

One possibility might be to return a special value from the process_auth_form() callback to indicate that the UI is just requesting a group change, not submitting the whole form.

David W has also indicated that he wants to tackle the secondary password problem at the same time. I have not looked into this yet.

[1] http://lists.infradead.org/pipermail/openconnect-devel/2013-October/001243.html

[db (damianbcpetro)]

running openconnect --no-xmlpost <myvpnserver> in the terminal works for me too

[Steve Ringley (gringley)]

Running openconnect --no-xmlpost <myvpnserver.com/vpn> in the terminal works for me too. So for me the ones that work in Saucy/5.01 allow you to land on the FQDN or IP address. The ones that require a true URL (vpn.com/vpn) fail unless the --no-xmlpost option is used.

[Mike Stucka (mstucka)]

Steve, I can confirm that my problem does not require anything more than
the FQDN -- it's a straight shot to somethingvpn.something.com, not
somethingvpn.something.com/something. I also tried a connect via IP address
and that didn't work.

Dumb question, and (presumably) not directly related to this bug -- should
apt-get be checking to see whether network-manager is installed? I just
installed openconnect on an Xubuntu VM and network-manager-openconnect
wasn't even a recommendation.

Mike

On Sun, Nov 3, 2013 at 1:31 AM, Steve Ringley <email address hidden> wrote:

> Running openconnect --no-xmlpost <myvpnserver.com/vpn> in the terminal
> works for me too. So for me the ones that work in Saucy/5.01 allow you
> to land on the FQDN or IP address. The ones that require a true URL
> (vpn.com/vpn) fail unless the --no-xmlpost option is used.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1229195
>
> Title:
> Openconnect will not connect under Saucy -- openssl problem?
>
> Status in “openconnect” package in Ubuntu:
> Incomplete
>
> Bug description:
> I'd been stable under 13.04, but the installed version of openconnect
> 5.01 is broken under 13.10.
>
> Under 13.10, I've confirmed openconnect works on an older version
> (4.08) that I compiled from source.
>
> With the stock 5.01, I get "Login failed: Your account does not have
> VPN rights" under commandline and under network manager.
>
> I'm wondering if part of the problem comes from an error message if I
> try to compile 5.01 from source:
> checking for known-broken versions of OpenSSL... yes
> configure: error: This version of OpenSSL is known to be broken with
> Cisco DTLS.
> See
> http://rt.openssl.org/Ticket/Display.html?id=2984&user=guest&pass=guest
> Add --without-openssl-version-check to configure args to avoid this
> check, or
> perhaps consider building with GnuTLS instead.
>
> Unfortunately, the packaged openssl (1.0.1e) of February 2013 is the
> most recent version, so there's nothing newer to test against.
>
>
> Mike
>
> ProblemType: Bug
> DistroRelease: Ubuntu 13.10
> Package: openconnect 5.01-1
> ProcVersionSignature: Ubuntu 3.11.0-8.15-generic 3.11.1
> Uname: Linux 3.11.0-8-generic i686
> ApportVersion: 2.12.4-0ubuntu1
> Architecture: i386
> Date: Mon Sep 23 09:28:14 2013
> InstallationDate: Installed on 2013-05-22 (123 days ago)
> InstallationMedia: Xubuntu 12.04.2 LTS "Precise Pangolin" - Release i386
> (20130213)
> MarkForUpload: True
> SourcePackage: openconnect
> UpgradeStatus: Upgraded to saucy on 2013-09-20 (2 days ago)
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/openconnect/+bug/1229195/+subscriptions
>

--

Mike Stucka
Staff Writer
The Telegraph
[phone] office
[phone] cell
[phone] fax

[Mike Miller (mtmiller)]

With regards to network-manager, no apt-get should not pull in network-manager components for the openconnect package.

If you want plain openconnect from the command line, which is perfectly suitable for many, install the openconnect package.

If you want Unity or GNOME network-manager VPN support, install network-manager-openconnect-gnome.

If you want KDE network-manager VPN support, install plasma-nm.

[Mike Miller (mtmiller)]

Changing status back to confirmed since it is being called a bug if the --no-xmlpost option is required to connect successfully.

[Gaspar (gaspar-ag)]

Just a word to let you knoy I really love the work you are doing!

After updating from raring to saucy, I was having the same error and now it works OK with the "--no-xmlpost" option

This is the verbose version of the error I was getting:

phe@sanlap:~$
phe@sanlap:~$
phe@sanlap:~$ sudo /usr/sbin/openconnect --verbose --script /etc/vpnc/vpnc-script --user=phe --certificate=/home/phe/phe.pem https://por.virtualdata.fon.com/dsn
[sudo] password for phe:
POST https://por.virtualdata.fon.com/dsn
Attempting to connect to server 82.42.2.21:443
Using certificate file /home/phe/phe.pem
Enter PEM pass phrase:
Using client certificate 'phe'
SSL negotiation with por.virtualdata.fon.com
Connected to HTTPS on por.virtualdata.fon.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: Keep-Alive
Date: Tue, 05 Nov 2013 12:06:21 GMT
X-Aggregate-Auth: 1
HTTP body chunked (-2)
XML POST enabled
Password:
POST https://por.virtualdata.fon.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: Keep-Alive
Date: Tue, 05 Nov 2013 12:06:28 GMT
X-Aggregate-Auth: 1
HTTP body chunked (-2)
Login failed.
Password:

Now it works OK with the "--no-xmlpost" option. I prefer the command line over the graphical interface, so this solution is perfect for me.

Thanks again !

[MorrisseyJ (morrissey-james1)]

Would it be possible for someone to provide some instructions for running openconnect from the command line?

There are some relative noobs who are not sure how to do this exactly and who find the instructions from the terminal and here (http://www.infradead.org/openconnect/manual.html) a little confusing.

Issue is also being discussed on the ubuntuforums: http://ubuntuforums.org/showthread.php?t=2182544

Any help at all would be very much appreciated.

Thanks,

j

[Cherif Tawil (c-tawil-home)]

Hi MorrisseyJ
Try this from the command line - you need root or sudo here

sudo openconnect --no-proxy https://<gateway>

Regards
Cherif

[MorrisseyJ (morrissey-james1)]

Wonderful, thanks.

James.

[Joseph McDonald (x-joe)]

Is there a fix coming for the network-manager-openconnect so that I can connect via the GUI and know VPN status?

I have to use the --no-xmlpost option on the command line, otherwise I get placed in the first GROUP. Problem is commandline requires me to enter my group and username and password every time I need to connect to the VPN. I've tried to automate it with a shell script but it doesn't work.

I am on ubuntu 13.10

[Cory F. Cohen (cfcohen)]

I don't know if this should be a separate ticket, but I also have a confirmed case where --no-xmlpost corrects the problem. I need to specify --authgroup XXX where XXX is NOT one of the valid options listed in the response from the sever. The server probably shouldn't be setup that way, but it's not under my control. :-( By looking at the code in auth.c, it appears that the user supplied authgroup is now validated against the list returned from the server as part of the xmlpost code. Adding --no-xmlpost corrects the problem because there's no list to validate against. I propose as a fix that when specified explicitly, that openconnect attempt to use the specifed authgroup value before rejecting it as invalid.

The problem appeared during an Ubuntu 13.04 to 13.10 upgrade.
The version of openconnect requiring the --no-xmlpost option is:
OpenConnect version v5.01
Using GnuTLS. Features present: PKCS#11, TOTP software token, DTLS (using OpenSSL)

[Kevin Cernekee (cernekee)]

"I need to specify --authgroup XXX where XXX is NOT one of the valid options listed in the response from the sever. The server probably shouldn't be setup that way, but it's not under my control."

Does this server work with the Cisco AnyConnect clients, or only OpenConnect?

Perhaps it breaks on Cisco clients that use XML POST, like AnyConnect Linux 3.1.00495 or AnyConnect Windows 3.0.08057? AFAIK the Cisco clients can only send an authgroup name that is in the dropdown list.

"Is there a fix coming for the network-manager-openconnect so that I can connect via the GUI and know VPN status?"

I prototyped a fix for libopenconnect; I'll submit to the openconnect-devel list this weekend if all goes well. It requires an API change.

[Cory F. Cohen (cfcohen)]

Kevin Cernekee asked whether this works with Cisco AnyConnect clients. Apparently the Cisco clients will allow you to type in a value that does not appear in the drop-down menu (I know of others using this client, but I am not.) It's possible that this connection configuration will be broken when we upgrade the Cisco clients to a newer version. Does that answer your question addressed to my post? I think that the intention was to "hide" the authgroup so that people didn't select it accidentally.

[Kevin Cernekee (cernekee)]

Cory: "By looking at the code in auth.c, it appears that the user supplied authgroup is now validated against the list returned from the server as part of the xmlpost code. Adding --no-xmlpost corrects the problem because there's no list to validate against."

The current --authgroup implementation can only select options that appear in the list. See:

http://git.infradead.org/users/dwmw2/openconnect.git/blob/refs/tags/v5.01:/main.c#l1099

If the provided string does not match choice->label (for some value of choice) it will be rejected. This is true with or without --no-xmlpost.

Perhaps there is another configuration issue causing different group lists to be returned for xmlpost vs. no xmlpost?

Could you please post or email me the server's hostname?

Joseph: "Is there a fix coming for the network-manager-openconnect so that I can connect via the GUI and know VPN status?"

I have submitted another round of patches here:

http://lists.infradead.org/pipermail/openconnect-devel/2013-December/001390.html

If you have the ability to test or review these changes I would appreciate the feedback.

[Cory F. Cohen (cfcohen)]

Kevin, I've been away on vacation for two weeks. Sorry for the delay in responding. What I really know is that the --no-xmlpost option fixed it somehow. I assumed it was related to the code that I looked at briefly that you appear to have also found restricting to auth group to the choices returned by the server. I assumed that --no-xmlpost somehow caused that entire piece of code to be skipped, but I never saw where that actually occurred. I propose that at least one fix would be to generate a warning (instead of failing) during that validation.

I don't think the server returns the choice I'm using either way, but it does accept the value when it is explicitly specified. The server is not public, and I doubt that providing the name would be of much use to you.

[Kevin Cernekee (cernekee)]

"What I really know is that the --no-xmlpost option fixed it somehow."

Could you please post the output from running:

openconnect --no-xmlpost --dump-http-traffic <SERVER>

openconnect --dump-http-traffic <SERVER>

No need to actually log in - the forms will suffice.

[Cory F. Cohen (cfcohen)]

Here's the one that works...

[Cory F. Cohen (cfcohen)]

And the one that doesn't... The values of several fields have been altered, but I attempted to do so consistently, so you should be able to figure it out.

[Kevin Cernekee (cernekee)]

@Cory

Basically there are two ways the ASA administrator can allow clients to select an authgroup (aka tunnel-group, aka Connection Profile):

1) Set up a group-alias for the tunnel-group, and turn on tunnel-group-list to show the dropdown menu:

    ciscoasa(config-webvpn)# show run webvpn
    webvpn
     enable outside
     anyconnect image disk0:/anyconnect-win-3.0.5080-k9.pkg 1
     anyconnect enable
     tunnel-group-list enable

    ciscoasa(config-webvpn)# show run tunnel-group
    tunnel-group default type remote-access
    tunnel-group default webvpn-attributes
     proxy-auth sdi
     group-alias d enable

When the dropdown menu appears on the auth form, openconnect will use the --authgroup parameter (if present) to match the group label "d" and fill it in automatically:

    < <select name="group_list" label="GROUP:">
    < <option selected="true">d</option>
    < </select>

The current (git.infradead.org) openconnect HEAD of tree still has some issues with authgroup selection when XML POST is enabled, but we're converging on a solution. This isn't relevant to your situation, however.

2) Set up a group-url, so clients who navigate directly to that URL do not see a dropdown at all:

    ciscoasa(config-webvpn)# show run tunnel-group
    tunnel-group default type remote-access
    tunnel-group default webvpn-attributes
     proxy-auth sdi
     group-url https://asa/hidden-d enable

Since there is no dropdown menu (<select> node) in this case, specifying --authgroup doesn't actually do anything. You should be able to safely omit it.

Note that the same tunnel-group (or different sets of tunnel-group's) can be selected through both methods, and the group-alias doesn't need to match the path in the group-url.

I set up both types of groups locally, and verified that the issue shown in your log was fixed by this commit from the openconnect HEAD of tree:

    commit 06ac20e005b6caba0a58fca13346ad01ae0989c5
    Author: Murilo Opsfelder Araujo <email address hidden>
    Date: Thu Sep 12 14:53:54 2013 -0300

        Append vpninfo->urlpath to <group-access>

        Some ASA gateways may need the relative path specified in <group-access> XML
        entry so it makes sense to verify if it exists and append it.

        Signed-off-by: Murilo Opsfelder Araujo <email address hidden>
        Signed-off-by: David Woodhouse <email address hidden>

On v5.01, the <group-access> node is missing the URL path:

    > POST /AUTHGROUP HTTP/1.1
    > Host: HOSTNAME
    [...]
    <group-access>https://HOSTNAME</group-access>

so in XML POST mode on v5.01 you are only able to use the groups that have a group-alias defined, not the group(s) which need to be accessed via group-url. This will be fixed in the next release.

Hope that clears things up...

For further reading: http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a00808bd83d.shtml

[Launchpad Janitor (janitor)]

This bug was fixed in the package openconnect - 5.02-1

---------------
openconnect (5.02-1) unstable; urgency=medium

  * New upstream release.
    - Temporarily disable XML POST if an authgroup dropdown exists.
      (LP: #1229195)
  * doc-remove-footer.patch: Remove footer from HTML doc template, it
    links to images from www.w3.org.
  * debian/control: Use lowercase for package synopsis.
  * debian/copyright: Fix some omissions in the copyright listing.
  * debian/rules: No need to explicitly set CFLAGS/CPPFLAGS/LDFLAGS.
  * debian/watch: Add support for verification of PGP signature on
    upstream release.
  * Use my @debian.org address.
  * Bump Standards-Version to 3.9.5. No changes needed.

 -- Mike Miller <email address hidden> Sun, 12 Jan 2014 15:30:14 -0500

[Jaceq (dzacek83)]

Hello,

I have installed 5.02-1 yet I still get the same problem.

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

When I connect on command line with --no-xmlpost it works.

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

[Mike Miller (mtmiller)]

Jaceq, in your last comment you say that you can connect on the command line with --no-xmlpost. Are you able to connect to your gateway on the command line without adding the --no-xmlpost option using 5.02-1?

[dwmw2 (dwmw2)]

On Wed, 2014-01-22 at 13:35 +0000, Jaceq wrote:
> 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.

That looks like normal gnome-shell brokenness, with the VPN
authentication agents not working. Nothing to do with openconnect
itself, or xmlpost. We aren't getting that far.

--
dwmw2

[Jaceq (dzacek83)]

Ah, yes now I can connect to my gatway without --no-xmlpost (which was not working with 5.01-1)

So... should I open a new bug or is anyone aware of existing one?
I use KDE NM applet...

[Perham (perham-x)]

I still can't connect without --no-xmlpost, and I can't seem to find a way to make networkmanager to pass that argument to openconnect. one would think since this is linux, there should be a config file for that, but there isn't.

[Perham (perham-x)]

and since it is not working for some of us, even with version 5.02, then fix is not released. please change the status.

[Kevin Cernekee (cernekee)]

@Perham

Could you please post or email logs for both the --no-xmlpost and normal cases, using the command line client v5.02?

Thanks.

[Toby Murray (toby-murray)]

For what it's worth, I just manually downloaded the 5.02 packages and installed them on a Linux Mint 16 laptop. It didn't work after I first installed the packages but after a reboot it worked. I'm guessing the network-manager was hanging on to the 5.01 lib files somewhere.

[Mike Stucka (stucka)]

For what it's worth, as the original version the patched version has worked perfectly fine for me under Ubuntu 13.10, and I'd used it several times under pre-release versions of Ubuntu 14.04 without problems.

Mike

[Mike Stucka (stucka)]

@toby-murray : My bad -- I didn't mean to steal your FWIW opening. Your post reminded me to post back.

I haven't used Linux Mint, but if I recall correctly, you may be able to force a dynamic library refresh by running ldconfig as root. That'll change the dynamic library config, and might have taken care of that problem.

[Terry Zhou (zhouxc)]

Just FYI. With 14.04 I can connect to vpn server, but I found ssh to internal servers didn't work, nor opened https website. It turns out the MTU of vpn server hasn't been honored by openconnect anymore, you can see below X-CSTP-MTU: 1347, while it's set to X-DTLS-MTU: 1418, after change vpn internface MTU to 1347, ssh and https are working fine. It's a regression after upgrade to 14.04 from 13.10.

X-CSTP-Lease-Duration: 86400
X-CSTP-Session-Timeout: 86400
X-CSTP-Idle-Timeout: 21600
X-CSTP-Disconnected-Timeout: 21600
X-CSTP-Keep: true
X-CSTP-Tunnel-All-DNS: false
X-CSTP-DPD: 30
X-CSTP-Keepalive: 20
X-CSTP-Smartcard-Removal-Disconnect: true
X-DTLS-Session-ID: 4A623D752E87AFB342E349390D22AC2CF090A9F313FC1DF107BCDBA7FA749019
X-DTLS-Port: 443
X-DTLS-Keepalive: 20
X-DTLS-DPD: 30
**X-CSTP-MTU: 1347**
**X-DTLS-MTU: 1418**
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
CSTP connected. DPD 30, Keepalive 20

[Friedemann Schorer (friedemann-schorer)]

Any news on this one?

[Mike Miller (mtmiller)]

Friedemann, as far as I can tell the original bug reported here was fixed with version 5.02-1. If you are experiencing problems with OpenConnect in a currently supported Ubuntu release or in the current development release, please open a new bug report. See https://help.ubuntu.com/community/ReportingBugs.