On Oct 8, 2016 12:53 AM, "David Woodhouse" <dwmw2 at infradead.org> wrote: > > For some reason, the Windows client drops the tunnel connection after > > a few seconds of running it through a (non-transparent) proxy. > > It seems to get stupidly confused as soon as it changes the default route > > and thinks it has lost communication with the proxy. > > Perhaps it preserves the specific route to the VPN server... but not to > the proxy? I've had a bug like that in the past... > > When there's no proxy (and when the UDP channel is blocked and can't > establish), I assume it stays up? Yes, it does stay up with the UDP channel blocked and an SSL tunnel only. At this point I think I'm close enough to understanding how this thing works that I'm not particularly motivated to resolve yet another bug in the Windows client (which is not surprisingly what brought me here in the first place). > > I don't know what the getconfig XML will look like for an IPv6 network > > configuration. A few minutes of googling didn't turn up anything very > > useful. > > Running 'strings' on the executable can often be enlightening. Failing > that though, it'll have to be Legacy IP only for now. I tried that, but could not find *any* mention of IPv6 anywhere in the executable(s). Over the weekend, I got the basic SSL-VPN support for GlobalProtect working, and decided I'd try to use it for "real work" for a couple of days before asking more questions. I found the code and comments to be extremely clear and well-designed, and this was a lot less painful than I expected! You can see my results on the globalprotect branch of https://github.com/dlenski/openconnect/commits/globalprotect Currently, the cookie is supposed to look like "USER=Username;AUTH=deadbeefdeadbeefdeadbeef;IP=1.2.3.4" and the cookie must be obtained using a Python script to query login.esp and getconfig.esp. The Python script can feed its standard output to openconnect --cookie-on-stdin, and can be run with --verbose to give a few more details of the XML results it's getting: globalprotect-auth.py --user $USERNAME --password $PASSWORD --cert $CERTFILE gateway.company.com | sudo ./openconnect --protocol=gp --cookie-on-stdin gateway.company.com After using it for a couple of days, a couple issues become apparent: 1. There is no keepalive or dead peer detection support, other than to reconnect if the TLS socket is closed. However, the gateway often stops responding without actually closing the TLS connection. strings *.exe *.dll shows that some kind of keepalive packets exists both for the SSL and ESP tunnels, but I don't know their format. 2. I don't know how to determine the MTU other than through path MTU discovery to hosts inside the VPN. The getconfig.esp request always returns <mtu>0</mtu>. So I have just been setting mtu=1500 for now, since that is the MTU of the network to which I'm connecting. Any ideas about how to handle this? Next step is to rewrite the authentication code in C. It would be great to know if the Python auth scripts works for any other lurkers out there with access to a GlobalProtect VPN. -Dan
