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: https://fusecommunity.fortinet.com/p/fo/st/thread=2787
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: https://fusecommunity.fortinet.com/p/fo/st/thread=2787
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.
