Load Balancing & Failover - more
The final step is to start routing traffic through the load balancer. For that ,we need to define three firewall rules:
|Primary ISP Traffic||Drive traffic to your Primary ISP||First|
|Secondary ISP Traffic||Traffic Destined for Second ISP||Second|
|Load Balancer Traffic||Direct Traffic across ISPs||Last|
Table 3: Load balancer rules
To define the rules, go to the Rules page (Firewall->Rules). The rules handle outbound LAN traffic, so go to the LAN tab. Let's first add the new rules, then delete existing rules.
|Log||Yes ( For Testing)|
Table 4: Primary ISP Traffic rules
For the secondary rules, we just change the destination:
|Destination||Secondary ISP Subnet|
|Log||Yes ( For Testing)|
Table 5: Secondary ISP Traffic rules
For the Load Balancing Rule, we want any traffic that doesn’t have a determined destination to go through the load balance gateway:
Table 6: Load balancer Traffic rules
This is what your finished rules will look like:
Figure 20: Firewall rules complete
To verify that everything started properly, go to the Load Balancer status page (Status->Load Balancer). It should be all green:
Figure 21: Load Balancer ready
Before we go any further, we should test load balancing and failover. Remember, Squid and HAVP are not multi-WAN enabled. These packages use a single interface and bypass the load balancer to push traffic out the interface you configured it to use, in our case the WAN PrimaryISP interface. So to test failover we’ll take down the SecondaryISP by simply disconnecting the cable. The system log should record the failure:
Figure 22: Log showing failover event
If the failure is not logged, or shows the wrong interface, most likely you’ve confused your pairs, using the wrong DNS address.
To test load-balancing, use a protocol other than HTTP, say FTP, POP, IM, etc. that doesn't go through Squid. You should see the rule trigger on the balancer gateway in the firewall log:
Figure 23: Load Balancer rule trigger
You can also check your States Table (Diagnostics->States). It should list some states associated with your Secondary ISP if load balancing is working.
Your network should now be ready for the next unplanned outage by your ISP.
Sticky Connections solves most requirements for persistent sessions, but you may want to do your own pre-emptive load balancing, especially if you will be running a proxy server such as HAVP and Squid. The template for these rules is:
Table 7: HTTPS Rule for Balancer Bypass
The HTTPS Destination Port in Table 7 can be FTP, SMTP, etc. This rule needs to be at the top of the list of rules—the load balancer rule should always be last. Using a failure gateway, traffic will, of course, fail over. If that isn’t what you want, change the gateway address to use the direct Gateway instead. In our example, that is Opt1/192.168.0.2 or WAN/192.168.100.100.
P2P traffic is much the same. You will have to use a static port and the destination port will need to agree with the configuration of your BitTorrent client (uTorrent uses 2000-3000). For incoming connections, you’ll need to define a port forwarding rule on your NAT, instead of using UPnP. More details are available in this pfSense tutorial.
That's all for this time. We'll try to wrap this up next time and run some performance tests to see if our hardware platform can handle all the extra duties we have piled onto it.