Staff

Technical Tip: FortiGate Hub with multiple IPSec Dial-up phase1 using IKEv2 and PSK authentication

Forum|Forum|2 years ago
December 11, 2023
1 reply
31875 views

Description

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:

Technical Tip: How to use Peer IDs to select an IPSec dialup tunnel on a FortiGate configured with multiple dialup tunnels

When using a FortiGate, with IKEv2, as a Dial-in client, it is not possible to 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.

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 dial-ups 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.

Scope

FortiGate, FortiSASE.

Solution

Configure the IPSec tunnel with the desired parameters, such as encryption, authentication, PSK, Certificates, etc.
More details about the multiple options of phase configurations:

FortiGate-to-FortiGate

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 multiple dialup tunnels

After choosing the phase1 options, enable the network overlay and define one network ID as shown below. Note that enabling network-overlay to use network-id will NOT affect existing site-to-site tunnels, provided it is only enabled on the specific dial-up Phase1 entries. It does not change global IPsec behavior or ADVPN operation for other tunnels.

The network-id is an integer value from the range of 0 to 255.
The network-id must be equal on both ends of the VPN.

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.

FortiClient network-id can be configured via EMS or using XML configuration, as explained in this article: Technical Tip: FortiClient support for multiple IKEv2 dialup tunnels at the same FortiGate Remote Gateway address.

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.

RFC5996

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

certificate errors.png