This article describes the Dial-up IPSec connection between 1 FortiGate Hub and multiple FortiGate dial-in clients using IKEv2 and pre-shared key authentication when there are more than 1 Dial-up phase1 at the Hub and the correct tunnel must be selected.
The equivalent IKEv1 use case can be found here where it leverages the use of the peerid and helps the IPsec process decide which phase1 should be selected:
When using a FortiGate, with IKEv2, as a Dial-in client we can't select the peerid the same way as IKEv1.
The limitation on IKEv2 starts when the peerid is not added to the IKE initial packet or message, so the HUB can't properly match the correct phase1 among multiple Dial-up phase1 configurations. However, FortiOS has limited Dial-in client capabilities when IKEv2 and pre-shared keys are used.
Let's keep in mind that the dial-up server side does not have remote IP information, so there are no parameters to match the IKE initial request to the correct phase1 when multiple phase1 dialups are configured.
Fortinet implements a proprietary IKEv2 attribute called 'network-id' to cover this scenario.
Common other use cases of the network-id are associated with ADVPN deployments, however, this guide intends to cover the simple non-ADVPN scenario between 2 or more FortiGates.
FortiGate, FortiSASE.
Configure the IPSec tunnel with the desired parameters such as encryption, authentication, PSK, Certificates, etc.
More details about the multiple options of phase configurations:
Make sure IKEv2 is used. To intend to use IKEv1:
Technical Tip: How to use Peer IDs to select an IPSec dialup tunnel on a FortiGate configured with m...
After choosing the phase1 options, enable the network overlay and define one network ID as shown below.
As of FortiOS version 7.4.2, the network-id must be configured from the CLI and isn't available to be set from the GUI.
config vpn ipsec phase1-interface
edit <example>
set ike-version 2
set network-overlay enable
set network-id <integer>
next
end
Make sure to enable and define the network-id on both sides of the tunnel.
Without the network-id attribute, the Dial-in clients will always attempt to be matched against the 1st Phase1 configuration that uses IKEv2 on the Hub.
This may be a problem when there are multiple Dial-up phase1 and specific dial-in clients must specify another tunnel down in the list.
With the network-id attribute defined, the IKE_SA_INIT can be correctly matched with the correct Phase1 even when the Hub contains multiple Dial-up Phase1 configurations.
In the example below, ipsec_001 was skipped as the network id = 10 was received, so it matched ipsec_004 successfully.
As a result, the IKEv2 Dial-up can go UP successfully even when there are multiple Dial-up tunnels on the HUB:
Note:
It is still possible to set the peerid on each dial-in client to have better control and visibility on the hub side.
Additional info:
Refer to the RFC 5996 - section 1.2 as it describes the attributes included in the IKE_SA_INIT message.
Notice that identification attributes (IDr) are only exchanged on the 2nd loop of packets.
https://datatracker.ietf.org/doc/html/rfc5996#section-1.2
If the Authentication method of phase1 is changed to Signature ( certificate ) the above statements still apply as matching criteria of correct phase1 parameters during the IKE_SA_INIT phase. peerid ( identification ) would now be used to match certificate parameters during the AUTH_REQUEST phase ( 2nd loop ) and the incorrect manipulation of such attributes may lead to errors like the one below.
For more information about ikev2 and certificate authentication:
Site-to-site VPN with digital certificate
Related documents:
Technical Tip: FortiGate IPSec VPN Resource List.
Admin Guide: Phase 1 configuration.
ADVPN: How to configure multiple VPN tunnels from the same ISP to the same remote peer ISP.
No Dial-UP: How to configure multiple VPN tunnels from the same ISP to the same remote peer ISP.
Well written article lcamilo, nice work mate.
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.