Technical Tip: How to setup IPSec tunnel in an Active/Active HA Cluster for FortiGate-VM in Azure

[mrashidi]

Description	This article describes how to set up an IPSec tunnel in an Active/Active HA Cluster for FortiGate-VM in Azure to prevent tunnel flapping and asymmetric routing
Scope	FortiGate-VM Active, Active HA Cluster in Azure.
Solution	While an Active/Passive HA cluster is generally recommended for IPSec tunnels, users may require establishing an IPSec tunnel in an existing Active/Active HA cluster. The following assumes an Active/Active HA cluster for FortiGate-VM is implemented based on the provided template: FortiGate Active-Active ELB-ILB - GitHub Set up an IPSec tunnel between the FortiGate HA cluster in Azure and another [FortiGate] firewall. Microsoft Azure: The external Azure Load Balancer requires 2 load balancing rules to pass IPSec traffic to the FortiGate HA cluster. The rules need to be configured to pass ports UDP/500 and UDP/4500. The Floating IP options should not be enabled in the IPSec VPN LB rules (UDP 500 and UDP 4500). When Floating IP is enabled, Azure Load Balancer doesn't DNAT the packets to the private IP configured on the FortiGate. The FortiGate VM in Azure does not have the public IPs configured and as such local processes like IPSec do not listen to this public IP address. FortiGate: Two firewall policies referencing the VPN are required for the IPSec tunnel to be created for end-to-end connection from both sides. Microsoft Azure requires NAT between the public IP and the FortiGate VM with or without the Azure Load Balancer. To establish an IPSec tunnel across NAT, the NAT Traversal option needs to be set to Enable or Forced on both the FortiGate in Azure and on the remote peer. For details on IPSec VPN setup and troubleshooting of a FortiGate Active/Passive HA cluster, refer to: IPSec VPN connectivity for FortiGate in Azure - GitHub FortiGate HA cluster ELB-ILB inbound-ipsec-configuration - GitHub When using an Active/Active HA cluster with an IPSec tunnel, the end-to-end connection from an on-premises host to a protected VM in Azure may encounter the following issues: Tunnel flapping: The tunnel may switch between the primary and secondary FortiGates since both are active. Asymmetric routing: If the tunnel terminates on one FortiGate (e.g., FGT-A), forwarding traffic passes through that FortiGate, but returning traffic from the internal load balancer might be sent to the other FortiGate (e.g., FGT-B), leading to asymmetric routing. To address these issues: Resolving tunnel flapping: Configure the following on the IPSec phase1-interface for both FGT-A and FGT-B: config vpn ipsec phase1-interface      edit "to_On-prem"       set fgsp-sync enable    next end If the FGSP session sync is not enabled on the FortiGate, enable the passive-mode too on the IPSec phase1-interface. Enabling passive mode ensures that the Azure FortiGate acts as a responder and does not initiate the IPSec tunnel. The on-premises device determines to which FortiGate (FGT-A or FGT-B) to send the IPSec traffic. If the responding FortiGate fails, the traffic automatically shifts to the other, re-establishing the tunnel. config vpn ipsec phase1-interface      edit "to_On-prem"       set passive-mode enable    next end For detailed configuration, refer to: Configuring FGSP with an IPSec tunnel - Fortinet Community Resolving asymmetric routing: Set session persistence to Client IP on the internal load balancing rule. This configuration ensures that traffic originating from a specific client IP always returns through the same FortiGate, maintaining symmetry in routing. Related documents: FortiGate Active-Active ELB-ILB - GitHub FGSP session sync IPSec VPN connectivity for FortiGate in Azure - GitHub FortiGate HA cluster ELB-ILB inbound-ipsec-configuration - GitHub Configuring FGSP with an IPSec tunnel - Fortinet Community IPSec Tunnel in FortiGate Active-Passive HA cluster with LB sandwich