FortiGate
FortiGate Next Generation Firewall utilizes purpose-built security processors and threat intelligence security services from FortiGuard labs to deliver top-rated protection and high performance, including encrypted traffic.
pjang
Staff
Staff
Article Id 208622

Description

 

This article describes a potential cause for why SSL VPN connections may fail on Windows 11 yet work correctly on Windows 10.

The following symptoms/situational behaviors are associated with this problem:

 

  • SSL VPN web-mode is working correctly for both Windows 10 and Windows 11.
  • Packet captures indicate that the TLS connection between FortiGate and FortiClient is established, yet SSL VPN connections fail regardless.
  • SSL VPN tunnel-mode connections via FortiClient fail at 48% on Windows 11, citing the following error: 'Credential or SSLVPN configuration is wrong (-7200)'. By comparison, tunnel-mode connections work fine on Windows 10.
  • Under config vpn ssl settings, the ciphersuite setting has been modified from the default. More specifically, the TLS-AES-256-GCM-SHA384 option has been removed by an administrator.
  • Users are unable to authenticate if they are in a User Group that is configured in an SSL VPN Authentication/Portal Mapping (aka 'authentication-rule' in the CLI), but successfully authenticate when using the 'All Other Users/Groups' catch-all authentication rule.

 

Scope

 

SSL VPN, FortiGate, FortiClient.

 

Solution

 

As a primer, be aware of the following key details:

 

  • Windows 11 uses TLS 1.3 by default for outbound TLS connections, whereas Windows 10 uses TLS 1.2 by default.

 

See the following documentation from Microsoft for Windows 10 for TLS Cipher Suites support:

https://learn.microsoft.com/en-us/windows/win32/secauthn/tls-cipher-suites-in-windows-10-v22h2

 

  • The ciphersuite setting (found under config vpn ssl settings on the FortiGate) governs the list of supported TLS Cipher Suites used for TLS 1.3 connections specifically (it has no bearing on TLS 1.2 or lower SSL VPN Connections).

  • When an SSL VPN Authentication/Portal Mapping is created, a setting called cipher is present in the CLI and is set to high by default. This setting dictates what the minimum acceptable strength is for the encryption cipher being used for SSL VPN, and it is based on the number of bits used in the encryption keys.

 

With the above in mind, the following is an overview of the events leading up to (and explaining) the SSL VPN connection failure (skip to the bottom of this article for the summarized solution).

 

  1. As mentioned in the essential details, Windows 11 uses TLS 1.3 by default for outbound TLS connections. This in turn means that FortiClient on Windows 11 will use TLS 1.3 when establishing an SSL VPN connection to the FortiGate.

  2. Upon receiving this TLS 1.3 connection request from FortiClient, the FortiGate will check the ciphersuite setting and utilize the list of allowed TLS 1.3 ciphersuites. By default, this list will include TLS-AES-128-GCM-SHA256, TLS-AES-256-GCM-SHA384, and TLS-CHACHA20-POLY1305-SHA256. However, the issue arises when TLS-AES-256-GCM-SHA384 is removed from this list (e.g. modified by an administrator).

  3. If TLS-AES-256-GCM-SHA384 is removed from the list, Windows 11/FortiClient will still be able to establish a TLS 1.3 connection using one of the alternative TLS Cipher Suites available. This will appear as a successful TLS connection in a packet capture tool like Wireshark.

  4. Once this initial TLS connection is established, FortiClient and FortiGate will proceed with handling authentication for the SSL-VPN. This is where the issue occurs.

  5. If a User Group has been set in an Authentication/Portal Mapping, the FortiGate will assess this authentication-rule and check the cipher set.

 

  • As mentioned above, the cipher setting is set to high by default. This setting specifically designates the acceptable key strength of the encryption cipher being used to greater than or equal to 168 bits.

  • If TLS-AES-256-GCM-SHA384 has been removed from the ciphersuite setting, then it is very likely that Windows 11 will establish a TLS 1.3 connection using TLS-AES-128-GCM-SHA256 as the agreed upon cipher suite. However, AES-128-GCM uses a 128-bit key, which is technically insufficient to meet the cipher high setting.

  • This results in the incoming FortiClient connection being ineligible for this authentication rule, and so the FortiGate will not include it during the authentication phase.

  • Notably, debugs of the SSL VPN process on the FortiGate will show that the expected User Group is absent during authentication.

 

Since the expected User Group could not be matched during the authentication phase of SSL VPN (due to the chosen SSL VPN ciphersuite being insufficient to meet the default cipher setting), FortiClient will be unable to complete authentication to the SSL VPN and the VPN tunnel will fail to establish.

 

Ultimately, Windows 11 may be unable to connect to the SSL VPN if a) the ciphersuite setting on the FortiGate has been modified to remove TLS-AES-256-GCM-SHA384, and b) an SSL VPN authentication rule has been created for a given User Group that has the cipher setting set to high (which it is by default).

 

As a side note, TLS-CHACHA20-POLY1305-SHA256 is included in the default ciphersuite list on the FortiGate, and Windows 11 does support this ciphersuite for TLS 1.3.

However, it is not enabled by default for Windows 11, so it is not utilized for TLS 1.3 connections by default.

 

See the following documentation from Microsoft:

https://docs.microsoft.com/en-us/windows/win32/secauthn/tls-cipher-suites-in-windows-11).

 

Issuing one of the two following commands should resolve the problem:


config vpn ssl settings
    unset ciphersuite OR append ciphersuite TLS-AES-256-GCM-SHA384
end