Bug 964329 - openconnect XML response has no "auth" node
openconnect XML response has no "auth" node
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: openconnect (Show other bugs)
19
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: David Woodhouse
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-05-17 17:23 EDT by Rui Moreira
Modified: 2013-07-29 11:29 EDT (History)
5 users (show)

See Also:
Fixed In Version: openconnect-5.01-1.fc19
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 981911 (view as bug list)
Environment:
Last Closed: 2013-06-04 23:24:24 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Login screenshot with error (26.64 KB, image/png)
2013-05-31 04:02 EDT, Simone Caronni
no flags Details

  None (edit)
Description Rui Moreira 2013-05-17 17:23:58 EDT
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:
Comment 1 David Woodhouse 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...
Comment 2 Simone Caronni 2013-05-27 04:21:49 EDT
Tried version 5.00 from Koji, same problem here.

Regards,
--Simone
Comment 3 David Woodhouse 2013-05-27 14:20:30 EDT
Are you able to build and try the latest version from the upstream git repository?
Comment 4 Simone Caronni 2013-05-28 05:28:45 EDT
Trying this now, come back in a few minutes.
Comment 5 Simone Caronni 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.
Comment 6 David Woodhouse 2013-05-28 07:18:03 EDT
make CFLAGS=-DNO_BROKEN_DTLS_CHECK
Comment 7 Simone Caronni 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.
Comment 8 David Woodhouse 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.
Comment 9 Simone Caronni 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
Comment 10 Simone Caronni 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
Comment 11 David Woodhouse 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.
Comment 12 Simone Caronni 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
Comment 13 David Woodhouse 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.
Comment 14 Simone Caronni 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
Comment 15 David Woodhouse 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.
Comment 16 David Woodhouse 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?
Comment 17 Simone Caronni 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
Comment 18 Simone Caronni 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
Comment 19 Simone Caronni 2013-05-31 04:02:51 EDT
Created attachment 755194 [details]
Login screenshot with error
Comment 20 Simone Caronni 2013-05-31 04:04:59 EDT
I've also rebuilt 4.08 for Fedora 19; it's working fine.
Comment 21 David Woodhouse 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...
Comment 22 Simone Caronni 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!
Comment 23 David Woodhouse 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.
Comment 24 David Woodhouse 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.
Comment 25 Simone Caronni 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
Comment 26 David Woodhouse 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.
Comment 27 Fedora Update System 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
Comment 28 David Woodhouse 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.
Comment 29 Fedora Update System 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).
Comment 30 Simone Caronni 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.
Comment 31 Simone Caronni 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
Comment 32 Simone Caronni 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!
Comment 33 Simone Caronni 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.
Comment 34 David Woodhouse 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.
Comment 35 Fedora Update System 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.
Comment 36 John L Magee 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 :-)
Comment 37 David Woodhouse 2013-07-10 06:19:45 EDT
Hi John,

Please see comment 13 regarding both the redaction of the addresses, and the --no-xmlpost option. Does it work for you with --no-xmlpost?

Please could you let me have the address of the server, in private email if you really prefer. Then I can see what it's offering as a login form, and work out why openconnect doesn't like it.

At the very least, I'll need to start with the output of openconnect with the '--dump-http-traffic' option, when connecting to it.

Thanks.
Comment 38 John L Magee 2013-07-10 08:24:24 EDT
Thanks. it works with --no-xmlpost I'd missed that comment.

I'll send the url privately.
Comment 39 Manuel Bejarano 2013-07-29 11:29:10 EDT
Hello,

I'm having the same problem when trying to access my university VPN network, passing the --no-xmlpost argument does not seem to work. Here it is the output:

# openconnect -v --dump-http-traffic --no-xmlpost connect.lu.se
GET https://connect.lu.se/
Attempting to connect to server 130.235.72.4:443
SSL negotiation with connect.lu.se
Connected to HTTPS on connect.lu.se
> GET / HTTP/1.1
> Host: connect.lu.se
> User-Agent: Open AnyConnect VPN Agent v5.01
> Accept: */*
> Accept-Encoding: identity
> X-Transcend-Version: 1
> 
Got HTTP response: HTTP/1.1 200 OK
Date: Mon, 29 Jul 2013 15:33:22 GMT
Last-Modified: Tue, 12 Feb 2013 01:36:28 GMT
ETag: "a90_83_51199c9c"
Accept-Ranges: bytes
Content-Length: 131
Content-Type: text/html
X-Frame-Options: SAMEORIGIN
HTTP body length:  (131)
< <html><script type="text/javascript">
< if (window!=top) top.location=window.location;top.location="/remote/login";
< </script></html>
XML response has no "auth" node
Failed to obtain WebVPN cookie

Note You need to log in before you can comment on or make changes to this bug.