Like every other website on the planet, SmallNetBuilder uses cookies. Our cookies track login status, but we only allow admins to log in anyway, so those don't apply to you. Any other cookies you pick up during your visit come from advertisers, which we don't control.
If you continue to use the site, you agree to tolerate our use of cookies. Thank you!

Router Charts

Click for Router Charts

Router Ranker

Click for Router Ranker

NAS Charts

Click for NAS Charts

NAS Ranker

Click for NAS Ranker

More Tools

Click for More Tools

Security How To

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:

Rule Explanation Order
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.

Action PASS
Interface LAN
Protocol ANY
Source LAN subnet
Destination Network, 192.168.100.0/24
Log Yes ( For Testing)
Gateway Default
Table 4: Primary ISP Traffic rules

For the secondary rules, we just change the destination:

Action PASS
Interface LAN
Protocol ANY
Source LAN subnet
Destination Secondary ISP Subnet
Log Yes ( For Testing)
Gateway Default
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:

Action PASS
Interface LAN
Protocol ANY
Source LAN subnet
Destination ANY
Log No
Gateway LoadBalance
Table 6: Load balancer Traffic rules

This is what your finished rules will look like:

Firewall rules complete

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:

Load Balancer ready

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:

Log showing failover event

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:

Load Balancer rule trigger

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:

Action PASS
Interface LAN
Protocol TCP
Source LAN subnet
Destination ANY
Destination Port HTTPS
Log No
Gateway 2ndWANFail
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.

More Stuff

Wi-Fi System Tools
Check out our Wi-Fi System Charts, Ranker and Finder!

Support Us!

If you like what we do and want to thank us, just buy something on Amazon. We'll get a small commission on anything you buy. Thanks!

Over In The Forums

I have a problem with IPv6 DNS: I am using Comcast via an ASUS RT-AC86U router with IPv6 enabled. On my LAN I have a Pi-hole on a Raspberry Pi 3B+ and...
Hi all,I have CL GPON fiber with the RT AC86U router connected to the ONT. I am connected using PPPoE & VLAN set to 201. I had a previous line speed o...
Hi there.I have an ASUS RT-AC66U_B1.For some reason, I have extremely slow page loads in the router's GUI since I updated the firmware to 384.12Is the...
Lots of invalid token freed, are these normal?Jul 15 22:29:15 kernel: FPM Pool 0: invalid token 0x00958000 freedJul 15 22:32:03 kernel: FPM Pool 0: in...
I just read this blog article https://www.privateinternetaccess.c...celeration-is-here-for-routers-using-openvpn/ which was very interesting.This is t...

Don't Miss These

  • 1
  • 2
  • 3