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
