Technical Tip: FortiClient support for multiple IKEv2 dialup tunnels at the same FortiGate Remote Gateway address

[pjang]

Description	This article discusses FortiClient feature support for connecting to IKEv2 tunnels that are located at the same Remote Gateway address on the FortiGate, including background into why this can be an issue, why the feature is useful, and how this multiple tunnel support works.
Scope	FortiClient 7.2/7.4 and later, FortiGate, IKEv2, IPSec
Solution	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 7.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 7.4.4 and later (see also: FortiClient 7.4.4 Release Notes). For guidance on converting from existing SSL VPN configurations over to IKEv2, refer to the following documentation: Technical Tip: Recommended basic configuration for SSL VPN to IPsec VPN migration with SAML authent... FortiGate Admin Guide - SSL VPN tunnel mode to IPsec VPN migration During this transition to IKEv2, a problem can occur when multiple dialup VPN tunnels are configured to listen on the same interface/Remote Gateway address. Administrators might need multiple dialup 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 in a different way: 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: FortiGate Admin Guide - 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 m... 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: 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: Technical Tip: Certificate Authentication for FortiClient remote access dialup IPsec clients with S...). 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, otherwise the wrong VPN tunnel may be matched and the IKEv2 tunnel connection will fail. So far, network-id support has been added to FortiClient 7.2.6 (Windows/macOS), 7.2.7 (Linux), 7.4.1 (all platforms) and all later, and support for configuring network-id via EMS was added as of versions 7.2.6 and 7.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 network-id for IKEv2 tunnels configured directly on FortiClient (though it is possible to manually configure the option via the FortiClient XML configuration: FortiClient XML Reference - 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: FortiGate Admin Guide - 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).