openconnect/www/globalprotect.xml

<PAGE>
	<INCLUDE file="inc/header.tmpl" />

	<VAR match="VAR_SEL_PROTOCOLS" replace="selected" />
	<VAR match="VAR_SEL_GLOBALPROTECT" replace="selected" />
	<PARSE file="menu1.xml" />
	<PARSE file="menu2-protocols.xml" />

	<INCLUDE file="inc/content.tmpl" />

<h1>PAN GlobalProtect</h1>

<h2>How the VPN works</h2>

<p>This VPN is based on HTTPS and <a
href="https://tools.ietf.org/html/rfc3948">ESP</a>, with routing and
configuration information distributed in XML format.</p>

<p>GlobalProtect mode is requested by adding <tt>--protocol=gp</tt>
to the command line:
<pre>
  openconnect --protocol=gp vpn.example.com
</pre></p>

<h3>GlobalProtect portals and gateways</h3>

<p>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.</p>

<p>Some GlobalProtect VPNs are configured in such a way that the
client <i>must</i> 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.</p>

<ul>
  <li>If <tt>--usergroup=gateway</tt> is specified (or, equivalently,
  <tt>/gateway</tt> is appended to the server URL, e.g.
  <tt>https://vpn.company.com/gateway</tt>), then OpenConnect will
  attempt to skip the portal interface and connect immediately to the
  gateway interface. This is useful if the GlobalProtect VPN portal is
  misconfigured, such as by not offering the desired gateway server in
  the list it provides.</li>
  <li>If connecting to the portal interface yields a choice of
  multiple gateways, <tt>--authgroup=GatewayName</tt> tells OpenConnect
  which one to choose.</li>
</ul>

<h3>Authentication</h3>

<p>To authenticate, you connect to the secure web server (<tt>POST
/ssl-vpn/login.esp</tt>), 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.</p>

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

<h3>Tunnel configuration</h3>

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

<p>Next, a <a href="hip.html">HIP report</a> (security scanner report) is
generated by the client and submitted to the server, if required.</p>

<p>Finally, either an HTTPS-based or ESP-based tunnel is setup:</p>

<ol>
  <li>The cookie is used in a non-standard HTTP request (<tt>GET
      /ssl-tunnel-connect.sslvpn</tt>, which acts more like a
      <tt>CONNECT</tt>).  Arbitrary IP packets can be passed over the
      resulting tunnel.</li>
  <li>The ESP keys provided by the configuration request are used to set up
      a <a href="https://tools.ietf.org/html/rfc3948">UDP-encapsulated
      ESP</a> tunnel.</li>
</ol>

<p>Since <a href="http://sites.inka.de/~W1011/devel/tcp-tcp.html">TCP over
TCP is very suboptimal</a>, 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 <tt>--no-dtls</tt> argument.</p>

<h2>Quirks and issues</h2>

<p>There appears to be no reasonable mechanism to negotiate the <a
href="https://en.wikipedia.org/wiki/Maximum_transmission_unit">MTU</a> for
the link, or discover the MTU of the accessed network.  The configuration
always shows <tt><![CDATA[&lt;mtu&gt;0&lt;/mtu&gt;]]></tt>.  OpenConnect attempts to
calculate the MTU by starting from the base MTU with the overhead of
encapsulating each packets within ESP, UDP, and IP.</p>

<p>IPv6 support was added in <a
href="https://live.paloaltonetworks.com/t5/Colossal-Event-Blog/New-GlobalProtect-4-0-announced-with-IPv6-support/ba-p/141593">GlobalProtect
4.0 in 2017</a>. 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 <a href="mail.html">the mailing list</a>.</p>

<p>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.</p>

<p>Compared to the AnyConnect or Juniper protocols, the GlobalProtect
protocol appears to have very little in the way of <a
href="https://en.wikipedia.org/wiki/In-band_signaling">in-band
signaling</a>.  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 <a
href="https://en.wikipedia.org/wiki/Internet_Control_Message_Protocol">ICMP</a>
("ping") request to the server with a magic payload for this purpose</p>

	<INCLUDE file="inc/footer.tmpl" />
</PAGE>