Description | This article describes an issue where SSL-VPN authentication fails with a 'Permission denied' error when the username matches the email address used for FortiToken-Email two-factor authentication (2FA). Although the FortiToken-Email is delivered successfully, the SSL-VPN daemon does not validate the 2FA. Same behavior are users facing with SMS 2FA. This behavior is identified after upgrading to v7.2.9 |
Scope | FortiGate, FortiClient, v7.2.9. |
Solution |
This issue is specific to FortiGate devices running FortiOS v7.2.9 configured with SSL VPN and FortiToken-Email 2FA, as well 2FA SMS FortiToken where the username and email address are identical. The problem does not occur in v7.2.10 or when the username and email address are different.
Symptoms:
Cause:
Related article: SSL VPN and two-factor expiry timers
The issue that causes the 2FA to fail is the SSL VPN will close the session in 30 seconds, it will not follow the correct timers for each token type.
The next is an example for FortiToken and local users.
FortiGate values for SSL VPN timeout and global timeouts for each 2FA token.
FGVM04TM24003657 (settings) # get | grep timeout
In the Debug commands, it closes the session before the timeout of the token:
2024-08-31 16:19:30 [2343:root:c]allocSSLConn:310 sconn 0x7f064f855800 (0:root) -------------> Session created.
When the user introduces the token after 30 seconds the error will show, not session info.
2024-08-31 16:20:33 [2342:root:d]rmt_web_auth_info_parser_common:525 no session id in auth info
Possible error like this can occur during the process:
2025-01-02 09:12:17 [285:VDOM:152a51]allocSSLConn:310 sconn 0x7f8656a800 (2:VDOM) 2025-01-02 09:12:17 [2321] handle_req-Token check failed, result -1
Currently, there is no workaround available for this issue in v7.2.9. Users encountering this problem must upgrade to v7.2.10. |