Unable to connect from AnyConnect 3.0 and 3.1 Windows Clients to ocserv 0.2.4 and git head

[Kevin Cernekee]

On Sat, Jan 11, 2014 at 11:42 AM, Thomas Glanzmann <thomas at glanzmann.de> wrote:
> Client:
> POST / HTTP/1.1
> Cache-Control: no-cache
> Connection: close
> Pragma: no-cache
> User-Agent: AnyConnect Windows 3.0.07059
> X-Transcend-Version: 1
> X-Aggregate-Auth: 1
> X-AnyConnect-Platform: win
> Content-Length: 243
> Host: lync.gmvl.de
>
> <?xml version="1.0" encoding="UTF-8"?>
> <config-auth client="vpn" type="init">
> <device-id>win</device-id>
> <version who="vpn">3.0.07059</version>
> <group-select>full</group-select>
> <group-access>https://lync.gmvl.de</group-access>
> </config-auth>
>
> Server:
> HTTP/1.1 200 OK
> Connection: Keep-Alive
> Content-Type: text/xml
> Content-Length: 209
> X-Transcend-Version: 1
>
> <?xml version="1.0" encoding="UTF-8"?>
> <auth id="main">
> <message>Please enter your username</message>
> <form method="post" action="/auth">
> <input type="text" name="username" label="Username:" />
> </form></auth>

I think we're seeing a discrepancy between how OpenConnect and
AnyConnect handle unexpected server responses.

AnyConnect 3.0+ will attempt the new style "XML POST" handshake, and
fall back to the old style if the server forces legacy mode.  It looks
like the Windows client may be stricter than the Linux/Mac clients;
perhaps it is checking explicitly to see if the form is a child of the
<config-auth> node, ala:

< <?xml version="1.0" encoding="UTF-8"?>
< <config-auth client="vpn" type="auth-request">
< <version who="sg">8.4(4)5</version>
< <opaque is-for="sg">
< <tunnel-group>alt</tunnel-group>
< <group-alias>alt</group-alias>
< <config-hash>1388992148509</config-hash>
< </opaque>
< <auth id="main">
< <title>Login</title>
< <message>Please enter your username and password.</message>
< <form>
[...]
< </form>
< </auth>
< </config-auth>


OpenConnect auth.c is fairly permissive, in that it will always accept
a form with either <config-auth> or <auth> as the root element.
OpenConnect figures out whether to use XML POST mode based on whether
the server redirects our initial "POST /" request to the /+webvpn+/
URL:

Connected to HTTPS on asa
> POST / HTTP/1.1
> Host: asa
> User-Agent: Open AnyConnect VPN Agent v5.02-67-gb3fdb0d
[...]
> Content-Type: application/x-www-form-urlencoded
> Content-Length: 306
>
> <?xml version="1.0" encoding="UTF-8"?>
> <config-auth client="vpn" type="init"><version who="vpn">v5.02-67-gb3fdb0d</version><device-id platform-version="1.0" device-type="android" unique-id="AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA">android</device-id><group-access>https://asa</group-access></config-auth>
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: Sat, 11 Jan 2014 22:51:56 GMT
Location: /+webvpn+/index.html
Set-Cookie: tg=; expires=Thu, 01 Jan 1970 22:00:00 GMT; path=/; secure
HTTP body length:  (0)


So, for the case of ocserv, OpenConnect is sending an XML-POST-style
reply to a legacy-style form, because ocserv didn't send a /+webvpn+/
redirect.  AnyConnect might not exhibit the same behavior.

If ocserv requires XML POST submissions, I would suggest tweaking the
ocserv XML output so that it more closely resembles the structure of
the document shown above.  However, requiring XML POST does break
compatibility with AnyConnect <=v2.5.