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
