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.
