Technical Tip: FortiOS IKEv2 EAP user authentication operation
| Description | This article clarifies how different EAP methods operate when performing IKEv2 user authentication on FortiOS. |
| Scope | FortiOS v7.2 and later, IKEv2. |
| Solution | User authentication for an existing IKEv2 tunnel is enabled by applying the following configuration:
config vpn ipsec phase1-interface edit <tunnel> set eap enable set eap-identity send-request set authusrgrp '' <----- User group applied here or on firewall policy, not both. next end
External RADIUS server:
If an external RADIUS server is configured for the VPN, FortiOS does not terminate the EAP-TTLS tunnel on its internal eap_proxy RADIUS server. Instead, it passes the EAP-TTLS connection attempt through to the external RADIUS server. EAP-TTLS with PAP as an inner method must be supported and properly configured on the external RADIUS server, or the authentication attempt will fail.
The EAP method attempted is configured on the client, and the default is EAP-MSCHAPv2. If EAP-TTLS/PAP is in use, the EAP server certificate is configured on the remote RADIUS server. Unlike EAP-TLS, EAP-TTLS does not require the use of client certificates.
Multiple RADIUS servers associated with the same dial-up gateway are not supported. See the KB article Technical Tip: IKEv2 dial-up gateway with RADIUS user groups does not support other authentication servers.
EAP-TTLS with no External RADIUS server:
If EAP-TTLS is used and no external RADIUS server is configured for the VPN, the EAP-TTLS tunnel terminates on the FortiGate's own internal RADIUS server. Since the firewall can view the user’s original plaintext credentials in this case, FortiOS attempts to authenticate them against the set of local users and remote LDAP servers configured for the tunnel.
Notes:
config system global set wifi-certificate "Fortinet_Wifi" <-- default setting. end
Two-factor authentication: When the user's FortiToken is hosted on a FortiAuthenticator, EAP-MSCHAPv2 must be used for the user to see a token prompt or get a push notification. This can be used to trigger token prompts for on-premises Active Directory users when the FortiAuthenticator is joined to the Active Directory domain. See this article: Technical Tip: Authenticating users using MSCHAP2 PEAP.
When authenticating against a remote RADIUS server that performs 2FA, extending the RADIUS timeout is usually required.
config user radius edit <server name> set timeout 60 next end
When EAP-TTLS must be used, FortiAuthenticator does not support sending the prompt, but the user may append the token code to their password as a workaround. See this KB article: Technical Tip: Multi-Factor Authentication support for Windows FortiClient with LDAP (EAP-TTLS).
The default IPsec negotiation timeout is 30 seconds. If OTP entry takes longer, the IPsec connection may expire, preventing access even after successful authentication. Consider increasing the IPsec negotiation timeout to allow enough time for users to enter their one-time password (OTP) or accept the token prompt.
config vpn ipsec phase1-interface edit <tunnel name> set negotiate-timeout 60 <----- Enter an integer value from <1> to <300> <-- Default = <30>. next end
Note: If using FortiTokens provisioned on FortiGate, EAP-TTLS authentication requires FortiOS v7.4.9 and FortiClient Windows v7.4.4. See Technical Tip: Multi-Factor Authentication support for Windows FortiClient with LDAP (EAP-TTLS) and issue ID# 1031789 in Resolved Issues
FortiClient IKEv2 only supports initiating EAP-MSCHAPv2 and EAP-TTLS authentication. However, the internal RADIUS server used by the FortiOS EAP proxy does support other EAP methods, and external RADIUS servers may support other EAP methods according to the configuration.
Properly configured third-party VPN clients supporting other EAP methods may authenticate successfully to FortiOS IKEv2 dial-up VPN, but are outside the scope of this document. SAML authentication: Requirements:
SAML authentication is not an EAP method. When SAML authentication is in use, FortiClient initiates an HTTPS connection to the FortiGate as the SAML Service Provider (SP) first. After SAML redirect and authentication with the SAML IDP, FortiClient presents the SAML cookie to the FortiGate, which caches a user authentication entry internally.
FortiClient attempts to connect to the IKEv2 dial-up gateway. FortiClient authenticates FortiGate using pre-shared key or signature authentication, then proves ownership of the cached user authentication by authenticating itself against the FortiGate eap_proxy using EAP-MSCHAPv2 or EAP-TTLS. For this reason, it is still required to enable EAP on the FortiGate phase1-interface configuration, even though SAML is not an EAP method.
When configuring a single-sign-on tunnel on FortiClient, it is recommended leave eap_method at the default value. Signature (Certificate) Authentication is often used as a granular and more secure alternative to pre-shared key authentication for IKE peers. This is different from using certificate methods such as EAP-TLS or EAP-TTLS for user authentication.
When configured with 'signature' as an authentication method, FortiClient supports submitting a certificate to FortiOS IKEv2 for validation, then continuing to the configured EAP method (EAP-MSCHAPv2 or EAP-TTLS) for authentication. See the following articles: Technical Tip: Certificate authentication for IKEv2 VPN with RADIUS or LDAP user authentication IPsec IKEv2 VPN 2FA with EAP and certificate authentication
Certificate authentication as an additional step is enabled using the following configuration in FortiOS. config vpn ipsec phase1-interface edit <tunnel> set authmethod signature set peertype peer set eap enable set eap-cert-auth {*disable | enable} set peer <user peer> next end
In site-to-site VPN or hub-and-spoke VPN topologies, FortiGate supports mutual signature authentication, but does not support authenticating itself as a user after this step. That is, FortiOS as a VPN client does not support user/password authentication for IKEv2. This functionality does exist for IKEv1, see this document: Using XAuth authentication for FortiGate XAUTH client configuration.
Troubleshooting commands: IKE and fnbamd debugs can also be used to investigate and check the steps of IKE negotiation and authentication on the FortiGate.
diagnose vpn ike log filter rem-addr4 <remote_side_publicIP> diagnose debug application fnbamd -1 diagnose debug application eap_proxy -1 diagnose debug console timestamp enable To disable the debug after testing: diagnose debug disable diagnose vpn ike log filter clear diagnose debug reset |
