Technical Tip: 'gw validation failed' for VPN Ikev2 tunnel with Strongswan using certificates, VPN tunnel not coming up

Description

This article describes that while connecting via IKEv2 with Strongswan using certificates, the tunnel does not come up.

Scope

FortiOS version lower than 7.4.8.

Solution

FortiGate VPN config:

config user peer
    edit "tst1-vpn"
        set ca "CA_Cert_1"
    next
end

config user peergrp
    edit "vpn_group"
        set member "tst1-vpn"
    next
end

config vpn ipsec phase1-interface
    edit "fgt_vpn"
        set type dynamic
        set interface "wan1"
        set ike-version 2
        set local-gw 10.20.3.15
        set keylife 28800
        set authmethod signature
        set peertype peergrp
        set proposal aes128-sha256 aes256-sha256
        set localid "fortigate.intern"
        set localid-type asn1dn
        set dpd on-idle
        set dhgrp 14
        set eap enable
        set eap-identity send-request
        set certificate "fgt-tst"
        set peergrp "vpn_group"
        set net-device enable
        set dpd-retryinterval 60
    next

config vpn ipsec phase2-interface
    edit "fgt_vpn_p2"
        set phase1name "fgt_vpn"
        set proposal aes256-sha256
        set dhgrp 14
        set keepalive enable
        set keylifeseconds 28800
        set src-subnet 10.20.40.0 255.255.255.0
    next
end

Strongswan Config:

#/etc/ipsec.conf - strongSwan IPsec configuration file
config setup
uniqueids = yes

# VPN 1
conn fgt_vpn
auto = add
keyexchange = ikev2
mobike = no
type = tunnel
forceencaps = no

left = %%any
right = 192.168.1.155
leftsubnet = 10.20.42.11/32
rightsubnet = 10.20.40.0/24
leftsendcert = always
leftauth = pubkey
rightauth = pubkey
leftcert = tst1-vpn.crt
leftid = tst1-vpn
ike = aes256-sha256-modp2048!
ikelifetime = 28800
esp = aes256-sha256-modp2048!
lifetime = 28800
rekeymargin = 3m
keyingtries = %%forever
fragmentation = yes
reauth = yes
rekey = yes
installpolicy = yes
dpdaction = restart
dpddelay = 10s

Running the debug, it could be seen that the GW validation is failing.

ike 2:e4ee3025ce9caf06/0000000000000000:1882500: SA proposal chosen, matched gateway fgt_vpn
ike 2:fgt_vpn:1882500: processing notify type INITIAL_CONTACT
ike 2:fgt_vpn:1882500: processing notify type EAP_ONLY_AUTHENTICATION
ike 2:fgt_vpn:1882500: processing notify type MESSAGE_ID_SYNC_SUPPORTED
ike 2:fgt_vpn:1882500: received peer identifier DER_ASN1_DN 'CN = tst1-vpn'
ike 2:fgt_vpn:1882500: re-validate gw ID
ike 2:fgt_vpn:1882500: gw validation failed
ike 2:fgt_vpn:1882500: schedule delete of IKE SA
ike 2:fgt_vpn:1882500: scheduled delete of IKE SA
ike 2:fgt_vpn: connection expiring due to phase1 down
ike 2:fgt_vpn: deleting
ike 2:fgt_vpn: deleted

In the config, it could be seen that EAP is enabled on FortiGate without any authentication group.

With EAP enabled, local authentication for Peer is not possible via PSK or Cert.

For dial-up tunnels, there are two scenarios:

• If the initial gateway lookup (based on SA_INIT_req) matches a phase1 with EAP enabled.

1. FortiOS expects the Peer to authenticate with EAP; otherwise, the negotiation fails.
2. The ID of the initiator is ignored: any ID is accepted, acting as if the phase1 is configured with ’set peertype any’.

• If the initial gateway lookup (based on SA_INIT_req) matches a phase1 without EAP.

1. FortiOS expects the Peer to authenticate with PSK/CERT authentication; otherwise, the negotiation fails.
2. The ID is used to perform gateway revalidation, but only among non-EAP phase1.
   
   

Solution.

Since the second scenario is required here, where Peer needs to authenticate via certificates, EAP should be disabled under phase1.

config vpn ipsec phase1-interface
    edit "fgt_vpn"
        set eap disable
    next
end

Debugs:

ike 2:fgt_vpn:2189544: received peer identifier DER_ASN1_DN 'CN = tst1-vpn’
ike 2:fgt_vpn:2189544: re-validate gw ID
ike 2:fgt_vpn:2189544: gw validation OK

Note: From FortiOS v7.4.8, FortiGate starts supporting IPsec IKEv2 VPN 2FA with EAP and certificate authentication by introducing the option of 'eap-cert-auth' under phase 1 settings. In that case, this workaround to disable the EAP in phase 1 is no longer required after having the 'eap-cert-auth' option enabled. The following document can be followed:

IPsec IKEv2 VPN 2FA with EAP and certificate authentication