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.
acardona
Staff
Staff
Article Id 338136
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:

  • Users encounter a 'Permission denied' error during SSL-VPN authentication.
  • Debug logs indicate that the SSL-VPN daemon does not validate the 2FA token.
  • FortiToken-Email is successfully sent, but login attempts fail.

Cause:

  • The issue arises due to a software issue in v7.2.9.
  • This issue is caused by a discrepancy in token timeout values, leading to authentication failures when the username matches the email address used for 2FA token delivery.

 

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
idle-timeout : 300
auth-timeout : 28800
login-timeout : 120
set two-factor-ftk-expiry 300
set two-factor-ftm-expiry 168

 

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.
2024-08-31 16:19:31 [796] create_auth_token_session-Created auth token session 363279387
2024-08-31 16:19:51 [2344:root:c]Timeout for connection 0x7f064f855800. -----> Session closed due to timeout.

 

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
2024-08-31 16:20:33 [2342:root:d]rmt_web_access_check:793 access failed, uri=[/remote/logincheck],ret=4103,
2024-08-31 16:20:33 [2342:root:d]fsv_logincheck_common_handler:1350 user 'acardona' has a matched local entry.
2024-08-31 16:20:33 [2342:root:d]got checking id 1-30d489eb
2024-08-31 16:20:33 [2342:root:0]fsv_logincheck_common_handler:1479 token_type = 0, time_out = 30

 

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 [2202] handle_req-Rcvd auth_token rsp for req 318516171
2025-01-02 09:12:17 [2246] handle_req-Auth token result(-1) for user 'USERNAME'

2025-01-02 09:12:17 [2321] handle_req-Token check failed, result -1
2025-01-02 09:12:17 [209] fnbamd_comm_send_result-Sending result 1 (nid 0) for req 318516171, len=2544
2025-01-02 09:12:17 [209] fnbamd_comm_send_result-Sending result 1 (nid 0) for req 318516171, len=2544
2025-01-02 09:12:17 [808] destroy_auth_session-delete session 318516171
2025-01-02 09:12:17 [755] __ldap_destroy-
2025-01-02 09:12:17 [16307:VDOM:f843e]2025-01-23 09:12:17 [1764] fnbamd_ldap_auth_ctx_free-
fam_auth_proc_resp:1369 fnbam_auth_update_result return: 1 (invalue username/password)
2025-01-02 09:12:17 [1086] fnbamd_ext_idps_destroy-
2025-01-02 09:12:17 [16907:VDOM:f843e][fam_auth_proc_resp:1470] Authenticated groups (2) by FNBAM with auth_type (16):
2025-01-02 09:12:17 [16307:VDOM:f843e]Received: auth_rsp_data.grp_list[0] = 2098208
2025-01-02 09:12:17 [16307:VDOM:f843e]Received: auth_rsp_data.grp_list[1] = 0
2025-01-02 09:12:17 [16307:VDOM:f843e]login_failed:404 user[USERNAME],auth_type=16 failed [sslvpn_login_permission_denied]

 

Currently, there is no workaround available for this issue in v7.2.9. Users encountering this problem must upgrade to v7.2.10.