| Description |
This article describes how to enforce a SAML session timeout for IPsec remote access VPN users, ensuring they are required to reauthenticate after a specified period. |
| Scope |
|
| Solution |
In environments where remote users access sensitive resources over a VPN, enforcing session timeouts enhances security by requiring periodic reauthentication. This ensures the user's identity is continuously validated, reducing the risk of unauthorized access from idle or hijacked sessions.
SAML Authentication Behavior.
Currently, SAML authentication is performed only during the initial tunnel establishment. After the user is authenticated, the IPsec tunnel continues to operate based on the established session. On the SAML IdP (in this case, FortiAuthenticator), the default session timeout is 480 minutes (8 hours). This can be monitored under SAML IdP Session Lists.
What Happens During Reconnection.
If the tunnel disconnects before the timeout period ends, and the user attempts to reconnect, a SAML login request is sent to FortiAuthenticator. If the FortiAuthenticator still holds a valid session for the user, the VPN reconnects without prompting for credentials or MFA.
New Feature in FortiOS 7.4.1.
Starting with FortiOS 7.4.1, a new option under the 'config user saml' CLI section allows administrators to enforce reauthentication for SAML users, regardless of the FortiAuthenticator's session state.
To make this effective, the FortiAuthenticator must also be configured to expire login sessions after the desired timeout period. This ensures that after the session timeout, users are required to go through the full SAML authentication process again, including MFA, if configured.
config user saml edit <name> set reauth {enable | disable} Default value is disable next end
For demonstration purposes, the following configuration settings are applied.
FGT # config vpn ipsec phase1-interface FGT (phase1-interface) # edit Dialup-TimeOut FGT (Dialup-TimeOut) # show config vpn ipsec phase1-interface edit "Dialup-TimeOut" set ike-version 2 set keylife 360 set reauth enable next end
FGT# config user saml FGT(saml) # edit SAML-IPSEC FGT(SAML-IPSEC) # show config user saml edit "SAML-IPSEC" set cert "Fortinet_CA_SSL" set entity-id "http://10.9.10.111:1001/remote/saml/metadata/" set single-sign-on-url "https://10.9.10.111:1001/remote/saml/login" set single-logout-url "https://10.9.10.111:1001/remote/saml/logout" set idp-entity-id "http://10.9.10.186/saml-idp/ipsec/metadata/" set idp-single-sign-on-url "https://10.9.10.186/saml-idp/ipsec/login/" set idp-single-logout-url "https://10.9.10.186/saml-idp/ipsec/logout/" set idp-cert "REMOTE_Cert_3" set user-name "username" set digest-method sha1 set reauth enable next end
When a remote user connects, SAML debugs 'SP Login Dump' will have the ForceAuth value set to True.
FGT # diagnose debug application samld -1 FGT # diagnose debug enable
__samld_sp_create_auth_req [472]: **** SP Login Dump **** <lasso:Login xmlns:lasso="http://www.entrouvert.org/namespaces/lasso/0.0" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" LoginDumpVersion="2"><lasso:Request><samlp:AuthnRequest ID="_F05D859DEAA785FC0013DD33C8628902" Version="2.0" IssueInstant="2025-09-22T21:08:08Z" Destination="https://10.9.10.186/saml-idp/ipsec/login/" SignType="0" SignMethod="0" ForceAuthn="true" IsPassive="false" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" AssertionConsumerServiceURL="https://10.9.10.111:1001/remote/saml/login"><saml:Issuer>http://10.9.10.111:1001/remote/saml/metadata/</saml:Issuer><samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" AllowCreate="true"/></samlp:AuthnRequest></lasso:Request><lasso:RemoteProviderID>http://10.9.10.186/saml-idp/ipsec/metadata/</lasso:RemoteProviderID><lasso:MsgUrl>https://10.9.10.186/saml-idp/ipsec/login/?SAMLRequest=xxx;Signature=xx</lasso:MsgUrl><lasso:MsgRelayState>magic=040c048995bc76ba</lasso:MsgRelayState><lasso:HttpRequestMethod>4</lasso:HttpRequestMethod><lasso:RequestID>_F05D859DEAA785FC0013DD33C8628902</lasso:RequestID></lasso:Login>
On the FortiAuthenticator, a session information will be added with a validity of 5 minutes from authentication time.
The remote user connects to the VPN. IKE debugs show that the tunnel came up at 17:18:33.
FGT # diagnose debug application ike -1 FGT # diagnose debug console timestamp enable FGT # diagnose debug enable 2025-09-23 17:18:33.287727 ike V=root:0:Dialup-TimeOut_0:264:Dialup-TimeOut:913: added IPsec SA: SPIs=0882a8d1/cf9e1dc5 2025-09-23 17:18:33.288773 ike V=root:0:Dialup-TimeOut_0:264:Dialup-TimeOut:913: sending SNMP tunnel UP trap
As the 'keylife' value is set to 6 minutes for testing purposes and 'reauth' is enabled under phase1-interface configuration, the tunnel goes down and does not re-key due to reauthorization requirements. IKE debug output shows that the tunnel went down at 17:24:33.
FGT # diagnose debug application ike -1 FGT # diagnose debug console timestamp enable FGT # diagnose debug enable 2025-09-23 17:24:33.222213 ike V=root:0:Dialup-TimeOut_0:264: expiring IKE SA 99fc5cb379810d8d/447560ac1449a010 2025-09-23 17:24:33.223199 ike V=root:0:Dialup-TimeOut_0: going to be deleted 2025-09-23 17:24:33.223999 ike V=root:0:Dialup-TimeOut_0: sent tunnel-down message to EMS: (fct-uid=440F2683C7854FBFB73A528151E1FB25, intf=Dialup-TimeOut_0, addr=10.58.25.2, vdom=root) 2025-09-23 17:24:33.225518 ike V=root:0:Dialup-TimeOut_0: flushing 2025-09-23 17:24:33.226158 ike V=root:0:Dialup-TimeOut_0: deleting IPsec SA with SPI cf9e1dc5 2025-09-23 17:24:33.226963 ike V=root:0:Dialup-TimeOut_0:Dialup-TimeOut: deleted IPsec SA with SPI cf9e1dc5, SA count: 0 2025-09-23 17:24:33.228012 ike V=Dialup-TimeOut:0:Dialup-TimeOut:913: del route 10.58.25.2/255.255.255.255 tunnel 10.58.25.2 oif Dialup-TimeOut(28) metric 15 priority 1 2025-09-23 17:24:33.230758 ike V=root:0:Dialup-TimeOut_0: sending SNMP tunnel DOWN trap for Dialup-TimeOut
At this point, checking the SAML session list on FortiAuthenticator shows that the session has expired and has been flushed. When users attempt to reconnect, they will be prompted to sign-in using their credentials again. This ensures that users reauthenticate after a specific period.
Other scenarios:
If reauth is enabled under phase1-interface and the tunnel expires before the expiration of SAML session on the FortiAuthenticator: the tunnel will go down as user will be asked to re-authenticate. However, in this scenario, after user select 'Connect', users will not be prompted to login again. On SAML debugs, there will still be SAML auth login request, but when the FortiAuthenticator receives this, it will validate its SAML session information. If a valid session is found, user is not prompted to reauthenticate.
To demonstrate this, the following configurations are applied.
The VPN tunnel connected at 17:40:32.
FGT # diagnose debug application ike -1 FGT # diagnose debug console timestamp enable FGT # diagnose debug enable 2025-09-22 17:40:32.423320 ike V=root:0:Dialup-TimeOut_0:266:Dialup-TimeOut:916: added IPsec SA: SPIs=0882a8d3/f21a4102 2025-09-22 17:40:32.424571 ike V=root:0:Dialup-TimeOut_0:266:Dialup-TimeOut:916: sending SNMP tunnel UP trap 2025-09-22 17:40:32.425449 ike V=root:0:Dialup-TimeOut_0: tunnel up event assigned address 10.58.25.2
After 2 minutes, the tunnel went down at 17:42:32
FGT # diagnose debug application ike -1 FGT # diagnose debug console timestamp enable FGT # diagnose debug enable 2025-09-22 17:42:32.363431 ike V=root:0:Dialup-TimeOut_0: deleting IPsec SA with SPI f21a4102 2025-09-22 17:42:32.364283 ike V=root:0:Dialup-TimeOut_0:Dialup-TimeOut: deleted IPsec SA with SPI f21a4102, SA count: 0 2025-09-22 17:42:32.365264 ike V=Dialup-TimeOut:0:Dialup-TimeOut:916: del route 10.58.25.2/255.255.255.255 tunnel 10.58.25.2 oif Dialup-TimeOut(28) metric 15 priority 1 2025-09-22 17:42:32.368387 ike V=root:0:Dialup-TimeOut_0: sending SNMP tunnel DOWN trap for Dialup-TimeOut
During this time, there is still a valid SAML session on the FortiAuthenticator. When users attempt to reconnect, VPN will be connected without an SAML prompt.
SAML debugs show another SAML login request was sent.
FGT # diagnose debug application samld -1 FGT # diagnose debug enable __samld_sp_create_auth_req [467]: **** AuthnRequest **** <samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="_C68338FD02A922D9A4BFC7CA0EAE784D" Version="2.0" IssueInstant="2025-09-22T17:43:44Z" Destination="https://10.9.10.186/saml-idp/ipsec/login/" SignType="0" SignMethod="0" ForceAuthn="true" IsPassive="false" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" AssertionConsumerServiceURL="https://10.9.10.111:1001/remote/saml/login"><saml:Issuer>http://10.9.10.111:1001/remote/saml/metadata/</saml:Issuer><samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" AllowCreate="true"/></samlp:AuthnRequest> ***********************
When 'reauth' is not set under phase1-configuration and the tunnel expires; the tunnel will re-key and will not go down. During this process, there will still be an SAML auth login request, but when the FortiAuthenticator receives this, it will validate its SAML session information. If a valid session is found, the user is not prompted to re-authenticate.
For this to work, FortiAuthenticator must also enforce login session timeout (or conditional access in other SAML Identity Providers) to flush the sessions after a specified time.
Related article: |
