testing a new SSL+ESP VPN

[Daniel Lenski]

On Wed, Oct 12, 2016 at 9:35 AM, Daniel Lenski <dlenski at gmail.com> wrote:
> 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

I've now got things pretty close to 100% working over SSL. The
authentication is done using libxml, so I can now connect to my GP VPN
using...

    openconnect --protocol=gp --user Myusername --certificate
certwpk.pem gateway.company.com

The cookie has the following format, which preserves everything that's
returned by the login request, and is subsequently needed to get the
configuration, connect to the SSL tunnel, and log the session out:

    USER=Username;AUTH=deadbeefdeadbeef;PORTAL=GatewayName;DOMAIN=domain

I tried to reuse existing coding style and interfaces from
openconnect, but there are a few things that don't work very well:

1. In order to log the user out, a separate HTTPS request has to be
issued. However, openconnect_open_https() and do_https_request() don't
work once got_cancel_cmd is set. Currently I have to trick openconnect
by temporarily setting got_cancel_cmd=0 during the logout request. Do
you have any suggestions on how to do this more cleanly?

2. As I understand it, the two-phase design of openconnect is intended
to do all the messy XML processing in the unprivileged phase, so that
only the simplest parts of the SSL/DTLS/ESP tunnel setup need to be
done by root. However, this doesn't work so well with GlobalProtect,
because all of the routing information comes in an XML file which
isn't received until after the login and getconfig requests. So I am
doing some XML processing during the connection process, in
gpst_parse_config_xml().

3. The existing process_split_xxclude() only handled IPv4 routes
formatted as "10.0.0.0/255.0.0.0", but the GP gateways returns split
routes formatted as "10.0.0.0/8". It's possible to unambiguously
distinguish the two (because no IPv4 netmask address can possibly have
a decimal integer value <=32) so I extended it to handle this case.

Still to do:

1. Have someone else test it with another GP VPN so we know I'm not crazy. :-D
2. Figure out how to do keepalive or DPD properly.
3. Figure out how to request or determine the MTU (I'm pretty sure ESP
will drop or fragment packets without getting this right).
4. Support ESP-over-UDP.

Should I go ahead and submit my patches for review at this point, or
would that be premature?

Thanks,
Dan