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:
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.
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:
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.
- 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.
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 articles:
- 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.
- Troubleshooting Tip: Troubleshooting IPsec Site-to-Site Tunnel Connectivity
- Technical Tip: How to configure VPN Site to Site between FortiGates (Using VPN Setup Wizard)
- Troubleshooting Tip: IPsec VPNs tunnels
- Technical Tip: Setting multiple DNS server for IPSec dial-up VPN
- Technical Tip: NAT-traversal comparison between site-to-site and dial-up” dynamic” tunnels
- Technical Tip : How to configure multiple VPN tunnels from the same ISP to the same remote peer ISP.
- Technical Tip: IPSec dial-up full tunnel with FortiClient
- Technical Tip: Differences between Aggressive and Main mode in IPSec VPN configurations
- Technical Note: Dynamic routing (BGP) over IPsec tunnel
- Technical Tip: OSPF with IPSec VPN for network redundancy
- Technical Tip: Dynamic dial-up VPN with OSPF
- Technical Tip: Fortinet Auto Discovery VPN (ADVPN)
- Technical Tip: 'set net-device' new route-based IPsec logic
- Technical Tip: Simple OCVPN deployment
- Technical Tip: SD-WAN integration with OCVPN
- Technical Tip: Configure IPsec VPN with SD-WAN
- Technical Tip: SD-WAN with DDNS type IPsec
- Technical Tip: SD-WAN primary and backup ipsec tunnel Scenario
- Troubleshooting Tip: IPsec VPN Phase 1 Process - Aggressive Mode
- Technical Note : Configuring more than one Main-Mode Pre-Shared Key (PSK) *dialup* IPSec phase1 on a...
- Technical Tip: How to configure IPsec VPN Tunnel using IKE v2
- Technical Tip: Hard timeout for Dialup IPSEC VPN Tunnel
