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.
hbac
Staff
Staff
Article Id 224888
Description

This article describes how to solve the 'AUTHENTICATION_FAILED' error while IPsec tunnel negotiation between FortiGate and Cisco.

 

In this example:

  • 10.1.1.1 is an IP on FortiGate.
  • 10.2.2.2 is an IP on Cisco ASA.

 

Site-to-Site IPsec VPN between FortiGate on AWS and Cisco using IKEv2 is not coming up. Debug on the FortiGate is showing 'AUTHENTICATION_FAILED'.

 

Below is the debug output on the FortiGate:  

 

2022-09-16 14:08:04.722079 ike 0:B1:49836: sent IKE msg (AUTH): 10.1.1.1:500->10.2.2.2:500, len=240, vrf=0, id=93cf8ded66f1bb7c/e34f9641e22c3ce3:00000001
2022-09-16 14:08:04.747045 ike 0: comes 10.2.2.2:500->10.1.1.1:500,ifindex=3,vrf=0....
2022-09-16 14:08:04.747059 ike 0: IKEv2 exchange=AUTH_RESPONSE

id=93cf8ded66f1bb7c/e34f9641e22c3ce3:00000001 len=80
2022-09-16 14:08:04.747072 ike 0: in 93CF8DED66F1BB7CE34F9641E22C3CE32E20232000000001000000502900003436FE4BDB3A3D8A55A6F939B558473

FA166E5F335244FA4A3B5F076AD120E2A3C5A16F324AA27C6A6A7BF52D604777FE2
2022-09-16 14:08:04.747083 ike 0:B1:49836: dec 93CF8DED66F1BB7CE34F9641E22C3CE32E2023200000000100000028290000040000000800000018
2022-09-16 14:08:04.747095 ike 0:B1:49836: initiator received AUTH msg
2022-09-16 14:08:04.747101 ike 0:B1:49836: received notify type AUTHENTICATION_FAILED

 

Debug on the Cisco, the peer’s identity type can be seen as FQDN. Below is the debug output on the Cisco firewall:

 

Sep 16 00:19:48.293 UTC: IKEv2:(SESSION ID = 54588636,SA ID = 50):Received Packet [From 10.1.1.1:500/To 10.2.2.2:500/VRF i0:f5]
Initiator SPI : B00BFE07C3FF2CE0 - Responder SPI : A021B9EFEC57B189 Message id: 1
IKEv2 IKE_AUTH Exchange REQUEST
Payload contents:
IDi NOTIFY(INITIAL_CONTACT) AUTH NOTIFY(Unknown - 16420) SA TSi TSr

Sep 16 00:19:48.294 UTC: IKEv2:(SESSION ID = 54588636,SA ID = 50):Stopping timer to wait for auth message
Sep 16 00:19:48.294 UTC: IKEv2:(SESSION ID = 54588636,SA ID = 50):Checking NAT discovery
Sep 16 00:19:48.294 UTC: IKEv2:(SESSION ID = 54588636,SA ID = 50):NAT not found
Sep 16 00:19:48.294 UTC: IKEv2:(SESSION ID = 54588636,SA ID = 50):Searching policy based on peer's identity ’10.1.1.1’ of type 'FQDN'
Sep 16 00:19:48.296 UTC: IKEv2-ERROR:(SESSION ID = 54588636,SA ID = 50):: Failed to locate an item in the database
Sep 16 00:19:48.296 UTC: IKEv2:(SESSION ID = 54588636,SA ID = 50):Verification of peer's authentication data FAILED
Sep 16 00:19:48.296 UTC: IKEv2:(SESSION ID = 54588636,SA ID = 50):Sending authentication failure notify
Sep 16 00:19:48.296 UTC: IKEv2:(SESSION ID = 54588636,SA ID = 50):Building packet for encryption.

 

This issue could occur when the local-id-type is set to auto.

Scope IPSec tunnel on FortiGate.
Solution

To resolve this issue, when configuring IPsec tunnels with vendor devices, set the local-id-type to address or whatever the remote peer is expecting from FortiGate:

 

config vpn ipsec phase1-interface
    edit 1
        set localid-type address
        set localid 10.1.1.1
end

 

The default behavior of the FortiGate concerning local ID and local ID type (as of FortiOS 7.4.5/7.6.0) is as follows:

  1. Local ID and Local ID type are not explicitly configured: The FortiGate sends the IP address of the interface the IPsec tunnel is bound to, and the type as IP address (ID_IPV4_ADDR). An exception is when a virtual FortiGate is used in a cloud platform and it is able to fetch the EIP (external IP address) - then the virtual FortiGate sends the IP address as the EIP and type as FQDN.
  2. Local ID as configured as an IP address and local ID type is not explicitly configured: The FortiGate will send the configured IP address as the local ID, with the ID type as FQDN. This works fine when both ends are FortiGates.

Hence whenever configuring an IP address as the local ID, make sure to configure the local ID type as an address as needed (important when configuring IPsec tunnels with vendor devices).

 

Note:

This applies to the other 3rd party vendors, as well as UniFi and WatchGuard, when using an IKEv2 IPsec tunnel with FortiGate.