Technical Tip: FortiClient support for multiple IKEv2 dialup tunnels at the same FortiGate remote gateway address

At the time of this writing (October 2025), FortiClient supports or has supported SSL VPN, IKEv1, and IKEv2 for remote access VPN connectivity to the FortiGate. The first two options, in particular, were more commonly utilized in the past, but recent changes show that IKEv2 will become the recommended/more-preferred option going forward:

• SSL VPN tunnel-mode has been deprecated on all FortiGates as of FortiOS v7.6.3 and later (though web-mode remains and has been renamed to Agentless VPN). Additionally, FortiSASE environments are now only utilizing IKEv2 for the Secure Internet Access (SIA) VPN tunnel between FortiClient and FortiSASE (existing SSL VPN-based environments are being migrated to IKEv2 over time).
• IKEv1 has been deprecated in FortiClient v7.4.4 and later (see also: FortiClient 7.4.4 Release Notes).

For guidance on converting from existing SSL VPN configurations to IKEv2, refer to the following documentation:

• Technical Tip: Recommended basic configuration for SSL VPN to IPsec VPN migration with SAML authentication
• SSL VPN tunnel mode to IPsec VPN migration

During this transition to IKEv2, a problem can occur when multiple dial-up VPN tunnels are configured to listen on the same interface/Remote Gateway address. Administrators might need multiple dial-up tunnels to separate different user groups (such as contractors vs. employees), and users must be able to consistently match the associated VPN tunnel. Each VPN method solves this problem differently:

• SSL VPN solves this problem with the Realms feature, which allows clients to access segregated SSL VPN zones by connecting to a separate URL path or FQDN (see also this document: VPN multi-realm).
  This can be useful for cases where authentication methods should be separated for different user groups, such as when using multiple SAML IdPs. Refer to the following KB article for an example of this: Technical Tip: SSL VPN with SAML authentication with multiple IdP's.
• IKEv1 (specifically Aggressive mode) solves this problem with the peer-id function, where the client specifies a Local ID that the FortiGate then uses to match that client with a specific tunnel. See also: Technical Tip: How to use Peer IDs to select an IPsec dialup tunnel on a FortiGate configured with multiple dialup tunnels.
• For IKEv2, this problem is solved using one of two methods:
  • Option 1 is using a Fortinet-proprietary option called network-id. This is similar to IKEv1 Aggressive mode's peer-id value, and the FortiGate can use this value to match a client to a tunnel with the same network-id. For a FortiGate to FortiGate example of this, see this article: Technical Tip: FortiGate Hub with multiple IPSec Dial-up phase1 using IKEv2 and PSK authentication.
  • Option 2 is using certificate-based authentication, where the FortiGate can match a client to a tunnel based on the contents of the client-provided certificate (see also this article: Technical Tip: Certificate Authentication for FortiClient remote access dialup IPsec clients with SAML user authentication).

On FortiClient, then, VPN tunnels not using certificate-based authentication must instead specify a network-id value when there are multiple possible IKEv2 dialup tunnels on the FortiGate; the wrong VPN tunnel may be matched, and the IKEv2 tunnel connection will fail.

So far, network-id support has been added to FortiClient v7.2.6 (Windows/macOS), v7.2.7 (Linux), v7.4.1 (all platforms), and above, and support for configuring network-id via EMS was added as of versions v7.2.6 and v7.4.1 (configurable under Endpoint Profiles -> Remote Access and modifying the Phase1 settings for VPN Tunnels:(

However, take note that GUI support in FortiClient itself is not yet available at this time, so it is not yet possible to set the network ID for IKEv2 tunnels configured directly on FortiClient. Instead, the FortiClient XML configuration file can be manually edited with the Network ID attribute. 

From the XML configuration file, locate the <ike_settings> section of the XML, and insert the <networkid> tag as below:

<ike_settings>

<networkid>2</networkid> <----- Add the entry here.

<version>2</version>

Note: This value is not consistently included in the configuration. In that case, manually add the <network-id> section as shown above.

In this example, '2' represents the Network ID and must match the corresponding Phase 1 configuration on the FortiGate.
Ensure that the <networkid> tag is placed within the correct tunnel definition block in the XML file.

For full guidance with the XML configuration: 

IKE Settings

Side Note: IPsec with SAML-based authentication on the FortiGate currently relies on setting a specific ike-saml-server directly on the FortiGate network interface (see also: SAML for dialup IPsec). This means that it is currently not possible to have multiple SAML IdPs supported across multiple IKEv2 tunnels when those tunnels listen on the same network interface (i.e., a single WAN interface).