Basic concepts

This recipe is part of the process of deploying FortiGate HA Active Active for Microsoft Azure using Azure load balancer. See below for the rest of the recipes in this process:

1. Basic concepts
   • Traffic flow
   • Azure load balancer
     • Inbound NAT rules
     • Load balancing rules
2. Locate FortiGate HA for Azure in the Azure portal or Azure marketplace
3. Determine your licensing model
4. Configure FortiGate initial parameters
5. Create VNet and subnets in network settings
6. Select Azure instance type
7. Assign Azure IP address
8. Validate deployment resources
9. Create FortiGate instances
10. Connect to the FortiGate
11. [Use case] Set up a Windows Server in the protected network
12. Configure FortiGate firewall policies and virtual IPs
13. [Failover test] Create load balancing rules and access the Windows Server via remote desktop

This recipe covers basic concepts relating to deploying FortiGate for Azure and contains the following subsections:

• • Traffic flow
  • Azure load balancer
    • Inbound NAT rules
    • Load balancing rules

Networking is a core component in using Azure services, and using a virtual network (VNet) and subnets with appropriate routing will help 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 load balancer to be Active-Active for incoming traffic, as seen below. Two FortiGate instances are also deployed as part of an Azure HA set. This is the most basic architecture in this HA style. In this process, we will use RDP to make access to the Windows server fault-tolerant.

For further fault tolerance, you can create another Azure load balancer to be Active-Active for outgoing traffic, as seen below. This recipe 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.

Traffic flow

Inbound traffic comes through the load balancer. The load balancer 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 load balancer, both FortiGates become Active/Active once you configure load balancing rules on Azure.

For outbound traffic to be Active/Active, there must be another load balancer within the VNet which has user-defined routes (UDR) with next hops.

Generally, Active/Active using Azure load balancers 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 load balancers can send probes as often as every five seconds and will stop forwarding traffic after two failures. With Azure load balancers, 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 load balancer 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.

Azure load balancer

All traffic from outside Azure passes through the load balancer first. The load balancer 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 load balancer.

Load balancing rules

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] Create load balancing rules and access the Windows Server via remote desktop. In this example, you will test the fault-tolerance using RDP.

The post Basic concepts appeared first on Fortinet Cookbook.