SDWAN Tunnel on Azure FortiGate active - standby using load balancer

Dear @sidhrane

When on‑prem initiates the SD‑WAN/IPsec tunnels to Azure, you should point the remote gateway on the on‑prem FortiGate to the load balancer frontend IPs, not the FortiGate VM NIC IPs:

Internet tunnel: remote gateway = ELB public frontend IP

ExpressRoute (private) tunnel: remote gateway = ILB private frontend IP

This way, traffic always hits the active FortiGate via the load balancer, and failover is handled by Azure LB without changing on‑prem config.

When the Azure FortiGate initiates the tunnels to on‑prem, the source IP seen by on‑prem will be the FortiGate interface IP bound to that tunnel. The ILB/ELB frontend IPs are only used for inbound connections to the active FortiGate; they are not used as the tunnel source when the FortiGate itself initiates.

So:

• On‑prem to Azure: use LB frontend IPs as remote gateway.
• Azure to on‑prem: FortiGate uses its own interface IP; on‑prem peers to that IP.When on‑prem initiates the SD‑WAN/IPsec tunnels to Azure, you should point the remote gateway on the on‑prem FortiGate to the load balancer frontend IPs, not the FortiGate VM NIC IPs:
  • Internet tunnel: remote gateway = ELB public frontend IP
  • ExpressRoute (private) tunnel: remote gateway = ILB private frontend IP

This way, traffic always hits the active FortiGate via the load balancer, and failover is handled by Azure LB without changing on‑prem config.

When the Azure FortiGate initiates the tunnels to on‑prem, the source IP seen by on‑prem will be the FortiGate interface IP bound to that tunnel. The ILB/ELB frontend IPs are only used for inbound connections to the active FortiGate; they are not used as the tunnel source when the FortiGate itself initiates.

So:

• On‑prem to Azure: use LB frontend IPs as remote gateway.
• Azure to on‑prem: FortiGate uses its own interface IP; on‑prem peers to that IP.

For diagrams and step‑by‑step, see:

Fortinet community: https://community.fortinet.com/t5/FortiGate-Azure-Technical/SD-WAN-Connecting-Azure-ExpressRoute-and-VPN-tunnel-from-the/ba-p/370030

Fortinet Azure templates (Active/Passive ELB+ILB): https://github.com/fortinet/azure-templates/blob/main/FortiGate/Active-Passive-ELB-ILB/README.md

Azure SD‑WAN architecture guide: https://learn.microsoft.com/azure/architecture/networking/guide/sd-wan-integration-hub-spoke-network-topologies

Help make this community better for everyone: if this answer resolved your issue, please accept it or leave an upvote. If not, share more details in a comment so we can continue the discussion and find the right solution.

Welcome to Microsoft Q&A!

Hello @sidhrane I hope you are doing well,

Here is a direct breakdown of how IP termination works for Active/Passive FortiGates behind Azure Load Balancers:

• On-Premises Initiating Tunnels (Inbound): Point the on-prem remote gateway directly to the Azure Load Balancer Frontend IPs (ELB Public IP for Internet, ILB Private IP for ExpressRoute). The LB probes ensure traffic only routes to the active FortiGate, providing automatic failover.
• Azure FortiGate Initiating Tunnels (Outbound): Traffic will source from the FortiGate’s physical NIC IP, not the LB Frontend IP, because Azure Load Balancers only forward inbound connections.

Recommended Best Practice:

To prevent routing asymmetry and peering conflicts during failovers, configure the Azure FortiGates as responders by enabling set passive-mode enable under the IPsec Phase 1 interface. Additionally, enable Floating IP (Direct Server Return) on your Azure Load Balancer load-balancing rules for UDP 500/4500 and HA ports.

References:

• Fortinet Azure Templates: Active-Passive ELB/ILB Deployment Guide
• Azure Architecture: Integrate SD-WAN with Azure Hub-and-Spoke

Help make this community better for everyone: if this answer resolved your issue, please accept it or leave an upvote. If not, share more details in a comment so we can continue the discussion and find the right solution.