Description
This article describes how to force the Dialup IPsec client to re-authenticate after a configured time (with failure to do so leading to the client being disconnected from the VPN).
Scope
FortiGate.
Solution
For reference, IPsec dialup tunnels (such as those used to connect FortiClient to a FortiGate via IPsec) will have user authentication in addition to the Pre-Shared Keys (or certificates) already used for IPsec authentication. This authentication typically involves the user supplying a username, password, and MFA token (if configured) that the FortiGate checks against a configured authentication source (local users, LDAP, RADIUS, SAML, etc.)
If an administrator wants to force users to re-authenticate regularly then this can be forced for dialup IPsec clients by using the command set reauth enable in the IPsec Phase1 settings. When this option is enabled, the dialup client will be forced to re-submit their user credentials to the FortiGate whenever the IPsec Phase1 key lifetime is nearing expiration and performing a re-key operation.
Important Note:
when reauth is enabled, users are explicitly being made to reauthenticate to the FortiGate whenever Phase1 key lifetimes are nearing expiration. If these users are also using multi-factor authenticationthen they are required to enter those tokens as part of the re-authentication process (FortiClient cannot and should not save these MFA token credentials).
For organizations that use push notifications to send MFA token prompts to end-users, enabling this reauth feature can result in users receiving seemingly-random MFA pushes (triggered whenever IPsec Phase1 key lifetimes are approaching expiration for their VPN connections). Consider disabling reauth in scenarios where Phase1 key lifetimes are set very short or if users are wary of unexpected MFA push notifications (i.e. users are assuming that someone is trying to use their credentials without their consent).
With the above in mind, consider the following scenarios that outline the differences in the behavior of the reauth option when using IKEv1 vs IKEv2:
Scenario 1: set reauth disable with IKEv1 and IKEv2 (default):
When reauth is set to disable the FortiGate/FortiClient will simply rekey/refresh IPsec Phase1 without any user authentication as the key lifetime approaches expiration (i.e. VPN stays established, user receives no prompts to reauthenticate or re-enter MFA tokens).
Scenario 2: set reauth enable with IKEv1:
When reauth is enabled with IKEv1, the FortiGate will prompt the remote VPN client to reauthenticate. In lab testing, it seems like FortiClient can cache username/password credentials from the initial connection, so the user may not need to supply username/credentials for this reauthentication process (i.e. this is not a hard enforcement of manual re-authentication, though it does actually reauthenticate in the back-end in-case credentials have changed).
To enforce a hard re-authentication for IKEv1 dialup clients, it is necessary to enable multi-factor authentication for the user (e.g. using FortiToken, Duo, Okta, Microsoft, etc.). With MFA enabled, the user will be required at minimum to enter their MFA token or accept a push notification, and they may also need to re-enter their username/password credentials.
Configuration of reauth in phase1 settings:
config vpn ipsec phase1-interface
edit Test-Dialup
set reauth enable
set authusrgrp "test-group"
end
The following is the behavior seen in the IKE debugs when phase1 re-negotiates during the expiry of keylife time and FortiToken is required again.
Username: test-user.
Usergroup: test-group.
2024-08-27 10:51:25.553972 ike 0:Test-Dialup_0:585213: received XAUTH_USER_NAME 'test-user' length 4
2024-08-27 10:51:25.554013 ike 0:Test-Dialup_0:585213: received XAUTH_USER_PASSWORD length 9
2024-08-27 10:51:25.554056 ike 0:Test-Dialup_0: XAUTH user "test-user"
2024-08-27 10:51:25.554094 ike 0:Test-Dialup: auth group test-group
2024-08-27 10:51:25.555175 ike 0:Test-Dialup_0: XAUTH 993837392 pending
2024-08-27 10:51:25.573858 ike 0:Test-Dialup_0:585213: XAUTH 993837392 result 7
2024-08-27 10:51:25.574007 ike 0:Test-Dialup_0: XAUTH requires token for user "test-user"
2024-08-27 10:51:25.574056 ike 0:Test-Dialup_0:585213: sending XAUTH token request <----Reauth is initiated at this point.
Note that there is a timeout value to provide the FortiToken during the re-authentication. The timeout value is calculated using the formula below.
Fortitoken Timeout = 10 x remoteauthtimeout + 30 seconds
For example – remoteauthtimeout = 10 seconds
Fortitoken Timeout = 10 X 10 + 30 = 130 seconds
The following is the behavior when the FortiToken is not provided by the user within the timeout value, for example, 130 seconds.
2024-08-27 10:51:25.553972 ike 0:Test-Dialup_0:585213: received XAUTH_USER_NAME 'test-user' length 4
2024-08-27 10:51:25.554013 ike 0:Test-Dialup_0:585213: received XAUTH_USER_PASSWORD length 9
2024-08-27 10:51:25.554056 ike 0:Test-Dialup_0: XAUTH user "test-user"
2024-08-27 10:51:25.554094 ike 0:Test-Dialup: auth group test-group
2024-08-27 10:51:25.555175 ike 0:Test-Dialup_0: XAUTH 993837392 pending
2024-08-27 10:51:25.573858 ike 0:Test-Dialup_0:585213: XAUTH 993837392 result 7
2024-08-27 10:51:25.574007 ike 0:Test-Dialup_0: XAUTH requires token for user "test-user"
2024-08-27 10:51:25.574056 ike 0:Test-Dialup_0:585213: sending XAUTH token request <----Reauth is initiated at this point.
2024-08-27 10:53:35.568119 ike 0:Test-Dialup_0:585228: negotiation timeout, deleting
2024-08-27 10:53:35.568271 ike 0:Test-Dialup_0: connection expiring due to phase1 down
2024-08-27 10:53:35.568316 ike 0:Test-Dialup_0: deleting
2024-08-27 10:53:35.568815 ike 0:Test-Dialup_0: sent tunnel-down message to EMS: (fct-uid=xxxx, intf=Test-Dialup_0, addr=x.x.x.x, vdom=root)
2024-08-27 10:53:35.568993 ike 0:Test-Dialup_0: flushing
2024-08-27 10:53:35.569241 ike 0:Test-Dialup_0: flushed <----After 130 seconds, the connection is expired and the tunnel is DOWN.
Scenario 3: set reauth enable with IKEv2:
When reauth is enabled for dialup IPsec tunnels using IKEv2, the re-authentication is triggered for clients with/without MFA during the expiry of keylife time.
Configuration of reauth in phase1 settings:
config vpn ipsec phase1-interface
edit "IKEv2-Dialup"
set ike-version 2
set reauth enable
end
More information can be found using the document below:
IKEv2 re-authentication for Phase1
Related articles:
Troubleshooting Tip: Troubleshooting IPsec Site-to-Site Tunnel Connectivity
Technical Tip: How to configure VPN Site to Site between FortiGates (Using VPN Setup Wizard)
Troubleshooting Tip: IPsec VPNs tunnels
Technical Tip: Setting multiple DNS server for IPSec dial-up VPN
Technical Tip: NAT-traversal comparison between site-to-site and dial-up” dynamic” tunnels
Technical Tip: FortiGate Hub with multiple IPSec Dial-up phase1 using IKEv2 and PSK authentication
Technical Tip : How to configure multiple VPN tunnels from the same ISP to the same remote peer ISP.
Technical Tip: IPSec dial-up full tunnel with FortiClient
Technical Tip: Differences between Aggressive and Main mode in IPSec VPN configurations
Technical Note: Dynamic routing (BGP) over IPsec tunnel
Technical Tip: OSPF with IPSec VPN for network redundancy
Technical Tip: Dynamic dial-up VPN with OSPF
Technical Tip: Fortinet Auto Discovery VPN (ADVPN)
Technical Tip: 'set net-device' new route-based IPsec logic
Technical Tip: Simple OCVPN deployment
Technical Tip: SD-WAN integration with OCVPN
Technical Tip: Configure IPsec VPN with SD-WAN
Technical Tip: SD-WAN with DDNS type IPsec
Technical Tip: SD-WAN primary and backup ipsec tunnel Scenario
Troubleshooting Tip: IPsec VPN Phase 1 Process - Aggressive Mode
Technical Note : Configuring more than one Main-Mode Pre-Shared Key (PSK) *dialup* IPSec phase1 on a...
Technical Tip: How to configure IPsec VPN Tunnel using IKE v2
