Technical Tip: How to set up an IPsec tunnel in an Active/Active HA Cluster for FortiGate-VM in Azure

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, and the traffic flow is from on-premises to the Cloud environment.

FortiGate Active-Active ELB-ILB - GitHub

Set up an IPsec tunnel between the FortiGate HA cluster in Azure and another [FortiGate] firewall.

• 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.

• 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

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:

1. Tunnel flapping: The tunnel may switch between the primary and secondary FortiGates since both are active.
2. 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:

1. 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.

2. Resolving asymmetric routing: Set session persistence to Client IP (or Source 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.

Important notes:

Note 1: Although the HA cluster is Active/Active, the IPsec tunnel with the FGSP configuration will operate in an Active/Passive manner, since the tunnel is established with only one FortiGate at a given time.

Note 2: If the traffic originates from the cloud environment to the on-premises network, connection issues may occur because only one IPsec tunnel is active, while both FortiGate-VMs may receive the forwarded traffic - but only one can route it through the tunnel. In that case, each FortiGate needs to establish an IPsec tunnel separately to the remote peer (ILB with persistence will not fix this, but FGSP with UTM enabled in policies will). 

Note 3: If traffic originates from the on-premises network to cloud network, the return traffic from the cloud machine will hit the ILB and this could send traffic to the wrong FortiGate (the one without IPSec tunnel established). This will happen even with persistence enabled in ILB, because in the original direction (on-premises -> FortiGate Azure -> cloud machine) the traffic will not traverse through the ILB, so no persistence will be created.
In order to not have dropped traffic, the policies from on-premises to cloud network should have SNAT enabled, this way, the cloud machine will reply to the FortiGate that SNATted the traffic and ILB will know which his because it is one of the IPs of the backend pool.

For more details, see the following GitHub document: GitHub - movinalot/fgt-in-azure-ipsec-troubleshoot.

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
• GitHub - movinalot/fgt-in-azure-ipsec-troubleshoot
• UTM inspection on asymmetric traffic in FGSP