Example: FortiADC L4 Virtual Server with HA VRRP mode using Azure Load Balancer Topology

Typically, an L4 virtual server using DNAT as the packet forwarding method requires the backend real server to have a route back to FortiADC. For this, the FortiADC uses the floating IP in the network interface as the default gateway for the backend real server.

In the Azure platform, the floating IP needs to be migrated in the event of an HA failover by using an Azure API call. To avoid the issues caused by the IP migration process, the internal Azure Load Balancer was introduced into the design.

Figure 5 FortiADC HA using Azure Load Balancer for L4 VS using DNAT topology

The Figure 5 example above shows the business traffic flow from the client → external ALB (FAD-HA-loadbalance-external) → the active FortiADC in HA VRRP mode → Ubuntu Apache web server → internal ALB (FAD-HA-loadbalance-internal) → the active FortiADC in HA VRRP mode → external ALB (FAD-HA-loadbalance-external) → the client.

In this deployment, we use the front end IP of the internal Azure Load Balancer instead of the floating IP in the FortiADC network interface as the web server default gateway. By doing so, there is no need to migrate the floating IP during an HA failover.

Creating an L4 virtual server using DNAT as the packet forwarding method with Azure Load Balancer

Similar to the steps taken for the Example: FortiADC L7 Virtual Server with HA VRRP mode using Azure Load Balancer Topology, follow the steps below to build an L4 virtual server using DNAT as the packet forwarding method on FortiADC.

1. Create the L4 virtual server on FortiADC and add the corresponding Load balancing rule on the external ALB, FAD-HA-loadbalance-external.
   
   
2. Check the inbound rule to allow access to port 1235 in the security group FAD-HA-Security-Group that is attached to both the FortiADC-VMs' network interface in the FadcHAOutsideSubnet.
   
3. In the FAD-HA-loadbalance-internal, check the front end IP, which is the default gateway for the backend web server.
   
4. Check the default route gateway of the backend web server. In this example, we use the Ubuntu Apache2 server as the backend web server. The default gateway should be configured to 10.2.1.6 to ensure the responding business traffic will go through the internal ALB, FAD-HA-loadbalance-internal.
   
   1. Check the route table attached to the FadcHAInsideSubnet on Azure Cloud.
      
      If you are using the ARM template to create the FortiADC HA pair with an existing network, you will need to manually associate the route table FAD-HARouteTable-FadcHAInsideSubnet to FadcHAInsideSubnet.
5. Check the Backend pools of FAD-HA-loadbalance-internal and add the ALB backend configuration on both FortiADC-VMs.
   
   
   
6. Check the Health Probe of the FAD-HA-loadbalance-internal and add the internal probing VS.
   
   
7. Check the Load balancing rule of FAD-HA-loadbalance-internal.
   The HA port is enabled so the FAD-HA-loadbalance-internal can load balance on all ports for TCP and UDP protocols. This means that the FAD-HA-loadbalance-internal can accept any TCP and UDP service traffic and direct them to the active FortiADC-VM based on the health probe.
   
8. Try to connect to the L4 virtual server with http://51.x.x.x:1235 to get an Apache2 Ubuntu default page.