When IPsec dial-up is configured with IKEv2, the following errors may be displayed in the following debug outputs when attempting to connect to the VPN.
diagnose vpn ike log-filter src-addr4 x.x.x.xÂ
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.
To disable the debug processes:
diagnose debug reset
diagnose debug disable
 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 is left blank, and a group is 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 and Policy Matching.
 There is a known issue ID 1132631 on FortiClient version 7.4.3 GA (which is the most used as a free version) causing failure after successful SAML-based user authentication. During peer authentication, while the FortiGate expects the EAP authentication method, FortiClient ignores it. The issue is fixed in the latest FortiClient versions. The workaround below should be followed consequently: Disable 'Enable Single Sign On (SSO) for VPN Tunnel'. Authentication (EAP) shows up. Change the setting to 'Prompt on login' if it is not selected automatically:
 Â Enable 'Enable Single Sign On (SSO) for VPN Tunnel'.
   Select Save.
 Notes: The tunnel name in this example is 'REMOTE'. Make sure to substitute it with the appropriate 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 a Microsoft Entra ID. When 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. Additionally, username case sensitivity may lead to an EAP failure error. In LDAP server/group scenarios, the configuration needs to be changed to IKEv1 to maintain compatibility with LDAP-based user authentication.
Â
Update:
Starting from v7.4.3, EAP-TTLS is now supported with IKEv2 authentication: EAP-TTLS support for IPsec VPNÂ (v7.4.3).
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. Â 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
The error 'EAP response is empty' can also be seen in the debug log output. To resolve this error, see Troubleshooting Tip: Using IKEv2 for a dial-up IPsec tunnel with a RADIUS server and Local user. The error 'EAP response is empty' and 'connection expiring due to EAP failure' also usually appears in the debug logs when changing from IKEv1 to IKEv2, because IKEv2 only allows configuring the authentication group via CLI and/or directly in the Firewall Policy, which does not happen with IKEv1, because IKEv1 allows enabling the XAUTH option and in turn selecting between 'Inherited from Policy' or 'choosing' the object that has been associated with the users who will authenticate through the tunnel. This error will appear when the user group is not associated through the CLI or in the Firewall Policy.
 It also provides the debug commands to troubleshoot 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: The error may also occur when the local ID is set on the FortiClient end, and FortiGate is configured to default (Peer ID type is 'Any').     ike 0:IPsecVPN_saml:saml_contractor:2037: received EMS tenant ID :
ike 0:IPsecVPN_saml:saml_contractor:2037: received peer identifier FQDN 'fortinet'
ike 0:IPsecVPN_saml:saml_contractor:2037: re-validate gw ID
ike 0:IPsecVPN_saml:saml_contractor:2037: gw validation failed
 FortiGate-Fw # config vpn ipsec phase1-interface
FortiGate-Fw (phase1-interface) # edit REMOTE
FortiGate-Fw (REMOTE) # set peerid any ----> Default value.
FortiGate-Fw (REMOTE) # end
 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).
 Note: If FortiClient is connected to EMS and there have been prior connection attempts using IKEv1 with XAuth, or if a migration from IKEv1 to IKEv2 has been performed, or if FortiClient v7.4.5 is in use (which does not support IKEv1 - see IPsec VPN), ensure that XAuth is disabled in the FortiClient XML configuration.  Failure to do so may result in the 'gw validation failed' error when trying to connect via IKEv2.  <xauth>
<use_otp>0</use_otp>
<enabled>0</enabled> <----- Value should be 0 (disabled) and not 1 (enabled).
<prompt_username>1</prompt_username>
</xauth>
 Use case 3: When the local gateway is defined and the interface has a dynamic IP address assigned (DHCP or PPPoE), it will be necessary to disable it due to the IP address change. There is a reference in the note about this behavior.  Note: IPv4 address is not supported for a Peer ID setup for IPsec VPN tunnels.  Use case 4: Receiving a 'gw validation failed' error when using IPsec IKEv2 dial-up VPN for Android users.
ike V=VPN:4:3rdpart_IPSEC:876: responder received AUTH msg
ike V=VPN:4:3rdpart_IPSEC:876: received peer identifier KEY_ID ''
ike V=VPN:4:3rdpart_IPSEC:876: re-validate gw ID
ike V=VPN:4:3rdpart_IPSEC:876: gw validation failedÂ
 In this case, authentication is configured using a pre-shared key combined with Username and Password, which is not compatible with FortiClient on Android when using IKEv2 with EAP. The error does not occur when using FortiClient Android and IPsec IKEv1.  FortiClient (Android) supports IPsec VPN using either a pre-shared key or X.509 certificate-based authentication, but does not support combining PSK with EAP (Username/Password).  Refer to the following document for more information: Technical Tip: Getting 'gw validation failed' when using IPsec IKEv2 dial-up VPN for android users.
Use case 5:
macOS users cannot connect to the dial-up IPsec VPN tunnel. The error that appears on the FortiClient is 'Connection timeout'. Based on the IKE debug, it says 'gw validation failed'.
ike 0:dialup:77: peer identifier IPV4_ADDR x.x.x.x
ike 0:dialup:77: re-validate gw ID
ike 0:dialup:77: gw validation failed
To resolve the issue, change the phase1 and phase2 encryption from DES-SHA256 to AES256-SHA256.
config vpn ipsec phase1-interface
edit dialup
set proposal aes256-sha256
next
end
config vpn ipsec phase2-interface
edit dialup
set proposal aes256-sha256
next
end
Related documents:
| 
