Networking is a core component in using Azure services, and using a VNet and subnets with appropriate routing helps secure your resources at the networking level. Most required resources in HA are automatically deployed with ARM deployment templates embedded in the backend deployment process. Therefore you do not need to manually instantiate resources one by one or concern yourself with ARM templates.
An exception is when configuring load balancing rules on the automatically created Azure LB to be load-balancing for incoming traffic, as seen below. Two FortiGate-VM instances are also deployed as part of an Azure HA set. This is the most basic architecture in this HA style. In this process, remote desktop protocol (RDP) is used to make access to the Windows server fault-tolerant.
For further fault tolerance, you can create another Azure LB to be load-balancing for outgoing traffic, as seen below. This section does not cover this scenario.
In either case, there are typically at least two networks where a pair of FortiGate instances (FortiGate A and FortiGate B) as firewalls sit inline: subnet 1, named “PublicFacingSubnet” by default, which is used to connect the FortiGates’ port 1 to the public-facing side; and subnet 2, named “FortigateProtectedSubnet” by default, which is an internal protected network that connects to the FortiGates’ port 2.
A Windows Server is deployed on subnet 2, which is what you will create after subnet 1 and subnet 2 in order to test connectivity of incoming RDP access.
Inbound traffic comes through the LB. The LB determines the traffic flow, unless a connection is already established, in which case the flow follows the existing path. For inbound traffic coming from the LB, both FortiGate-VMs become load-balancing once you configure load balancing rules on Azure.
For outbound traffic to be load-balancing, there must be another LB within the VNet which has user-defined routes (UDR) with next hops.
Generally, load-balancing using Azure LBs for inbound and outbound traffic provides better availability in Azure. Fortinet does not recommend an Active/Passive solution. Any manipulation of UDRs or public IP addresses for Active/Passive solutions take 30 seconds to be applied after failover is initiated, whereas Azure LBs can send probes as often as every five seconds and will stop forwarding traffic after two failures. With Azure LBs, a failure is detected and mitigated with six to ten seconds.
The first time you access a FortiGate instance for initial configuration, inbound NAT is configured by default on the Azure LB for TCP ports 443 and 22 (443 = management GUI, 22 = SSH). For load balancing purposes, you need only one public IP address as the front end IP address, but there are two public IP addresses assigned to enable you to access both FortiGates at the same time.
All traffic from outside Azure passes through the LB first. The LB uses network address translation and port address translation (NAT/PAT) to connect a single public IP address to the Azure VNet. The Azure portal has two options for configuring these NAT rules: inbound NAT rules and load balancing rules.
Inbound NAT rules
These rules are applied to a specific host and are not load-balanced. As such, these are typically used for management. The ARM template automatically configures ports 443 and 22 for management access to the GUI and SSH of FortiGate. Note these should not be confused with FortiGate’s port forwarding because their functionality is the same. The location is different; in this HA, FotiGates are located behind the Azure LB.
These rules also use PAT, but rather than being directed at a specific host, they are directed at a collection of VMs called a backend pool. In this case, the pool consists of FortiGate A and FortiGate B. These rules are necessary to provide HA and load balancing for any given service, and you need to create rules to achieve HA. See (Failover test) Creating load balancing rules and accessing the Windows server via RDP. In this example, you will test the fault-tolerance using RDP.