Load Balancing and Failover with Gateway Groups¶

Gateway Groups are necessary components of a Load Balancing or Failover configuration. The group itself does not cause any action to be taken, but when the group is used later, such as in policy routing firewall rules, the group settings define how the items utilizing the group will behave.

The same gateway may be included in multiple groups so that several different scenarios can be configured at the same time. For example, some traffic can be load balanced, and other traffic can use failover, and the same WAN can be used in both capacities by using different gateway groups.

A common example setup for a two WAN firewall contains three groups:

LoadBalance:: Gateways for WAN1 and WAN2 both on Tier 1
PreferWAN1:: Gateway for WAN1 on Tier 1, and WAN2 on Tier 2
PreferWAN2:: Gateway for WAN1 on Tier 2, and WAN2 on Tier 1

The best practice for any strategy is to have at least one failover group and to set that failover group to be used as the default gateway on the firewall. This ensures that the firewall always has a viable default gateway, and using a gateway group ensures that the correct gateways are used for this function and in the intended order. See Managing the Default Gateway for details.

Configuring a Gateway Group for Load Balancing or Failover¶

To create a gateway group for Load Balancing or Failover:

Navigate to System > Routing, Gateway Groups tab
Click Add to create a new gateway group
Fill in the options on the page as described in Gateway Group Options
Click Save

Load Balancing¶

Any two gateways on the same tier are load balanced. For example, if Gateway A, Gateway B, and Gateway C are all Tier 1, connections would be balanced between them. Gateways that are load balanced will automatically failover between each other. When a gateway fails it is removed from the group, so in this case if any one of A, B, or C went down, the firewall would load balance between the remaining online gateways.

Weighted Balancing¶

If two WANs must be balanced in a weighted fashion due to differing amounts of bandwidth between them, that can be accommodated by adjusting the Weight parameter on the gateway as described in Unequal Cost Load Balancing and Advanced Gateway Settings.

Failover¶

The firewall prefers gateways on a lower number tier. If the gateways on the lowest number tier are down then it looks for gateways on a higher numbered tier.

For example, if Gateway A is on Tier 1, Gateway B is on Tier 2, and Gateway C is on Tier 3, then the firewall uses Gateway A first. If Gateway A goes down, then the firewall uses Gateway B. If both Gateway A and Gateway B are down, then the firewall uses Gateway C.

Complex/Combined Scenarios¶

By extending the concepts above for Load Balancing and Failover, complicated scenarios are possible that combine both load balancing and failover. For example, if Gateway A is on Tier 1, and Gateway B and Gateway C are on Tier 2, then Gateway D on Tier 3, the following behavior occurs: Gateway A is preferred on its own. If Gateway A is down, then traffic would be load balanced between Gateway B and Gateway C. Should either Gateway B or Gateway C go down, the remaining online gateway in that tier would still be used. If Gateway A, Gateway B, and Gateway C are all down, traffic would fail over to Gateway D.

Any other combination of the above can be used, so long as it can be arranged within the limit of 5 tiers.

Problems with Load Balancing¶

Some websites store session information including the client IP address, and if a subsequent connection to that site is routed out a different WAN interface using a different public IP address, the website will not function properly. This has been more common with banks and other security-minded sites. One method of working around this issue is to create a failover group and direct traffic destined to these sites to the failover group rather than a load balancing group. Alternately, perform failover for all HTTPS traffic.

The sticky connections feature of pf is intended to resolve this problem. It is safe to use, and should alleviate this scenario, but there is also a downside to using the sticky option. When using sticky connections, the firewall remembers an association between the client IP address and a given gateway, it is not based off of the destination. When the sticky connections option is enabled, a single client would not load balance its connections between multiple WANs, but it would be associated with whichever gateway it happened to use for its first connection. Once all of the client states have expired, the client may exit a different WAN for its next connection, resulting in a new gateway pairing. As such, it works best in environments with many clients where one client utilizing a single WAN does not have a large impact.