Bug 981911

+++ This bug was initially created as a clone of Bug #964329 +++

Description of problem:
When connecting to a Cisco VPN using openconnect get the following error 
XML response has no "auth" node 
Seems to be a known issue with upstream 
http://comments.gmane.org/gmane.network.vpn.openconnect.devel/517


Version-Release number of selected component (if applicable):


How reproducible:




Steps to Reproduce:
1.
2.
3.
  
Actual results:
XML response has no "auth" node 

Expected results:
Established connection


Additional info:

--- Additional comment from David Woodhouse on 2013-05-23 15:24:06 EDT ---

This should be fixed in the 5.00 release, made a few days ago. Unfortunately another compatibility issue has surfaced, and there'll be a 5.01 very shortly. That one will get into Fedora 19 as an update...

--- Additional comment from Simone Caronni on 2013-05-27 04:21:49 EDT ---

Tried version 5.00 from Koji, same problem here.

Regards,
--Simone

--- Additional comment from David Woodhouse on 2013-05-27 14:20:30 EDT ---

Are you able to build and try the latest version from the upstream git repository?

--- Additional comment from Simone Caronni on 2013-05-28 05:28:45 EDT ---

Trying this now, come back in a few minutes.

--- Additional comment from Simone Caronni on 2013-05-28 05:40:54 EDT ---

Compilation on Fedora 19 x86_64 bombs out with this:

DEBUG: dtls.c:129:2: error: #error This version of OpenSSL is known to be broken with Cisco DTLS.
DEBUG: make[1]: *** [openconnect-dtls.o] Error 1

I've used your spec file as is with a tarball generated from git and an "autoreconf -v --install" after the %setup macro.

--- Additional comment from David Woodhouse on 2013-05-28 07:18:03 EDT ---

make CFLAGS=-DNO_BROKEN_DTLS_CHECK

--- Additional comment from Simone Caronni on 2013-05-28 08:36:44 EDT ---

With:

export CFLAGS="$RPM_BUILD_OPTFLAGS -DNO_BROKEN_DTLS_CHECK"

I was able to build the package. The bug is still present also in the git version; I still have "XML response has no "auth" node" instead of the login prompt.

--- Additional comment from David Woodhouse on 2013-05-28 15:33:02 EDT ---

Thanks. Please could you apply the patch at http://david.woodhou.se/openconnect-show-http-traffic.patch and email me the full output of openconnect with the '-v' option on the command line.

--- Additional comment from Simone Caronni on 2013-05-29 04:12:15 EDT ---

Here is the log. I've replaced IPs and dns names with consistent but fake addresses.

# openconnect examplevpn.example.com


POST https://examplevpn.example.com/
Attempting to connect to server 202.189.128.75:443
SSL negotiation with examplevpn.example.com
Connected to HTTPS on examplevpn.example.com
request: POST / HTTP/1.1
Host: examplevpn.example.com
User-Agent: Open AnyConnect VPN Agent v5.00-unknown
Accept: */*
Accept-Encoding: identity
X-Transcend-Version: 1
X-Aggregate-Auth: 1
X-AnyConnect-Platform: linux-64
Content-Type: application/x-www-form-urlencoded
Content-Length: 216

<?xml version="1.0" encoding="UTF-8"?>
<config-auth client="vpn" type="init"><version who="vpn">v5.00-unknown</version><device-id>linux-64</device-id><group-access>https://examplevpn.example.com</group-access></config-auth>

Got HTTP response: HTTP/1.0 302 Temporary moved
response: (null)
POST https://mt-examplevpn01.example.com/
Attempting to connect to server 202.189.128.77:443
SSL negotiation with mt-examplevpn01.example.com
Connected to HTTPS on mt-examplevpn01.example.com
request: POST / HTTP/1.1
Host: mt-examplevpn01.example.com
User-Agent: Open AnyConnect VPN Agent v5.00-unknown
Accept: */*
Accept-Encoding: identity
X-Transcend-Version: 1
X-Aggregate-Auth: 1
X-AnyConnect-Platform: linux-64
Content-Type: application/x-www-form-urlencoded
Content-Length: 216

<?xml version="1.0" encoding="UTF-8"?>
<config-auth client="vpn" type="init"><version who="vpn">v5.00-unknown</version><device-id>linux-64</device-id><group-access>https://examplevpn.example.com</group-access></config-auth>

response: <?xml version="1.0" encoding="UTF-8"?>
<config-auth client="vpn" type="auth-request">
<version who="sg">9.1(1)4</version>
<client-cert-request></client-cert-request>
</config-auth>

XML response has no "auth" node
GET https://mt-examplevpn01.example.com/
SSL negotiation with mt-examplevpn01.example.com
Connected to HTTPS on mt-examplevpn01.example.com
request: GET / HTTP/1.1
Host: mt-examplevpn01.example.com
User-Agent: Open AnyConnect VPN Agent v5.00-unknown
Accept: */*
Accept-Encoding: identity
X-Transcend-Version: 1
X-Aggregate-Auth: 1
X-AnyConnect-Platform: linux-64


response: <?xml version="1.0" encoding="UTF-8"?>
<config-auth client="vpn" type="complete">
<version who="sg">9.1(1)4</version>
<error id="96" param1="" param2="">VPN Server internal error.</error>
</config-auth>

XML response has no "auth" node
Failed to obtain WebVPN cookie

--- Additional comment from Simone Caronni on 2013-05-29 04:13:37 EDT ---

I forgot the "-v" switch, here's the correct output:

# openconnect -v examplevpn.example.com

POST https://examplevpn.example.com/
Attempting to connect to server 202.189.128.75:443
SSL negotiation with examplevpn.example.com
Connected to HTTPS on examplevpn.example.com
request: POST / HTTP/1.1
Host: examplevpn.example.com
User-Agent: Open AnyConnect VPN Agent v5.00-unknown
Accept: */*
Accept-Encoding: identity
X-Transcend-Version: 1
X-Aggregate-Auth: 1
X-AnyConnect-Platform: linux-64
Content-Type: application/x-www-form-urlencoded
Content-Length: 216

<?xml version="1.0" encoding="UTF-8"?>
<config-auth client="vpn" type="init"><version who="vpn">v5.00-unknown</version><device-id>linux-64</device-id><group-access>https://examplevpn.example.com</group-access></config-auth>

Got HTTP response: HTTP/1.0 302 Temporary moved
Content-Length: 0
Cache-Control: no-cache
Pragma: no-cache
Connection: Close
Date: Wed, 29 May 2013 08:12:25 GMT
Location: https://mt-examplevpn01.example.com/
HTTP body length:  (0)
response: (null)
POST https://mt-examplevpn01.example.com/
Attempting to connect to server 202.189.128.77:443
SSL negotiation with mt-examplevpn01.example.com
Connected to HTTPS on mt-examplevpn01.example.com
request: POST / HTTP/1.1
Host: mt-examplevpn01.example.com
User-Agent: Open AnyConnect VPN Agent v5.00-unknown
Accept: */*
Accept-Encoding: identity
X-Transcend-Version: 1
X-Aggregate-Auth: 1
X-AnyConnect-Platform: linux-64
Content-Type: application/x-www-form-urlencoded
Content-Length: 216

<?xml version="1.0" encoding="UTF-8"?>
<config-auth client="vpn" type="init"><version who="vpn">v5.00-unknown</version><device-id>linux-64</device-id><group-access>https://examplevpn.example.com</group-access></config-auth>

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: Wed, 29 May 2013 08:12:26 GMT
X-Aggregate-Auth: 1
HTTP body chunked (-2)
response: <?xml version="1.0" encoding="UTF-8"?>
<config-auth client="vpn" type="auth-request">
<version who="sg">9.1(1)4</version>
<client-cert-request></client-cert-request>
</config-auth>

XML response has no "auth" node
GET https://mt-examplevpn01.example.com/
SSL negotiation with mt-examplevpn01.example.com
Connected to HTTPS on mt-examplevpn01.example.com
request: GET / HTTP/1.1
Host: mt-examplevpn01.example.com
User-Agent: Open AnyConnect VPN Agent v5.00-unknown
Accept: */*
Accept-Encoding: identity
X-Transcend-Version: 1
X-Aggregate-Auth: 1
X-AnyConnect-Platform: linux-64


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: Wed, 29 May 2013 08:12:27 GMT
X-Aggregate-Auth: 1
HTTP body chunked (-2)
response: <?xml version="1.0" encoding="UTF-8"?>
<config-auth client="vpn" type="complete">
<version who="sg">9.1(1)4</version>
<error id="96" param1="" param2="">VPN Server internal error.</error>
</config-auth>

XML response has no "auth" node
Failed to obtain WebVPN cookie

--- Additional comment from David Woodhouse on 2013-05-29 12:03:42 EDT ---

Hm, did any older version of openconnect work with this server? If so, please could you provide '-v' output from that, with a similar patch applied (don't actually log in; just abort when you get asked for password).

Or is this a new breed of server that's never worked, and we need to do some more analysis of what the Cisco client does to talk to it?

I note that we're trying the new XML post method, getting redirected to a different server, then falling back to the old method when that doesn't work... but we're trying the old method on the server that we got redirected to, not the original. When we fall back, we should probably reset to the original URL.

Cheap hack to try that: at about line 978 of http.c, near the big 'Step 2' comment at the beginning of openconnect_obtain_cookie(), please just add a 'goto fail;', which will make it skip the XML post attempt and go directly to the old method.

--- Additional comment from Simone Caronni on 2013-05-30 06:20:23 EDT ---

(In reply to David Woodhouse from comment #11)
> Hm, did any older version of openconnect work with this server?

Yes it is. With Fedora 17 and 18 I'm able to connect; in fact I fired up my old laptop a few moments ago for doing some work.

> If so,
> please could you provide '-v' output from that, with a similar patch applied
> (don't actually log in; just abort when you get asked for password).

Can I rebuild the Fedora 18 package for 19 or it has additional prerequisites? Can you please provide the patch for this on openconnect-4.08-1.fc18?

> Or is this a new breed of server that's never worked, and we need to do some
> more analysis of what the Cisco client does to talk to it?

It always worked and it's still working up to Fedora 18 and with RHEL 6.

> I note that we're trying the new XML post method, getting redirected to a
> different server, then falling back to the old method when that doesn't
> work... but we're trying the old method on the server that we got redirected
> to, not the original. When we fall back, we should probably reset to the
> original URL.
> 
> Cheap hack to try that: at about line 978 of http.c, near the big 'Step 2'
> comment at the beginning of openconnect_obtain_cookie(), please just add a
> 'goto fail;', which will make it skip the XML post attempt and go directly
> to the old method.

The behaviour with lot of redirects has been consistent with this VPN server in the past 2 years; there's nothing new introduced lately.

If you provide patches for this I will be happy to test; I'm currently busy at the moment, sorry. :(

Thanks,
--Simone

--- Additional comment from David Woodhouse on 2013-05-30 11:18:50 EDT ---

Are the IP addresses in comment 10 correct, or did you "edit" them? In the general case, there's no problem with showing the address of the server. It's not as if you're also giving out your username and password. The server is just another one out of millions of HTTPS servers on the Internet, and will be receiving hundreds if not thousands of "unexpected" connections every day.

If I can connect to it directly and test, I should be able to fix things without having to hassle you to keep trying different things. But those IP addresses are not responding from here.

Please could you test the scratch build at http://koji.fedoraproject.org/koji/taskinfo?taskID=5442326

There's a --no-xmlpost option which should revert to the older behaviour and should *definitely* (hopefully) work. And I've also hopefully fixed the fallback behaviour so that it forgets any redirections it encountered while trying the XML POST mode, and starts again from scratch at the original URL. Which should mean that you don't *need* the --no-xmlpost option.

--- Additional comment from Simone Caronni on 2013-05-30 12:16:23 EDT ---

(In reply to David Woodhouse from comment #13)
> Are the IP addresses in comment 10 correct, or did you "edit" them? In the
> general case, there's no problem with showing the address of the server.
> It's not as if you're also giving out your username and password. The server
> is just another one out of millions of HTTPS servers on the Internet, and
> will be receiving hundreds if not thousands of "unexpected" connections
> every day.
> 
> If I can connect to it directly and test, I should be able to fix things
> without having to hassle you to keep trying different things. But those IP
> addresses are not responding from here.

You convinced me, sorry :)
You can try the connection with the "catvpn.cat.com" as an address on your box. There is also an RSA hardware token authentication in place so it should be pretty safe.

> Please could you test the scratch build at
> http://koji.fedoraproject.org/koji/taskinfo?taskID=5442326
> 
> There's a --no-xmlpost option which should revert to the older behaviour and
> should *definitely* (hopefully) work. And I've also hopefully fixed the
> fallback behaviour so that it forgets any redirections it encountered while
> trying the XML POST mode, and starts again from scratch at the original URL.
> Which should mean that you don't *need* the --no-xmlpost option.

I've tried with "openconnect -v catvpn.cat.com" command, but I still get the same result:

[...]
X-Aggregate-Auth: 1
HTTP body chunked (-2)
XML response has no "auth" node
Failed to obtain WebVPN cookie

Thanks,
--Simone

--- Additional comment from David Woodhouse on 2013-05-30 16:25:11 EDT ---

OK, thanks. The problem was the X-Aggregate-Auth: header. When we fall back to the non-XMLPOST mode, we need to drop that. I've pushed a commit to the git tree which should fix things. The fallback mode now works, and I get asked for a username and password.

However, we probably *shouldn't* be falling back to the old mode. The Cisco client, when it sees that server 'form' with <client-cert-request></client-cert-request>, will respond with <client-cert-fail></client-cert-fail> and then get a similar form asking for username/password. Whereas we just complain that we didn't see any 'auth' node in the form, and fall back to the old mode.

--- Additional comment from David Woodhouse on 2013-05-30 16:29:15 EDT ---

Simone, just to confirm: You *don't* have any SSL certificate authentication? The RSA hardware token you mention is just one of the ones with a numeric readout that changes ever 30 seconds or so? And you log in with just your username and a "password" taken from the token?

--- Additional comment from Simone Caronni on 2013-05-31 03:44:56 EDT ---

(In reply to David Woodhouse from comment #16)
> Simone, just to confirm: You *don't* have any SSL certificate
> authentication? 

Exactly. Of all the NetworkManager settings that are available when creating the VPN I fill only the "Gateway" field with the catvpn.cat.com address.

> The RSA hardware token you mention is just one of the ones
> with a numeric readout that changes ever 30 seconds or so? And you log in
> with just your username and a "password" taken from the token?

Yes, the RSA hardware token is exactly that. There's a pin to open the token, synchronized with both the RSA server and my token that gives back an 8 number password to use as my password in OpenConnect.

The "hardware" token is actually a software thing; there's a Windows, Android and iOS version. No Linux version unfortunately; so I type my pin and read the passcode from an Android phone.

The Linux Cisco AnyConnect client behaves exactly the same (i.e. no RSA integration); while the Windows Cisco AnyConnect client is able to open directly the RSA token from the locally installed RSA Token software and just asks for the first pin.

Thanks,
--Simone

--- Additional comment from Simone Caronni on 2013-05-31 04:01:27 EDT ---

I've rebuilt the package with the current GIT code; I'm asked username and passcode but the xml message is still there.

I'm unable to connect after filling the authentication data:

POST https://catvpn.cat.com/
Attempting to connect to server 192.189.128.75:443
SSL negotiation with catvpn.cat.com
Connected to HTTPS on catvpn.cat.com
Got HTTP response: HTTP/1.0 302 Temporary moved
Content-Length: 0
Cache-Control: no-cache
Pragma: no-cache
Connection: Close
Date: Fri, 31 May 2013 07:56:50 GMT
Location: https://mt-catvpn01.cat.com/
HTTP body length:  (0)
POST https://mt-catvpn01.cat.com/
Attempting to connect to server 192.189.128.77:443
SSL negotiation with mt-catvpn01.cat.com
Connected to HTTPS on mt-catvpn01.cat.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: Fri, 31 May 2013 07:56:51 GMT
X-Aggregate-Auth: 1
HTTP body chunked (-2)
XML response has no "auth" node
GET https://catvpn.cat.com/
SSL negotiation with catvpn.cat.com
Connected to HTTPS on catvpn.cat.com
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: Fri, 31 May 2013 07:56:52 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://catvpn.cat.com/+webvpn+/index.html
SSL negotiation with catvpn.cat.com
Connected to HTTPS on catvpn.cat.com
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.
Username:^C
[slaanesh@3zpc0560 result]$ openconnect -v catvpn.cat.com
POST https://catvpn.cat.com/
Attempting to connect to server 192.189.128.75:443
SSL negotiation with catvpn.cat.com
Connected to HTTPS on catvpn.cat.com
Got HTTP response: HTTP/1.0 302 Temporary moved
Content-Length: 0
Cache-Control: no-cache
Pragma: no-cache
Connection: Close
Date: Fri, 31 May 2013 07:58:39 GMT
Location: https://ad-catvpn01.cat.com/
HTTP body length:  (0)
POST https://ad-catvpn01.cat.com/
Attempting to connect to server 192.189.128.76:443
SSL negotiation with ad-catvpn01.cat.com
Connected to HTTPS on ad-catvpn01.cat.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: Fri, 31 May 2013 07:58:39 GMT
X-Aggregate-Auth: 1
HTTP body chunked (-2)
XML response has no "auth" node
GET https://catvpn.cat.com/
SSL negotiation with catvpn.cat.com
Connected to HTTPS on catvpn.cat.com
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: Fri, 31 May 2013 07:58:40 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://catvpn.cat.com/+webvpn+/index.html
SSL negotiation with catvpn.cat.com
Connected to HTTPS on catvpn.cat.com
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.
Username:account
PASSCODE:
POST https://catvpn.cat.com/+webvpn+/index.html
Got HTTP response: HTTP/1.1 200 OK
Transfer-Encoding: chunked
Content-Type: text/xml
Cache-Control: max-age=0
Set-Cookie: webvpnlogin=; expires=Thu, 01 Jan 1970 22:00:00 GMT; path=/; secure
Set-Cookie: webvpn=<elided>; path=/; secure
Set-Cookie: webvpnc=bu:/CACHE/stc/&p:t&iu:1/&sh:09705C4C9F025D540F5B2E54D3AD891528D6314B&lu:/+CSCOT+/translation-table?textdomain%3DAnyConnect%26type%3Dmanifest&fu:profiles%2Fvpnclientprofile.xml&fh:BB3FEE75168A4C8FD0DF2D7E91833A12FF7EFF76; path=/; secure
Set-Cookie: webvpnx=gu:feedback@%2Fprofiles%2Fvpnnofeedbackprofile.xml&gh:1AFA3DB4440BB242615A700FF3E317521C085623
Set-Cookie: webvpnaac=1; path=/; secure
X-Transcend-Version: 1
HTTP body chunked (-2)
TCP_INFO rcv mss 1380, snd mss 1380, adv mss 1460, pmtu 1500
Got CONNECT response: HTTP/1.1 200 OK
X-CSTP-Version: 1
X-CSTP-Address: 10.222.247.30
X-CSTP-Netmask: 255.255.248.0
X-CSTP-DNS: 137.230.255.248
X-CSTP-Lease-Duration: 57600
X-CSTP-Session-Timeout: 57600
X-CSTP-Idle-Timeout: 14400
X-CSTP-Disconnected-Timeout: 14400
X-CSTP-Default-Domain: corp.cat.com
X-CSTP-Keep: true
X-CSTP-Tunnel-All-DNS: false
X-CSTP-DPD: 30
X-CSTP-Keepalive: 20
X-CSTP-Banner: WARNING%3A%20This%20is%20a%20Private%20Network%21%0A%0AUnauthorized%20access%20is%20prohibited.%0AUse%20of%20this%20system%20constitutes%20your%20consent%20to%20interception%2C%0Amonitoring%2C%20and%20recording%20for%20official%20purposes%20of%20information%0Arelated%20to%20such%20use%2C%20including%20criminal%20investigation.%0A
X-CSTP-MSIE-Proxy-Lockdown: true
X-CSTP-Smartcard-Removal-Disconnect: true
X-CSTP-Content-Encoding: deflate
X-DTLS-Session-ID: F3F1C5DD357B9CC99815B184D32ED32AD388E948126F286625DC1F8F3565679C
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
TUNSETIFF failed: Operation not permitted

--- Additional comment from Simone Caronni on 2013-05-31 04:02:51 EDT ---



--- Additional comment from Simone Caronni on 2013-05-31 04:04:59 EDT ---

I've also rebuilt 4.08 for Fedora 19; it's working fine.

--- Additional comment from David Woodhouse on 2013-05-31 04:18:51 EDT ---

In comment #18 you show a successful login. It ends with 'TUNSETIFF failed' because you ran it as yourself and not root. Your own user doesn't have sufficient privileges on the *local* machine to create and configure network devices.

In comment #19 you show a dialog box which is patiently waiting for you to enter your username and password. It's showing that 'has no auth node' error which happened when it tried to use XML POST mode, but it's irrelevant because it then falls back to the old mode and tries again. We should see if we can make the message go away...

--- Additional comment from Simone Caronni on 2013-05-31 04:40:02 EDT ---

(In reply to David Woodhouse from comment #21)
> In comment #18 you show a successful login. It ends with 'TUNSETIFF failed'
> because you ran it as yourself and not root. Your own user doesn't have
> sufficient privileges on the *local* machine to create and configure network
> devices.

Sorry, I've never had a single problem with openconnect until Fedora 19 so I never bothered to look at what kind of tunnel / interface it was bringing up.

Launching as root from the command line works and now works also through NetworkManager.

It was showing weird behaviour with icons and connections statuses; I had to reload NetworkManager to make it behave correctly.

Fixed for me, many thanks!

--- Additional comment from David Woodhouse on 2013-05-31 05:33:22 EDT ---

Well, almost fixed. I still want to fix the fact that it falls back to the old method. It ought to give the <cert-auth-fail/> response and then let you log in using the new method. And then it wouldn't give that scary error in the NetworkManager dialog.

I think I'll do a 5.01 release like this though; fixing the cert handling for aggregate auth is going to require some experimentation... after we find a new server that uses certificate auth that we can actually test with :)

I might see if I can get rid of the scary error somehow.

--- Additional comment from David Woodhouse on 2013-05-31 10:01:12 EDT ---

I've just pushed some changes to the git tree which should make this work properly for you with the new aggregate auth (xml post) mode. It should now send the appropriate <client-cert-fail/> tag which prompts the server to send us the real form we wanted. If you could test that this works for you, I'd be very grateful.

Thanks for all your help with debugging this.

--- Additional comment from Simone Caronni on 2013-05-31 10:36:03 EDT ---

(In reply to David Woodhouse from comment #24)
> If you could test that this works for you, I'd be very grateful.

Perfect! No more auth message and (maybe it's my impression) faster login.

Thank you very much for fixing this so fast!
--Simone

--- Additional comment from David Woodhouse on 2013-05-31 12:22:38 EDT ---

Yes, it should definitely be faster. When it falls back to the old mode it has to close the connection and re-open a completely new SSL connection. That's a lot of round-trips between you and the server.

--- Additional comment from Fedora Update System on 2013-06-01 17:11:34 EDT ---

openconnect-5.01-1.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/openconnect-5.01-1.fc19

--- Additional comment from David Woodhouse on 2013-06-01 17:13:25 EDT ---

(In reply to Simone Caronni from comment #17)
> The "hardware" token is actually a software thing; there's a Windows,
> Android and iOS version. No Linux version unfortunately; so I type my pin
> and read the passcode from an Android phone.

Btw, when we used to use RSA soft tokens (before our IT department finally worked out that they were just wasting money paying a snake-oil merchant for random numbers they could have generated by themselves), I found that the RSA Softoken software used to run just fine under Wine. Including the .exe file that we downloaded to deploy/install our own personal token.

We also have libstoken now on Linux: http://stoken.sourceforge.net/

We probably ought to package libstoken for Fedora and build OpenConnect against it. If you are interested in that, please let me know.

--- Additional comment from Fedora Update System on 2013-06-02 14:41:39 EDT ---

Package openconnect-5.01-1.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing openconnect-5.01-1.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-9871/openconnect-5.01-1.fc19
then log in and leave karma (feedback).

--- Additional comment from Simone Caronni on 2013-06-03 04:08:50 EDT ---

(In reply to David Woodhouse from comment #28)
> (In reply to Simone Caronni from comment #17)
> We also have libstoken now on Linux: http://stoken.sourceforge.net/
> 
> We probably ought to package libstoken for Fedora and build OpenConnect
> against it. If you are interested in that, please let me know.

Thanks for the indo, I did not know it.

I'm trying to package it; though it depends on libtomcrypt.pc package config file which is not included in libtomcrypt. Actually the last update of libtomcrypt is from 2007 (!) and does not even build for Fedora 19.

I'm filing bugs for it and add them for dependency on the stoken review.

--- Additional comment from Simone Caronni on 2013-06-03 06:14:00 EDT ---

stoken review:

* https://bugzilla.redhat.com/show_bug.cgi?id=970009

Unfortunately this review depends on the following bugs on libtomcrypt:

* https://bugzilla.redhat.com/show_bug.cgi?id=914150
* https://bugzilla.redhat.com/show_bug.cgi?id=970003

On top of this the libtomcrypt seems quite abandoned, so I started the inactive mantainer process:

* https://bugzilla.redhat.com/show_bug.cgi?id=970002

Should I file another bug on openconnect that has the stoken review as a dependency?

Thanks & regards,
--Simone

--- Additional comment from Simone Caronni on 2013-06-04 15:09:42 EDT ---

libtomcrypt-1.17-17: f18, f19, f20
openconnect-5.01-1: el6, f19, f20

I will try to build libtomcrypt for el6; please build openconnect 5.01 for f18.

This way, at the end of the review of stoken I will request branches for el6, f18, f19 and we will have RSA enabled openconnect everywhere!

--- Additional comment from Simone Caronni on 2013-06-04 15:23:22 EDT ---

...and please also build NetworkManager-openconnect-0.9.8.0-1 for f18 and f19 as they are currently using the prerelease.

--- Additional comment from David Woodhouse on 2013-06-04 19:43:07 EDT ---

I'll need to rebuild openconnect against stoken once it's reviewed and built, so is there any point in pushing updates now?

NM-o 0.9.8.0 needs to be built against openconnect 5.00 or newer in order to support software tokens. And there are some newer patches which have only just hit the upstream git tree, which we should probably backport.

I was thinking of doing it in the following order:

- Finish stoken (and oath-toolkit) reviews.
- Build openconnect with stoken and oath support
- Build NetworkManager-openconnect

Doing NM-o last means we get time for the dust to settle on the recent changes; we don't necessarily want to push that out too fast. I'm a little reticent to push openconnect 5.01 to f18 and el6 this soon, too. I wouldn't be *entirely* shocked if I end up needing a 5.02 release after finding more compatibility issues. I'm still not 100% sure if certificate auth is working with the new xmlpost method.

--- Additional comment from Fedora Update System on 2013-06-04 23:24:24 EDT ---

openconnect-5.01-1.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

--- Additional comment from John L Magee on 2013-07-06 18:55:21 EDT ---

Cannot be certain this is related but this command and configuration works on F18 with openconnect-4.08-1.fc18.x86_64 but fails on f19 with 5.01-1.fc19

[redact@redactee4 ~]$ sudo  openconnect  --disable-ipv6  --cafile /etc/pki/vapa.crt --passwd-on-stdin --no-cert-check -u redactedid --authgroup=redacted_VPN -v  vapa.redacted.com </home/redact/mypass.txt 
POST https://vapa.redacted.com/
Attempting to connect to server 10.10.10.10:443
SSL negotiation with vapa.redacted.com
Server certificate verify failed: signer not found
Connected to HTTPS on vapa.redacted.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: Sat, 06 Jul 2013 14:01:11 GMT
X-Aggregate-Auth: 1
HTTP body chunked (-2)
XML POST enabled
POST https://vapa.redacted.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: Sat, 06 Jul 2013 14:01:11 GMT
X-Aggregate-Auth: 1
HTTP body chunked (-2)
Login failed.
Password:
Failed to obtain WebVPN cookie
[redact@redactee4 ~]$ 

disappointing because it will prevent upgrading to f19 :-)