Need to establish IPSEC tunnel to Fortiagte firewall with Dual ISP with single Azure VPN gateway

Question

Need to establish IPSEC tunnel to Fortiagte firewall with Dual ISP with single Azure VPN gateway, but in fortiage not able to have same peer IP for both the ISP links

Answer 1

Hello Harish Shivanna,

Greetings! Thanks for raising this question in the Q&A forum.

The behavior you're seeing is a FortiGate limitation, not an Azure one. By default, FortiGate will not let you create two separate IPsec phase1-interfaces (tunnels) that point to the same remote gateway (peer) IP, even when each tunnel is bound to a different WAN interface. You'll typically see this surface as a "Duplicate remote gateway ip" error in the GUI or CLI. Since your two ISP links both need to reach the same single Azure VPN Gateway public IP, you're hitting this restriction directly.

You have two ways to resolve this, depending on whether you want to keep a single Azure peer IP or not.

Option 1: Keep the single Azure VPN Gateway peer IP and fix it on the FortiGate side

FortiGate supports coexisting tunnels to the same peer IP using a proprietary IKEv2 attribute called network-id. This lets you run both ISP tunnels to the same Azure gateway IP without the duplicate-gateway conflict.

1. Build each phase1-interface with IKEv2 and a unique network-id, bound to its own WAN interface

config vpn ipsec phase1-interface
    edit "Azure-WAN1"
        set type static
        set interface "wan1"
        set ike-version 2
        set network-overlay enable
        set network-id 10
        set remote-gw <Azure_VPN_Gateway_Public_IP>
        set psksecret <shared-key>
    next
    edit "Azure-WAN2"
        set type static
        set interface "wan2"
        set ike-version 2
        set network-overlay enable
        set network-id 20
        set remote-gw <Azure_VPN_Gateway_Public_IP>
        set psksecret <shared-key>
    next
end

Create matching phase2-interfaces, static routes, and firewall policies for each tunnel as you normally would, one set per phase1.

Configure Azure with one Local Network Gateway per FortiGate WAN IP (Gateway IP Address = your wan1 public IP for one, wan2 public IP for the other), then create two Connection resources from your VPN Gateway to those two Local Network Gateways. Both terminate on the same Azure Gateway public IP, which is fine on the Azure side.

Note this only works with IKEv1 site-to-site is not supported for this trick; you must use IKEv2.

Option 2 (recommended): Switch the Azure VPN Gateway to Active-Active mode

This is the topology Microsoft and Fortinet both recommend for dual-ISP-to-single-gateway scenarios, because it sidesteps the FortiGate duplicate-peer restriction entirely by giving you two distinct Azure peer IPs, one per ISP link.

Confirm your Gateway SKU supports Active-Active. Basic SKU does not; you need VpnGw1 or higher.

Enable Active-Active mode on the existing gateway. This provisions a second Standard SKU static public IP for the second gateway instance.

az network vnet-gateway update \
  --name <YourVpnGatewayName> \
  --resource-group <YourResourceGroup> \
  --set enableActiveActiveFeature=true

1. Create two Local Network Gateways, one for each FortiGate WAN/ISP public IP:

az network local-gateway create \
  --name OnPremWAN1 \
  --resource-group <YourResourceGroup> \
  --gateway-ip-address <FortiGate_WAN1_Public_IP> \
  --local-address-prefixes <OnPrem_CIDR>

az network local-gateway create \
  --name OnPremWAN2 \
  --resource-group <YourResourceGroup> \
  --gateway-ip-address <FortiGate_WAN2_Public_IP> \
  --local-address-prefixes <OnPrem_CIDR>

Create two Connections, each linking the VPN Gateway to one Local Network Gateway.

On the FortiGate, create one phase1-interface per WAN link, each pointing to its own Azure gateway public IP:

config vpn ipsec phase1-interface
    edit "Azure-WAN1"
        set interface "wan1"
        set remote-gw <Azure_Public_IP_Instance0>
    next
    edit "Azure-WAN2"
        set interface "wan2"
        set remote-gw <Azure_Public_IP_Instance1>
    next
end

Since the two remote gateway IPs are now different, the duplicate-gateway restriction never applies, and you get true high availability on both the Azure side and the on-prem ISP side. BGP is recommended (though not strictly required if you're not combining it with on-prem active-active redundancy) so that route withdrawal and failover happen automatically when either tunnel drops.

If this answer helps you kindly accept the answer which will help others who have similar questions.

Best Regards,

Jerald Felix.