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.



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 they can successfully authenticate when using the 'All Other Users/Groups' catch-all authentication rule.




SSL-VPN, FortiGate, FortiClient.




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


- Windows 11 is uses TLS 1.3 by default for outbound TLS connections, whereas Windows 10 appears to use TLS 1.2 by default.


- 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 upon 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 key 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 such as Wireshark.


4) Once this initial TLS connection is established, FortiClient and the 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 setting.


- 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 sslvpn process on the FortiGate will show that the expected User Group is absent during authentication.


6) 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:


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