| 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.
Multiple RADIUS servers associated with the same dial-up gateway are not supported. See the KB article Technical Tip: IKEv2 dialup gateway with RADIUS user groups does not support other authentication se....
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 with the default EAP server certificate 'Fortinet_Wifi'. 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.
Note: FortiGate cannot authenticate Active Directory users against an LDAP server directly using EAP-MSCHAPv2; see this KB article Technical Tip: IKEv2 dial up VPN with LDAP authentication.
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 Technical Tip: Authenticating users using MSCHAP2 PEAP
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)
This limitation does not affect FortiTokens assigned on the FortiGate. In v7.4.9 and later, users with locally assigned tokens authenticating using EAP-TTLS can receive the token prompt as expected. See Issue ID# 1031789 in FortiOS v7.4.9 Release Notes | 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. 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, 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.
Signature Authentication is enabled using the following configuration in FortiOS. config vpn ipsec phase1-interface edit <tunnel> set eap enable set eap-cert-auth {*disable | enable} set peer <user peer> next end
When configured with X.509 certificate as an authentication method, FortiClient supports submitting a certificate to FortiOS IKEv2 for IKE authentication, then continuing to the configured EAP method (EAP-MSCHAPv2 or EAP-TTLS) for user authentication. See this KB article: Technical Tip: Certificate authentication for IKEv2 VPN with RADIUS or LDAP user authentication.
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.
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 |
