FortiGate
FortiGate Next Generation Firewall utilizes purpose-built security processors and threat intelligence security services from FortiGuard labs to deliver top-rated protection and high performance, including encrypted traffic.
Matt_B
Staff & Editor
Staff & Editor
Article Id 418199
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:

 

EAP_external.png

 

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:

 

EAP_internal.png

 

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:

LDAP users cannot be authenticated 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 by a FortiAuthenticator, EAP-MSCHAPv2 must be used for the user to see a token prompt or get a push notification. See this KB article Technical Tip: Multi-Factor Authentication support for Windows FortiClient with LDAP (EAP-TTLS)

 

For users who must use EAP-TTLS, such as remote LDAP users using FortiAuthenticator as a RADIUS proxy, the user may append the token code to their password as a workaround.

 

This does not affect FortiTokens assigned on the FortiGate. These users may receive the token prompt as expected. 


Other EAP methods:

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.

IKEv2 peer verification:

Signature (Certificate) Authentication is often used as a granular and more secure alternative to pre-shared key authentication for IKE peers. Note 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.

The IKE and fnbamd debugs can also be used to investigate and check the steps of IKE negotiation and authentication on the FortiGate.


The commands below can be used:

diagnose vpn ike log filter rem-addr4 <remote_side_publicIP>
diagnose debug application ike -1

diagnose debug application fnbamd -1
diagnose debug console timestamp enable
diagnose debug enable

To disable the debug after testing:

diagnose debug disable

diagnose debug reset