| To troubleshoot the issue where the Session-Timeout AVP received from a RADIUS server is not enforced on an IPsec RADIUS VPN, follow these steps:
- RADIUS server: 10.0.32.100.
- FortiGate server: 10.3.254.100.
 - Make sure the RADIUS server is sending the Session-Timeout attribute (27) with the correct value. In this case, the value should be 60 seconds and not 0 seconds.
diagnose sniffer packet any "host 10.0.32.100 and port 1812" 6 0 l 
- Verify that the FortiGate is receiving the Session-Timeout attribute from the RADIUS server. This can be done by checking the FortiGate debug logs (fnbamd/radiusd).
diagnose debug reset diagnose debug console timestamp enable diagnose debug application fnbamd -1 diagnose debug application radiusd -1 diagnose debug enable 2026-02-06 09:46:34 [1774] handle_req-Rcvd auth req 31022561972226 for customer.fgt in opt=0400001d prot=3 svc=7
...
...
2026-02-06 09:46:34 [965] __rad_rxtx-Sent radius req to server 'FAC-10.0.32.100': fd=10, IP=10.0.32.100(10.0.32.100:1812) code=1 id=52 len=208
2026-02-06 09:46:34 [974] __rad_rxtx-Start rad conn timer.
2026-02-06 09:46:34 [934] __rad_rxtx-fd 10, state 1(Auth)
2026-02-06 09:46:34 [936] __rad_rxtx-Stop rad conn timer.
2026-02-06 09:46:34 [977] __rad_rxtx-
2026-02-06 09:46:34 [485] __rad_udp_recv-Recved 292 bytes. Buf sz 262144
2026-02-06 09:46:34 [1133] __rad_chk_resp_authenticator-The Message Authenticator validation is mandatory now
2026-02-06 09:46:34 [1156] __rad_chk_resp_authenticator-ret=0
2026-02-06 09:46:34 [1231] fnbamd_rad_validate_pkt-RADIUS resp code 2 <-- Response was RADIUS response code 2=Access-Accept
2026-02-06 09:46:34 [1003] __rad_rxtx-
2026-02-06 09:46:34 [1301] fnbamd_rad_process-Result from radius svr 'FAC-10.0.32.100' is 0, req 31022561972226
2026-02-06 09:46:34 [530] fnbamd_rad_get_vsas-FORTINET attr, type 1, val IT
2026-02-06 09:46:34 [530] fnbamd_rad_get_vsas-FORTINET attr, type 1, val RandD
2026-02-06 09:46:34 [530] fnbamd_rad_get_vsas-FORTINET attr, type 1, val RadAdmin
2026-02-06 09:46:34 [920] fnbamd_radius_parse_mschapv2_attr-Decoding TYPE_MS_MPPE_Recv_Key
2026-02-06 09:46:34 [843] __radius_decode_mppe_key-Key len after decode 16
2026-02-06 09:46:34 [931] fnbamd_radius_parse_mschapv2_attr-Decoding TYPE_MS_MPPE_Send_Key
2026-02-06 09:46:34 [843] __radius_decode_mppe_key-Key len after decode 16
2026-02-06 09:46:34 [1503] fnbamd_rad_process-Challenged: 0, FTK_Challenge: 0, CHG_PWD: 0, Invaid_Digest: 0, No_Message_Authenticator_Attr: 0, State_Len: 0
2026-02-06 09:46:34 [195] find_matched_usr_grps-Skipped group matching
2026-02-06 09:46:34 [912] update_auth_token_session-config does not require 2fa
2026-02-06 09:46:34 [239] fnbamd_comm_send_result-Sending result 0 (nid 0) for req 31022561972226, len=2615
2026-02-06 09:46:34 [603] destroy_auth_session-delete session 31022561972226
2026-02-06 09:46:34 [1436] fnbamd_rad_stop-
2026-02-06 09:46:34 [1060] __rad_stop-
2026-02-06 09:46:34 [356] __rad_udp_close-closed.
2026-02-06 09:46:34 [1055] __rad_conn_stop-Stop rad conn timer.
2026-02-06 09:46:34 [890] __rad_del_job_timer-
2026-02-06 09:46:34 [1444] fnbamd_rads_destroy- From Access-Accept, it printed: Fortinet VSA Group-Name: IT, RandD, RadAdmin.
MS-MPPE keys (Recv/Send Key) for MS-CHAPv2
However, it is not being processed through the dial-up IPsec tunnel.
To confirm if the FortiGate received the attribute, a sniffer should be used, like in the first step:
diagnose sniffer packet any "host 10.0.32.100 and port 1812" 6 0 l
- Check the FortiGate configuration to ensure that it is set to respect the Session-Timeout value received from the RADIUS server. This can be done by running the command config user setting and checking the radius-ses-timeout-act and auth-timeout settings.
- If the issue persists, try setting the radius-ses-timeout-act to hard-timeout and the auth-timeout to a non-zero value (e.g., 5 minutes).
config user setting
set auth-timeout 5
set auth-timeout-type hard-timeout
set radius-ses-timeout-act hard-timeout
end
Note that the Session-Timeout AVP received from the RADIUS server may not be used by the FortiGate to terminate the VPN session in all cases. The FortiGate may use other mechanisms, such as the tunnel idle timeout, to control the behavior of the VPN session.
If the issue persists, try using the Tunnel idle timeout instead of the Session-Timeout attribute to control the behavior of the IPSEC RA VPN. The Tunnel idle timeout can be configured using the command config vpn ipsec phase1 and setting the idle-timeout parameter.
What usually controls behavior is:
Tunnel idle timeout (cuts off due to inactivity, not absolute time).
SSL VPN does have an auth-timeout, but IPsec/IKEv2 EAP does not always have a hard-logout per user.
Related article:
Technical Tip: IKEv2 dialup IPsec tunnel with RADIUS server authentication and FortiClient | 
