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.
vbarrios
Staff
Staff
Article Id 339644
Description

This article describes how to solve the authentication problem 'gw validation failed' using IPsec Dial-up IKEv2.

Scope FortiGate.
Solution

When IPsec Dial-up is configured with IKEv2, the following errors may be displayed in the following debug outputs when attempting to connect to VPN.

diagnose vpn ike log-filter src-addr4 x.x.x.x  <----- Public IP address of the user attempting to connect to VPN.
diagnose debug app ike -1 

diagnose debug enable

     .

ike 0:REMOTE:77: peer identifier IPV4_ADDR x.x.x.x
ike 0:REMOTE:77: re-validate gw ID
ike 0:REMOTE:77: gw validation failed

 

ike 0:REMOTE: connection expiring due to phase1 down
ike 0:REMOTE: deleting
ike 0:REMOTE: deleted

 

Note:

Starting from v7.4.1, the 'diagnose vpn ike log-filter src-addr4 <IP>' command has been changed to 'diagnose vpn ike log filter loc-addr4 <IP>'. 

 

To display the list of filters, use a '?' after 'filter'.

diagnose vpn ike log filter ?

loc-addr4:   IPv4 local gateway address range to filter by.
mloc-addr4:  Multiple IPv4 local gateway address to filter by.
rem-addr4:   IPv4 remote gateway address range to filter by.
mrem-addr4:  Multiple IPv4 remote gateway address to filter by.
loc-addr6:   IPv6 local gateway address range to filter by.
mloc-addr6:  Multiple IPv6 local gateway address to filter by.
rem-addr6:   IPv6 remote gateway address range to filter by.
mrem-addr6:  Multiple IPv6 remote gateway addresses to filter by.

 

Use case 1:
FortiGate IPsec VPN wizard only supports IKEv1 when creating Dial-up tunnels. When IKE is changed from version '1' to '2', some settings are not configured. To authenticate successfully using IKEv2, the following commands must be set under tunnel phase1 settings: 

 

FortiGate-Fw # config vpn ipsec phase1-interface
FortiGate-Fw (phase1-interface) # edit REMOTE
FortiGate-Fw (REMOTE) # set eap enable
FortiGate-Fw (REMOTE) # set eap-identity send-request
FortiGate-Fw (REMOTE) # set authusrgrp <User Group name>
FortiGate-Fw (REMOTE) # end

 

As an alternative, EAP may be enabled, but the 'authusrgrp' setting left blank, and a group set in at least one firewall policy that uses the phase1-interface as source. This acts the same as the 'Inherit from policy' setting in IKEv1.

For more details on IPsec and Authentication, refer to Technical Tip: A guide to Dial-Up IPsec VPN Authentication.

 

Note:

  • The tunnel name in this example is 'REMOTE'. Make sure to use the respective name. 
  • The user group should only be set in either the phase1-interface configuration, or the policies, but not both, otherwise FortiGate may match the traffic to implicit deny or (attempt to) trigger a captive portal.
  • EAP should be disabled when IPsec VPN dial-up is configured to autoconnect using Microsoft Entra ID.
  • Using a dial-up IPsec tunnel with IKEv2, EAP (Extensible Authentication Protocol) must be enabled. EAP-Auth must be enabled under advanced VPN settings for IOS devices.  EAP authentication is supported when using RADIUS, SAML, or Local User authentication. Also, username case sensitivity can also lead to the EAP fail error.
    In the scenario of LDAP server/group scenarios, the configuration needs to be changed to IKEv1 to maintain compatibility.

     

Update:
Starting from v7.4.3, EAP-TTLS is now supported with IKEv2 authentication: EAP-TTLS support for IPsec VPN 7.4.3 | FortiClient 7.4.0.

In earlier versions of FortiClient, EAP-MSCHAPv2 was the method used for username + password authentication and did not work with LDAP. EAP-TTLS allows FortiGate to authenticate a connecting dial-up user to LDAP even when using IKEv2.

 

Related document:

Autoconnect to IPsec VPN using Entra ID logon session information

 

FortiGate-Fw # config vpn ipsec phase1-interface
FortiGate-Fw (phase1-interface) # edit IPSec_Auto_Connect

FortiGate-Fw (IPSec_Auto_Connect) # set eap disable

FortiGate-Fw (IPSec_Auto_Connect) # end

 

 

It also provides the debug commands to troubleshoot the issues with dial-up VPN and EAP together. 


Use case 2:
In a Dial-up IPsec VPN setup using SAML authentication, the following errors may appear if the Peer ID is configured in the IPsec Phase 1 settings on FortiGate but the Local ID is not set on FortiClient.

 

FortiGate-Fw # config vpn ipsec phase1-interface
FortiGate-Fw (phase1-interface) # edit REMOTE
FortiGate-Fw (REMOTE) # set peerid "fortinet"
FortiGate-Fw (REMOTE) # end

ike 0:IPsecVPN_saml:381: received FCT-UID = B041A92A44754A61BE5F6A8B2B64E2
ike 0:IPsecVPN_saml:381: received EMS SN : FCTEMS*******
ike 0:IPsecVPN_saml:381: received EMS tenant ID : 00000000000000000000000000000000
ike 0:IPsecVPN_saml:381: peer identifier IPV4_ADDR 192.168.1.222
ike 0:IPsecVPN_saml:381: re-validate gw ID
ike 0:IPsecVPN_saml:381: gw validation failed
ike 0:IPsecVPN_saml:381: schedule delete of IKE SA d8813abeaecd89/9f83068932fba0
ike 0:IPsecVPN_saml:381: scheduled delete of IKE SA d8813abeaecd89/9f83068932fba0
ike 0:IPsecVPN_saml: connection expiring due to phase1 down

To resolve this issue, configure the Local ID on FortiClient to match the Peer ID set on FortiGate in the IPsec Phase 1 configuration:


ike 0:IPsecVPN_saml:381: received FCT-UID = B041A92A44754A61BE5F6A8B2B64E2
ike 0:IPsecVPN_saml:381: received EMS SN : FCTEMS*******
ike 0:IPsecVPN_saml:381: received EMS tenant ID : 00000000000000000000000000000000
ike 0:IPsecVPN_saml:381: received peer identifier FQDN 'fortinet'
ike 0:IPsecVPN_saml:381: re-validate gw ID
ike 0:IPsecVPN_saml:381: gw validation OK

 

Note: IKEv2:

  • For IKEv2, FortiClient will use EAP-MSCHAPv2.
  • For this setup to work, the remote RADIUS server must support EAP-MSCHAPv2 authentication (EAP-MS-CHAP) (Microsoft NPS, for example).

 

Use case 3:

When the local gateway is defined and the interface has a dynamic IP address attributed (DHCP or PPPoE), it will be necessary to disable it due to the IP addresses change.

There is a reference on the note about this behavior

 

Note: 

IPv4 address is not supported for a Peer ID setup for IPsec VPN tunnels.

Refer to the following articles for more information: 

Troubleshooting Tip: The IPv4 address is not supported for Peer ID for IPsec vpn tunnels

Technical Tip: Local Gateway: IPSec VPN

Comments
GILMENDO
Staff & Editor
Staff & Editor

Great input thank you @vbarrios 

MaryBolano
Staff & Editor
Staff & Editor

Well done @vbarrios !!!

princes
Staff
Staff

Great article , really helps.