Technical Tip: Explaining global 'set remoteauthtimeout', user radius 'set timeout', and how they work together
Description
This article describes the global 'set remoteauthtimeout' and user radius 'set timeout', as well as how they work together.
Scope
FortiOS.
Solution
The two timeout values have different uses:
- remoteauthtimeout (global setting): It defines the total process time for RADIUS authentication on the FortiGate, including Access-Request, Access-Challenge, Access-Accept, and Access-Reject.
- timeout (radius setting): defines how long the FortiGate will wait before re-sending the same RADIUS Access-Request ID.
Consider a scenario where multiple RADIUS servers are in use, such as in the configuration below:
config user radius
edit "1"
set server "10.200.0.100"
set secret ENC <>
set secondary-server "10.200.0.101"
set secondary-secret ENC <>
next
end
FortiGate will try to use server 10.200.0.100 first and, after a certain period of time with no response (determined by remoteauthtimeout), will abort the attempt and connect to the second server, 10.200.0.101.
The default value of remoteauthtimeout is 5 seconds.
get | grep remoteauthtimeout
remoteauthtimeout : 5
This means that, after 5 seconds, the FortiGate will use 10.200.0.101:
However, there is a second timeout value that controls the interval that the FortiGate will wait before it queries the same server again. The value can be set under 'config user radius'. Its default setting is also 5 seconds.
config user radius
edit 1
get | grep timeout
timeout : 5
If both globals are set to their default, the FortiGate will make a second attempt to connect to the first server before aborting the attempt and connecting to the second server instead:
If remoteauthtimeout is changed to a higher value, the FortiGate will make as many attempts as 'set interval' fits into the value. For example, when remoteauthtimeout is 10 seconds, and the default interval between retries is 5 seconds, FortiGate will attempt 2 retries before the secondary server is used:
Finally, if the timeout value under user radius is higher than remoteauthtimeout, no retry will be attempted. The secondary server will be used as soon as the remoteauthtimeout is reached.
To successfully authenticate, the remoteauthtimeout should be extended to cover the Access-Request and Access-Challenge if necessary.
By default, the Access-Challenge timeout is 90 seconds. FortiGate will wait for the Access-Challenge for 90 seconds. This value is hard-coded, and it is not configurable.
Take into consideration that these timers do not affect the wireless connection, because Wi-Fi cannot wait longer to complete authentication.
Example change without VDOM:
config system global
set remoteauthtimeout 10
end
Example change with VDOM:
config global
config system global
set remoteauthtimeout 10
end
IKEv2 Multi-Factor Authentication:
In non-IKEv2 RADIUS multi-factor authentication, RADIUS Access-Challenge is frequently used to trigger a user token prompt. This allows the user the hard-coded 90-second interval to complete multi-factor authentication, provided remoteauthtimeout is long enough. In IKEv2, custom EAP messages are used to trigger multi-factor authentication, and FortiOS will not see Access-Challenge messages.
For this reason, when multi-factor authentication is triggered on a remote RADIUS server such as FortiAuthenticator, FortiOS v6 and v7: both the remoteauthtimeout and RADIUS timeout must be configured to allow sufficient time to complete multi-factor authentication. Additionally, it is recommended to configure the 'negotiate-timeout' setting with enough time to complete the Authentication and VPN process.
config user radius
edit <radius server name>
set timeout 60
next
end
config system global
set remoteauthtimeout 60
end
config vpn ipsec phase1-interface
edit <VPN name>
set negotiate-timeout 120
next
end
Related article:
