Load Balancing Traffic Between Different Firewalls

AWS

In AWS Transit FireNet, you can either allow the Aviatrix Transit gateways to perform the load balancing (inherent/default function, configured when you create the FireNet gateway), or you can enable AWS GWLB (Gateway Load Balancer) when you create a FireNet in an AWS Transit Gateway (AWS TGW). Typically you select the latter to allow for scaling of firewalls without affecting established sessions.

Transit FireNet load balances the traffic across different firewalls using five-tuple hash (Source IP/Source Port/Destination IP/Destination Port/Protocol Type). The algorithm provides stickiness only within a transport session. Packets that are in the same session are directed to the same firewall. When the client starts a new session from the same source IP, the source port changes and causes the traffic to go to a different firewall.

Azure and GCP

Transit FireNet supports two- and five-tuple hash to load balance the traffic across different firewalls. You can change the hashing algorithm in the Azure or GCP portal. Load balancers are created automatically in Azure/GCP after Transit FireNet is enabled.

Hashing algorithms available in Azure cloud to load balance the traffic across different firewalls include Hash-based distribution mode (five-tuple hash) and Source IP affinity mode (two- or three-tuple hash).

Although the Azure load balancer supports three-tuple hash, the Aviatrix Controller does not.

Log in to Microsoft Azure’s Portal and Go to Load balancer under Azure services.
Click the Transit FireNet where Load balancing algorithm needs to be changed.
Go to Load Balancing rules under Settings and click LBRule.
Select hashing algorithm under Session persistence.
[arabic]
None > Default five-tuple (source IP, source port, destination IP, destination port and protocol type) hashing algorithm.

Client IP > This mode uses a two-tuple (source IP and destination IP).

Client IP and protocol > three-tuple uses source IP, destination IP, and protocol type.