In this recipe, we configured a gateway group for load balancing. Gateway groups may be configured for failover or load balancing. With failover, some gateways have priority over other gateways, and only when all higher priority gateways fail, do the lower priority gateways come online. With load balancing, all gateways handle a share of the total WAN traffic. Load balancing would thus seem to be a good way to implement bandwidth aggregation, as the total bandwidth from all gateways will be available.
There is a significant limitation, however, on bandwidth aggregation using gateway groups. A single connection can only pass through a single gateway; therefore, the connection can at most utilize the bandwidth of the gateway through which it passes—not the total bandwidth of the gateway group. In practice, many file sharing technologies (such as BitTorrent) will use multiple connections when transferring files. Therefore, by making connections through all available gateways in the group, they will be able to utilize the total gateway group bandwidth.
Even after we add WAN-type interfaces, designate them as gateways, and place them in a gateway group, the new gateway group won't affect the default routing. The original WAN interface will still be the default gateway, and all outbound traffic will pass through it unless we change the firewall rules. Therefore, we have to create one or more rules to make sure at least one internal interface utilizes the new gateway group.
You can change the default gateway by navigating to System | Routing | Gateways and selecting a gateway from the Default gateway IPv4 and Default gateway IPv6 drop-down boxes. Click on the Save button when done.
After configuring the additional WAN interfaces, one of the first things we do is assign a DNS server to each of the WAN interfaces. Having a separate DNS server for each interface is a good policy; if we used the same DNS server for each interface, then a failure of that DNS server will cause DNS resolution to fail for the entire gateway group.
There is, however, an issue with using alternate DNS servers. pfSense uses its internal routing tables to find routes to DNS servers. Policy-based routing does not apply to traffic generated by pfSense. Therefore, we have to configure static routes if we want pfSense to use the right OPT WAN interface for a DNS query. Otherwise, all DNS queries will go through the primary WAN interface, and, as a result, DNS queries will fail if the primary WAN interface goes down.
If we don’t want to configure a static route for each gateway’s DNS server, one possible solution is to set the monitor IP for each gateway to the DNS server IP address. The monitor IP is an IP address (preferably outside of our network) that pfSense pings to determine whether a gateway is still up. If the ping attempts are getting an adequate number of responses, the gateway is considered up; otherwise, it is considered to be down. Very conveniently, pfSense creates an internal static route for monitor IPs. Therefore, if we make the DNS server the monitor IP, we won’t have to create a static route for the DNS server. The only drawback to this approach is that unless the DNS server is a server that we control, the administrators running the DNS server may look upon our constant pings as suspicious activity and block them. When our ping attempts fail, pfSense will deem the gateway to be down, resulting in a false positive. This is why the monitor IP is ideally a node outside of our network but still under our control. Nevertheless, setting the monitor IP to the DNS server should work in most cases.