Technical Tip: How to setup FortiGate in Active-Active mode with Network Load balancer in AWS

vvikash · ‎08-23-2023

Description

This article describes how to setup FortiGate in Active-Active mode with Network Load balancer in AWS.

Scope

Availability Zone 1 (Having FortiGate 1).

Port1: External (Public) interface that is connected to Internet.

Port2: Internal Interface that is connected to the Private network.

No HA as well as Mgmt interface is needed in this lab.

Availability Zone 2 (Having FortiGate 2).

Port1: External (Public) interface that is connected to the Internet.

Port2: Internal Interface that is connected to the Private network.

Four subnets are needed for our Lab (Two for each AZ).

Window servers are placed in AZ1 and AZ2 respectively.

Four route tables are needed for our Lab. (Two for public as well as two for private).

Reference to create VPC, Subnets (Subnet Association), Route Table, and Internet Gateway has already been configured to these related documents:

https://docs.fortinet.com/document/fortigate-public-cloud/7.4.0/aws-administration-guide/932825/crea...

https://docs.fortinet.com/document/fortigate-public-cloud/7.4.0/aws-administration-guide/348339/atta...

https://docs.fortinet.com/document/fortigate-public-cloud/7.4.0/aws-administration-guide/60984/creat...

Solution

In an active-passive FortiGate (FGT) setup within AWS, a failover event can result in extended downtime.

This occurs because the active node must inform the cloud infrastructure that it is now the current master node and request resource allocation.
Control over the speed of the transfer of the Elastic Network Interface (ENI) from one interface to another within AWS's API is limited.
This is the reason for the use of an Active-Active (A-A) configuration. A load balancer is employed in front of the FortiGate (FGT), with the Elastic IP (EIP) serving as a listener on the load balancer.

The load balancer is responsible for distributing traffic to the FortiGates(FGTs). (Make sure to use a Network Load balancer as in this case TCP 3389 (RDP) traffic is used for the window server and NLB is a Layer 4 load balancer fulfilling these requirements).

Additionally, the load balancer performs health checks to determine the operational status of the FortiGates, ensuring they are functioning correctly.

All FortiGates receive sessions via the load balancer as long as they pass the health checks.

While an Active-Passive (A-P) cluster behind the load balancer is an option, it is generally more effective to use standalone FGT units behind the load balancer in multiple Availability Zones (AZs). This configuration provides a robust mechanism to withstand the complete failure of an AZ.

Note:

To be able to attach at least two Network interfaces, the Instances ('VM') size in AWS Must contain at least two vCPUs.

Port 1(Public1) of the Primary FortiGate resides within one subnet, whereas Port 1(Public2) of the Secondary FortiGate belongs to a separate subnet. (Two Elastic IP will be used with these ports for management purposes).

Port 2 (Private1) of the Primary FortiGate resides within one subnet, whereas Port 2 (Private2) of the Secondary FortiGate belongs to a separate subnet.

Window servers 1 and 2 are behind our Private subnets (Private 1 and Private 2 respectively).

Four subnets are needed for this Lab as shown in the below picture.

FortiGates exist in the same VPC and different AZ.

If using FGT_VM64_AWS, ensure that both FortiGates have valid licenses.

Steps:

Log in to the AWS management console, navigate to the EC2, and Launch the FortiGate-VM using the below article in 2 separate AZs with the required subnets created.

Note:

Primary FortiGate is getting the IP address (Public) from US-EAST-2A.

When launching the Secondary FortiGate, select the suitable Availability Zone. In this case, US-EAST-2b has been selected.

Customize the Security Group based on the network requirements. The Security Group allows to control the incoming and outgoing traffic to and from the EC2 instances.
Assign the security group rule to all interfaces on both FortiGate-VMs. The next step in the process, Adding network interfaces and elastic IP addresses to the FortiGate-VMs, explains creating additional network interfaces. Tighten the security group later.

Launch the Primary EC2 instance.
Launch the Secondary EC2 instance but in a different Availability Zone
To access the FortiGate, select the Primary EC2 Instance and obtain the Public IPv4 address. Open the address in a browser.
Once accessed, use 'admin' as the default username and the instance ID as the password, which can be found under the Instance ID by selecting the respective Instance. It will ask to change the password. Afterward, the License can be uploaded to the FortiGate (If BYOL is used).

On FortiGate 1 and 2.

A VIP (Virtual IP) will be created for the Windows server to facilitate internet traffic reaching the server via the FortiGate.

On the VIP policy make sure SNAT is enabled whenever we use ALB in front of FortiGate because ALB always sources NAT the traffic, so to avoid asymmetric routing enable NAT on VIP policy always so that traffic will reach to original server with FortiGate private ENI IP.

Even if the configuration appears correct, when attempting RDP, it will not be possible to not see any traffic in the firewall logs.

To resolve this, ensure that the security group associated with the firewalls in the AWS console allows RDP traffic

Creating Window server.

Launch a two-window instance in Private 1 and Private 2 subnet, select launch instance, Type window server, and select window server image from Marketplace as shown below picture, window server 1 is launched in subnet 1, similarly, window server 2 is needed to launch in subnet 2 in different AZ).

As shown in the picture, Instance 1 is located in Subnet 1, and a security group has been created to permit inbound HTTPS and RDP traffic.

Similarly, Windows Server 2 is in Subnet 2, and it is possible to usethe security group of Windows Server 1, as depicted in the image.

Alternatively, it is also possible to hover the mouse over Instance 1, 'right-click', select 'Launch More like this,' and then edit the settings for the subnet.

Created route table for Private subnet so that all traffic will be routed to corresponding Fortigate port 2.

This ensures that all traffic from the Windows servers flows through the connected FortiGate, allowing for comprehensive inspection.

Creating Network Load balancer

Sign in to AWS Console: Log in to the AWS Management Console.
Navigate to EC2: Go to the EC2 Dashboard.
Create a Load Balancer by selecting 'Load Balancers' in the navigation pane and then selecting 'Create Load Balancer'.
Choose Network Load Balancer: Select 'Network Load Balancer' as the load balancer type.
Configure Listeners: Configure the listeners, specifying the protocol and port for the backend targets.
Configure Subnets: Choose the VPC and select the subnets where the NLB is wanted to distribute traffic.
Assign Security Groups: Assign security groups to control inbound and outbound traffic to the NLB.
Configure Routing: Set up target groups and configure health checks for your backend instances.
Register Targets: Register the instances or IP addresses where the NLB routes traffic to.
Review and Create: Review the settings, and then select 'Create' to create the Network Load Balancer.
DNS Configuration: After creation, note the DNS name of theNLB. Use this DNS name to direct traffic to the applications.

The steps are shown in the pictures below:

Do not register on instance ID as the instance has more than one interface so it will not work (so the target group in load balancer should have registered target as IP address).
Once both FortiGates port1 IPs have been added to the NLB target
Go into load balancer select the NLB and turn on cross-zone load balancing

By doing this load balancing will be done in all AZs:

To check the health check, run a sniffer on FortiGate port1 to see if NLB is doing health checks. (Which NLB IP in that AZ can be visible). NLB will have a DNS name, which is used to do RDP for Windows servers.

FINAL NETWORK DIAGRAM:

Once everything is set, you will have, two FortiGates in two AZs having window server attached and VIPs are made in the firewall.

Traffic will be load-balanced by NLB as FortiGates are in the target group.

Results:

Initiate two different RDP sessions with the same DNS name of the Network load balancer as shown below picture and in first picture traffic went through FGT1 to window Server 1

In the below image with same DNS IP of NLB, traffic went to Windows server 2 through FGT2 (In a different AZ).

It is possible to run a sniffer in parallel on both FortiGates to verify matching logs and confirm that traffic is load-balanced across them. If one FortiGate fails, the automatic health check will mark it as unhealthy, and traffic will seamlessly route through the available FortiGate.

Additionally, this setup allows you to implement auto-scaling based on the network load:

Scale Out: Increase the instance count to handle higher loads.

Scale In: Decrease the instance count during lower traffic periods.