Share via

Azure FortiGate HA – Need SNAT with Same Public IP as Inbound VIP + Failover Design

Dimitrov, Todor 20 Reputation points
2026-06-19T06:22:53.5566667+00:00

Hi all,

I’m running a FortiGate HA cluster (2 nodes) in Azure (Active-Passive) behind an Azure Standard Load Balancer. We are currently in a migration phase and expanding the number of public IPs.

Current Architecture

  • 2x FortiGate VMs in Azure (FGCP Active-Passive)
  • External Azure Standard Load Balancer
  • Multiple Public IPs assigned to the Load Balancer frontend
  • LB forwards inbound traffic (DNAT) to FortiGate
  • FortiGate handles internal routing to backend servers

    Inbound Works Fine

Example:

Public IP A → Azure Load Balancer → FortiGate → Server A

This part is working correctly using VIPs on FortiGate.

Problem (Outbound SNAT Requirement)

We need the following requirement:

Internal servers must use the SAME public IP for outbound Internet access as the one used for inbound VIP.

Example:

Current Issue

We tried implementing SNAT using the same Public IPs that are configured on the Azure Load Balancer frontend, but:

  • Those public IPs are owned by the Load Balancer
  • FortiGate cannot reliably use them as SNAT IPs
  • This results in asymmetric routing and session issues

Key Design Question

We need clarification on the correct supported design for this scenario:

  1. How can we achieve symmetric NAT (same inbound/outbound public IP) in Azure with FortiGate HA?
  2. Is it supported to use Azure Public IPs assigned to LB frontend for SNAT?
  3. If not, what is the recommended architecture?

High Availability Requirement

We also need the solution to support failover:

  • If FortiGate-1 fails
  • FortiGate-2 must take over
  • Public IP mappings must move automatically (or remain consistent)

So ideally:

We would like to know:

  • Is this achievable in Azure?
  • NIC-based Public IP association (manual or automated move)
  • Azure API / Automation / FortiGate HA script
Azure Firewall
Azure Firewall

An Azure network security service that is used to protect Azure Virtual Network resources.

0 comments

Answer accepted by question author

Thanmayi Godithi 10,820 Reputation points Microsoft External Staff Moderator
2026-06-22T13:21:11.9633333+00:00

Hi Dimitrov, Todor,

What you're looking for is essentially symmetric NAT, where the same public IP is used for both inbound and outbound traffic for a given application/workload:

For an Active-Passive FortiGate HA deployment in Azure, the main challenge is that the public IPs attached to an Azure Standard Load Balancer frontend are owned and managed by the Load Balancer, not by the FortiGate itself. As a result, using those same frontend public IPs as FortiGate-controlled SNAT addresses is generally not the design pattern described in Fortinet's HA guidance and can lead to the asymmetric routing and session-state issues you are observing.

From the FortiGate Azure HA documentation, there are two primary HA models:

  1. Active-Passive HA with External/Internal Azure Load Balancers
  • Public IPs remain attached to the Azure Load Balancer.
  • The Load Balancer handles failover using health probes.
  • Ingress and egress traffic can be inspected by the active FortiGate.
    • This architecture provides high availability, but it does not inherently guarantee a one-to-one mapping between an inbound VIP public IP and the outbound SNAT public IP.
  1. Active-Passive HA with SDN Connector Failover
  • FortiGate uses Azure API integration to update routes and shift public IP resources during failover.
  • When the passive node becomes active, it can take ownership of the relevant Azure networking resources.
    • This model is the closest match to your requirement of maintaining consistent public-IP identity across failover events.

Based on the requirement you've described, I would recommend evaluating the FortiGate SDN Connector HA architecture rather than attempting to use the Azure Standard Load Balancer frontend public IPs directly as SNAT addresses. The SDN Connector model was specifically designed to address Azure HA limitations around IP ownership and failover.

A couple of clarifying questions that will help determine the best design:

  1. Is the requirement specifically that Server A must always use Public IP A outbound because remote partners whitelist that address, or is it sufficient to use a consistent pool of outbound public IPs?
  2. Are the outbound connections originating from servers behind the FortiGate with a default route (0.0.0.0/0) pointing to the FortiGate?
  3. Which FortiGate Azure HA deployment model are you currently using (standard ELB/ILB HA, SDN Connector HA, custom automation, etc.)?
  4. Approximately how many public IP mappings need to maintain this inbound/outbound symmetry?

Those details will help determine whether the existing architecture can be adapted or whether a different FortiGate HA pattern would be more appropriate.

Was this answer helpful?

1 person found this answer helpful.
0 comments

0 additional answers

Sort by: Most helpful
Most helpful Newest Oldest

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.