Cybersecurity Forum

This forum is for all security enthusiasts to discuss Fortinet's latest & evolving technologies and to connect & network with peers in the cybersecurity hemisphere. Share and learn on a broad range of topics like best practices, use cases, integrations and more. For support specific questions/resources, please visit the Support Forum or the Knowledge Base.


FortiGate HA Options in Azure

Public cloud networks (including Azure) do not allow virtual appliances to modify layer 2/3 MAC/IP tables.  These are defined in software by the cloud environment.  Thus traditional HA and first hop redundancy, which rely heavily on gratuitous ARP, will not function in the public cloud.  There are, however, methods to achieve high availability within Azure.  Here are the four primary methods:

1. Public Access HA using the Azure load balancer and source-NAT.
2. East/West and outbound HA leveraging Azure SDN features.
3. Multiple VPN tunnels and source-NAT for DC connectivity.
4. Transit Vnet leveraging VPN tunnels, multiple Vnets, and BGP.

Depending on your architecture and requirements, the above can all be used individually or in combination. 

The first method is by far the most common and simplest deployment option.  Much of the Vnet configuration is preset for you by Fortinet's HA offer in the Azure marketplace.  This is focused on maintaining highly available, protected, public access to Azure hosted resources.  For this option, the Azure load balancer hosts one or more public IP addresses and forwards traffic on a per port basis to a pair (or more) FortiGates.  The FortiGates are configured with D-NAT, to forward the packets to web or other hosted services inside the Azure virtual network, and S-NAT to force return packets to symmetrically return to the same FortiGate virtual appliance.  Elaboration and Q&A for this can be found here:

The second option is often used in combination with the first for outbound traffic (example software updates and other traffic initiated by hosts within the virtual network).  It is not required for return traffic if initiated by public clients.  This option can also be used if inspection between subnets (or peered Vnets) is required.   It relies on the software defined networking capabilities of Azure to change user defined route tables when necessary.  The routing changes can be done with Powershell in Azure automation, or via a script on a local VM inside the virtual network.  Fortinet offers some documentation and a sample script, but this is primarily an Azure solution.  For more details see here:

The third option is fairly basic.  If you are routing traffic through VPN from your data center (or through ExpressRoute and wish to add encryption), you can create a VPN tunnel to each FortiGate and load balance at layer 3.  This works best for incoming traffic if you can also enable source-NAT to maintain symmetry for return traffic. You can use FGSP to synchronize sessions between FortiGates if source-NAT won't be possible.  In that case (and in the case where you are concerned about traffic going outbound from the virtual network through the tunnels), you will need to use this in combination with option 2.

The final option is designed to provide fast failover for east/west inspection between security zones in Azure.  It is quite complex, and has a bandwidth limitation of 100 or 200mbps per member virtual network.  In this option, a hub (or transit) Vnet is created, and 2 FortiGate virtual appliances are installed in that hub Vnet.  For each security zone, a member Vnet is created.  Each member Vnet is configured with an Azure VPN Gateway.  The VPN Gateway uses IPSec to create two tunnels (one to each FortiGate in the hub Vnet).  Once, the VPN tunnels are established, a BGP neighbor relationship is also configured between each FortiGate and each member virtual network.  At this point, redundant routes can be advertised (one via each tunnel), and Azure will use ECMP to load balance the traffic between the tunnels.  If either tunnel fails, the routes advertised through that tunnel are immediately withdrawn from the member Vnet's route table. The FortiGates must be configured with FGSP to synchronize session state and BGP to advertise routes between the member Vnets.

New Contributor

Hi all,


I need to setup a HA to control traffic betwen several internal subnets, looking at the cenarios on the deplyment guide i'm thinking to use the internal load balance cenario and have the UDR point to the internal load balance as the next hop to reach remote networks, apart from the probe does any one know what configuration needs to be done on the ILB ?





Azure has a new load balancer in preview which functions much more like a traditional FHRP VIP.  The big difference is that it can forward all protocols, rather than having to be configured on a per TCP/UDP port basis.

Here's their documentation on it:

A couple of things to note:

1. It must be enabled on a per subscription basis
2. It's only available in the following regions:

  • East US 2
  • Central US
  • North Europe
  • West Central US
  • West Europe
  • Southeast Asia

I have a new template that I've been developing to deploy this.  It does work currently as long as you deploy with 2 new public IPs (selected in the parameters):

Here's the main template:


If you can't use the preview ILB, things are much more difficult.  You can still do east/west inspection, but you have to configure a load balancer rule per destination port, and you have to enable source-NAT on all FortiGate policies (unless you can specify both source and destination port for your connections).



Hi Martin,

There appears a new HA solution introduced by NFR 0447861.

What are the pros and cons of using this a-p stateful HA option, compared with the a-a HA option w/ Azure loadbalancer?