Palo Alto Networks (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

GlobalProtect portals and gateways

GlobalProtect VPNs actually contain two different server interfaces: portals and gateways. Most VPNs have one portal server and one or more gateway servers; the server hosting the portal interface often hosts a gateway interface as well, but not always. The portal interface mostly sends centrally-imposed security/lockdown settings for the official client software to follow. The only information sent by the portal that's clearly useful to a VPN client like OpenConnect (which tries to give full control to the end user) is the list of gateways.

Some GlobalProtect VPNs are configured in such a way that the client must authenticate to the portal before it can access the gateway, while with other VPNs no interaction with the portal is necessary. In order to replicate the behavior of the official clients, OpenConnect first attempts to connect to the portal interface of the specified server.

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.

Some servers are configured to authenticate through SAML for multi-factor authentication. Support for this is provided in combination with network-manager-openconnect.

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.

IPv6 support was added in GlobalProtect 4.0 in 2017. OpenConnect has experimental support for GlobalProtect IPv6 as of 9.0. If you have access to a GlobalProtect VPN that supports IPv6, please send feedback to the mailing list.

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 IP 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