PAN GlobalProtect

How the VPN works

This VPN is based on HTTPS and ESP, with routing and configuration information distributed in XML format.

GlobalProtect mode is requested by adding --protocol=gp to the command line: 

  openconnect --protocol=gp vpn.example.com

Authentication

To authenticate, you connect to the secure web server (POST /ssl-vpn/login.esp), provide a username, password, and (optionally) a certificate, and receive an authcookie. The username, authcookie, and a couple other bits of information obtained at login are combined into the OpenConnect cookie.

Tunnel configuration

To connect to the secure tunnel, the cookie is used to read routing and tunnel configuration information (POST /ssl-vpn/getconfig.esp).

Next, a HIP report (security scanner report) is generated by the client and submitted to the server, if required.

Finally, either an HTTPS-based or ESP-based tunnel is setup:

  1. The cookie is used in a non-standard HTTP request (GET /ssl-tunnel-connect.sslvpn, which acts more like a CONNECT). Arbitrary IP packets can be passed over the resulting tunnel.
  2. The ESP keys provided by the configuration request are used to set up a UDP-encapsulated ESP tunnel.

Since TCP over TCP is very suboptimal, OpenConnect tries to always use ESP-over-UDP, and will only fall over to the HTTPS tunnel if that fails, or if disabled via the --no-dtls argument.

Quirks and issues

There appears to be no reasonable mechanism to negotiate the MTU for the link, or discover the MTU of the accessed network. The configuration always shows <mtu>0</mtu>. OpenConnect attempts to calculate the MTU by starting from the base MTU with the overhead of encapsulating each packets within ESP, UDP, and IP.

There is currently no IPv6 support. PAN's documentation suggests that recent versions of GlobalProtect may support IPv6 over the ESP tunnel, though not the SSL tunnel.

The ESP and HTTPS tunnels cannot be connected simultaneously. The ESP tunnel becomes unresponsive as soon as the HTTPS tunnel is started, and remains so unless/until the tunnel is closed and the configuration is re-fetched.

Compared to the AnyConnect or Juniper protocols, the GlobalProtect protocol appears to have very little in the way of in-band signaling. The HTTPS tunnel can only send or receive IPv4 packets and a simple DPD/keepalive packet (always sent by the client and echoed by the server). The ESP tunnel does not have any special DPD/keepalive packet, but uses an ICMP ("ping") request to the server with a magic payload for this purpose