Fortinet black logo

VRRP HA using Azure Load Balancers

VRRP HA using Azure Load Balancers

To avoid the issues caused by the Azure API call HA deployment mode, FortiADC has developed a new design that incorporates the use of external and internal Azure Load Balancers. The objective of this design is to eliminate the need for IP migration by making the IP configurations that are affected during an HA failover independent on each FortiADC. For more information, see Deploying VRRP HA using Azure load balancers via the ARM template.

In the event of an HA failover, there are 5 configurations that will be affected:

  1. Virtual Server IP
  2. IP used in the VS NAT pool
  3. IP used in the Firewall NAT SNAT
  4. IP used as the network interface floating IP
  5. IP used in the Firewall 1-1 NAT

To avoid IP migration, the IP configuration needs to be independent on each FortiADC. This means that these FortiADC IPs should not be synchronized even when HA is active. Each FortiADC should maintain its own IP configuration (for all 5 configurations listed above), both on the FortiADC and Azure side as shown in Figure 3 below.

To achieve this, the FortiADC units are configured to maintain their own IP configuration. However, this is only achievable for 4 of the total 5 configurations listed above; the 5th configuration, the IP used for the Firewall 1-1 NAT, would still require using the Azure API call method for HA failover.

For the Firewall 1-1 NAT configuration, the Azure API calling method is required to migrate the IP during HA failover.

In FortiADC 6.2.0/6.2.1, the following IP configurations are not available in the VRRP HA in Azure:

  • IP used in the VS NAT pool

  • IP used in the Firewall NAT SNAT


In FortiADC 6.2.2, these IP configurations are available in the VRRP HA in Azure. For more information, see Virtual Server NAT Pool and Firewall NAT SNAT configuration in HA mode.

Figure 3 Independent IP configuration on both FortiADC side and Azure side

For more details on configuring the FortiADC for this new deployment mode, see Configuring the FortiADC-VMs to use Azure Load Balancer.

If you are using a virtual server IP and/or an interface floating IP, you will need to set up an Azure Load Balancer to achieve a single access endpoint.

For FortiADC version 6.2.0 or above, the VRRP HA deployment mode using Azure API call is no longer supported for virtual server IP and interface floating IP. An Azure Load Balancer is required for deploying HA for these IP configurations.

Why use the Azure Load Balancer?

The independent configuration of the virtual server IP on both FortiADCs would now be using Azure Load Balancers to provide the single access point for customers in the event of HA failover. The Azure Load Balancer publishes the IP address used by customers to provide the single point of contact for clients. Azure Load Balancer (ALB) distributes inbound flows that arrive at the load balancer's front end to backend pool instances. For deploying the FortiADC VRRP HA, the ALB distributes the inbound traffic to the FortiADC units (the backend pool instances). These flows are determined according to configured load-balancing rules and health probes.

ALB provides flexibility in defining the load-balancing rules. The function of the load-balancing rule is to declare how an address and port on the front end would be mapped to the destination address and port on the backend.

In FortiADC 6.2.0, the default rule type mapping of ALB is supported, using the secondary IP of the FortiADC in the ALB backend pool configuration. As shown in Figure 4 below, with the default rule type, Azure exposes a traditional load balancing IP address scheme for ease of use (such as the VM instances' IP). In the Figure 4 example, when receiving business traffic, ALB changes the packet destination IP from 51.x.x.x to 10.2.0.7, which is the secondary IP of the FAD1-OutSideNic attached to the HA active node, FAD-HA-VM1.

Figure 4 Azure Load Balancer with FortiADC HA pair

Azure Load Balancer uses health probes to monitor the FortiADCs in the backend pool by periodically sending the health check packet to all FortiADCs in the backend pool. The probing virtual server configured on FortiADC will respond to the health check packet from the ALB. Under known conditions in HA VRRP mode, only the probing virtual server on the active FortiADC will respond to the packet. Based on the health check result, ALB can direct the business traffic to the correct (active) FortiADC.

Configuring the FortiADC-VMs to use Azure Load Balancer

In FortiADC 6.2.0, the new configuration object "Azure LB Backend" was introduced. This can be found via the GUI in System > Azure LB Backend. When adding a new entry in the Azure LB Backend configuration on one node, the entry will be synchronized to the other node but excluding the IP address of the unit. On the second node, you will see the entry as 0.0.0.0. You will need to change this value to the Azure LB Backend IP of the second node. The Azure LB Backend configuration is designed to be used in the virtual server configuration screen to prevent configuration mistakes and re-using the same IP address.

As the IP address in the Azure LB Backend configuration object would not be synchronized in HA mode, you must configure it on both the FortiADCs in the cluster.

This feature is only available in the FortiADC Azure based images.

Using the Figure 4 example, the FAD-HA-VM1 configuration should look like this:


FAD-HA-vm1 # show system azure-lb-backend-ip

config system azure-lb-backend-ip

edit "FADHaLBBackendAddrPool"

set ip 10.2.0.7

end


And the FAD-HA-VM2 configuration should look like this:


FAD-HA-vm2 # show system azure-lb-backend-ip

config system azure-lb-backend-ip

edit "FADHaLBBackendAddrPool"

set ip 10.2.0.5

end


Settings

Guidelines

Name Azure LB Backend Pool Name. Valid characters are A-Z, a-z, 0-9, _, and -. No spaces. After you initially save the configuration, you cannot edit the name.
IP

IP address used in the Azure LB Backend Pool.

Note: The IP address would not be synchronized in HA mode.

The Azure LB Backend configuration object can be used in the virtual server configuration to reference the Azure LB Backend IP as the virtual server IP.


FAD-HA-vm1 # show load-balance virtual-server probing-vs

config load-balance virtual-server

edit "l7-vs"

set type l7-load-balance

set use-azure-lb-backend-ip enable

set azure-lb-backend FADHaLBBackendAddrPool

set interface port1

set port 8080

set load-balance-profile LB_PROF_HTTP

set load-balance-method LB_METHOD_ROUND_ROBIN

set load-balance-pool pool

set traffic-group default

next

end


Settings

Guidelines

use-azure-lb-backend-ip Enable or disable the virtual server to reference Azure LB Backend IP as the virtual server IP.
azure-lb-backend Select the Azure LB Backend IP Configuration used as the virtual server IP.

The Azure LB Backend IP configuration is an independent configuration on all FortiADC nodes. The virtual server references the Azure LB Backend IP as the virtual Server IP. In this way, the virtual server IP is no longer a shared configuration for FAD-HA-VM1 and FAD-HA-VM2.

Therefore, when an HA failover occurs, the traffic will be directed to the new active FortiADC by the ALB.

For more information, see Deploying VRRP HA using Azure load balancers via the ARM template.

VRRP HA using Azure Load Balancers

To avoid the issues caused by the Azure API call HA deployment mode, FortiADC has developed a new design that incorporates the use of external and internal Azure Load Balancers. The objective of this design is to eliminate the need for IP migration by making the IP configurations that are affected during an HA failover independent on each FortiADC. For more information, see Deploying VRRP HA using Azure load balancers via the ARM template.

In the event of an HA failover, there are 5 configurations that will be affected:

  1. Virtual Server IP
  2. IP used in the VS NAT pool
  3. IP used in the Firewall NAT SNAT
  4. IP used as the network interface floating IP
  5. IP used in the Firewall 1-1 NAT

To avoid IP migration, the IP configuration needs to be independent on each FortiADC. This means that these FortiADC IPs should not be synchronized even when HA is active. Each FortiADC should maintain its own IP configuration (for all 5 configurations listed above), both on the FortiADC and Azure side as shown in Figure 3 below.

To achieve this, the FortiADC units are configured to maintain their own IP configuration. However, this is only achievable for 4 of the total 5 configurations listed above; the 5th configuration, the IP used for the Firewall 1-1 NAT, would still require using the Azure API call method for HA failover.

For the Firewall 1-1 NAT configuration, the Azure API calling method is required to migrate the IP during HA failover.

In FortiADC 6.2.0/6.2.1, the following IP configurations are not available in the VRRP HA in Azure:

  • IP used in the VS NAT pool

  • IP used in the Firewall NAT SNAT


In FortiADC 6.2.2, these IP configurations are available in the VRRP HA in Azure. For more information, see Virtual Server NAT Pool and Firewall NAT SNAT configuration in HA mode.

Figure 3 Independent IP configuration on both FortiADC side and Azure side

For more details on configuring the FortiADC for this new deployment mode, see Configuring the FortiADC-VMs to use Azure Load Balancer.

If you are using a virtual server IP and/or an interface floating IP, you will need to set up an Azure Load Balancer to achieve a single access endpoint.

For FortiADC version 6.2.0 or above, the VRRP HA deployment mode using Azure API call is no longer supported for virtual server IP and interface floating IP. An Azure Load Balancer is required for deploying HA for these IP configurations.

Why use the Azure Load Balancer?

The independent configuration of the virtual server IP on both FortiADCs would now be using Azure Load Balancers to provide the single access point for customers in the event of HA failover. The Azure Load Balancer publishes the IP address used by customers to provide the single point of contact for clients. Azure Load Balancer (ALB) distributes inbound flows that arrive at the load balancer's front end to backend pool instances. For deploying the FortiADC VRRP HA, the ALB distributes the inbound traffic to the FortiADC units (the backend pool instances). These flows are determined according to configured load-balancing rules and health probes.

ALB provides flexibility in defining the load-balancing rules. The function of the load-balancing rule is to declare how an address and port on the front end would be mapped to the destination address and port on the backend.

In FortiADC 6.2.0, the default rule type mapping of ALB is supported, using the secondary IP of the FortiADC in the ALB backend pool configuration. As shown in Figure 4 below, with the default rule type, Azure exposes a traditional load balancing IP address scheme for ease of use (such as the VM instances' IP). In the Figure 4 example, when receiving business traffic, ALB changes the packet destination IP from 51.x.x.x to 10.2.0.7, which is the secondary IP of the FAD1-OutSideNic attached to the HA active node, FAD-HA-VM1.

Figure 4 Azure Load Balancer with FortiADC HA pair

Azure Load Balancer uses health probes to monitor the FortiADCs in the backend pool by periodically sending the health check packet to all FortiADCs in the backend pool. The probing virtual server configured on FortiADC will respond to the health check packet from the ALB. Under known conditions in HA VRRP mode, only the probing virtual server on the active FortiADC will respond to the packet. Based on the health check result, ALB can direct the business traffic to the correct (active) FortiADC.

Configuring the FortiADC-VMs to use Azure Load Balancer

In FortiADC 6.2.0, the new configuration object "Azure LB Backend" was introduced. This can be found via the GUI in System > Azure LB Backend. When adding a new entry in the Azure LB Backend configuration on one node, the entry will be synchronized to the other node but excluding the IP address of the unit. On the second node, you will see the entry as 0.0.0.0. You will need to change this value to the Azure LB Backend IP of the second node. The Azure LB Backend configuration is designed to be used in the virtual server configuration screen to prevent configuration mistakes and re-using the same IP address.

As the IP address in the Azure LB Backend configuration object would not be synchronized in HA mode, you must configure it on both the FortiADCs in the cluster.

This feature is only available in the FortiADC Azure based images.

Using the Figure 4 example, the FAD-HA-VM1 configuration should look like this:


FAD-HA-vm1 # show system azure-lb-backend-ip

config system azure-lb-backend-ip

edit "FADHaLBBackendAddrPool"

set ip 10.2.0.7

end


And the FAD-HA-VM2 configuration should look like this:


FAD-HA-vm2 # show system azure-lb-backend-ip

config system azure-lb-backend-ip

edit "FADHaLBBackendAddrPool"

set ip 10.2.0.5

end


Settings

Guidelines

Name Azure LB Backend Pool Name. Valid characters are A-Z, a-z, 0-9, _, and -. No spaces. After you initially save the configuration, you cannot edit the name.
IP

IP address used in the Azure LB Backend Pool.

Note: The IP address would not be synchronized in HA mode.

The Azure LB Backend configuration object can be used in the virtual server configuration to reference the Azure LB Backend IP as the virtual server IP.


FAD-HA-vm1 # show load-balance virtual-server probing-vs

config load-balance virtual-server

edit "l7-vs"

set type l7-load-balance

set use-azure-lb-backend-ip enable

set azure-lb-backend FADHaLBBackendAddrPool

set interface port1

set port 8080

set load-balance-profile LB_PROF_HTTP

set load-balance-method LB_METHOD_ROUND_ROBIN

set load-balance-pool pool

set traffic-group default

next

end


Settings

Guidelines

use-azure-lb-backend-ip Enable or disable the virtual server to reference Azure LB Backend IP as the virtual server IP.
azure-lb-backend Select the Azure LB Backend IP Configuration used as the virtual server IP.

The Azure LB Backend IP configuration is an independent configuration on all FortiADC nodes. The virtual server references the Azure LB Backend IP as the virtual Server IP. In this way, the virtual server IP is no longer a shared configuration for FAD-HA-VM1 and FAD-HA-VM2.

Therefore, when an HA failover occurs, the traffic will be directed to the new active FortiADC by the ALB.

For more information, see Deploying VRRP HA using Azure load balancers via the ARM template.