[PATCH 7/8] Add support for GlobalProtect ESP tunnel

[Daniel Lenski]

On Sat, May 20, 2017 at 3:43 PM, Daniel Lenski <dlenski at gmail.com> wrote:
> Most of the existing ESP support code (written for Juniper/nc) can be reused
> for GlobalProtect ESP. The ESP algorithms, SPIs, and keys are sent as part of the
> getconfig XML response.
>
> GlobalProtect requires a fairly awkward "tap dance" between the TCP mainloop and
> the UDP mainloop in order to support ESP:
>
> * Prior to the getconfig XML request, the HTTPS tunnel will not work (even though
>   the authcookie is already known from the login response) and the ESP tunnel
>   also will not work (because the ESP keys are not known).
> * After the getconfig XML request, either the ESP tunnel or the HTTPS tunnel can
>   be connected, but not both.  As soon as the HTTPS tunnel is disconnected,
>   the ESP keys are invalidated.  On the other hand, if the ESP tunnel stops
>   responding due to some firewall that interferes with UDP, the HTTPS tunnel
>   can still be connected.
> * Therefore, in order to allow the ESP tunnel to start, the TCP mainloop must
>   refrain from actually connecting to the HTTPS tunnel unless the ESP tunnel
>   is disabled or has failed to connect... but it can't wait *too* long
>   because then the HTTPS keepalive connection may be dropped, and the user
>   will wonder why no traffic is flowing even though the VPN has allegedly
>   started.  The wait time is currently hard-coded at 5 seconds (half the DPD
>   interval used by the official clients).
>
> Another quirk of the GlobalProtect ESP support: it uses specially
> constructed ICMP request/reply ("ping") packets as the probes for ESP
> initiation and DPD.
>
> * These packets must contain a "magic payload" in order to work.
> * In most GlobalProtect VPNs, the packets are addressed to the public, external IPv4
>   address of the VPN gateway server even though they are sent over the ESP
>   tunnel (???), but in some cases they must be addressed to a different address
>   which is misleading described as <gw-address> in the getconfig XML response.
>
> Don't blame me. I didn't design this.
>
> Signed-off-by: Daniel Lenski <dlenski at gmail.com>

Small patch-on-top-of-a-patch coming... nothing is broken in the
current version, but the ESP probe-catching function could be
implemented more cleanly.

-Dan