testing a new SSL+ESP VPN

[Daniel Lenski]

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