Fortinet SSL VPN

Experimental support for Fortinet SSL VPN was added to OpenConnect in March 2021. It is also known as FortiGate in some documentation. It is a PPP-based protocol using the native PPP support which was merged into the 9.00 release.

Fortinet mode is requested by adding --protocol=fortinet to the command line:

  openconnect --protocol=fortinet

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


OpenConnect currently supports basic username/password, optional TLS client certificate, and optional multifactor authentication token entry via the two known challenge/response mechanisms: plaintext/"tokeninfo" (issue #225) and HTML forms (issue #332).

If you have access to a Fortinet VPN which uses other types of authentication, please send information to the mailing list so that we can add support to OpenConnect.

Non-PPP-based wire protocol

FortiGate server versions starting around v5.6.6 support a new wire protocol ("v2") for the VPN tunnel, in addition to the original wire protocol ("v1"). The original wire protocol is based on PPP; the new one is not.

OpenConnect does not yet support this wire protocol. We do not know of any advantages of this wire protocol, but if there are some then it might be worthwhile to add support, and relatively straightforward (see many details of this wire protocol are easily understood).

Quirks and Issues

FortiGate server versions prior to v6.2.1 do not allow the post-authentication cookie (as output by --authenticate) to be used to reestablish a dropped connection. This means that if the client loses its connection to the gateway (for example, due to a network outage, or after roaming to a different physical adapter) a new authentication will always be required. This is a substantial design flaw which is not present in any of the other protocols supported by OpenConnect.

Starting with FortiOS 6.2.1, an optional server-side setting (tun-connect-without-reauth) appears intended to support reconnection, but still doesn't work very well (see discussion on issue #297). Please send reports on success and failure with Fortinet reconnection to the mailing list so we can understand it better.