With the Sophos XG Firewall it can be
We hate making mistakes. Sometimes our brain is too fast for our fingers to comply and the dreaded fat-finger rears. Groans ensue. Very rarely, it produces a hesitant, albeit slightly joyful, “Oh. Ooohhhh. Ha!”
When we were experiencing some issues with our F5 Load Balancers related to random dropped connections, we were looking for immediate alternatives to help resolve client issues. It turns out we didn’t have to look far.
While adding a new NAT for a client, we stumbled across a little section we had never used, and perhaps never realized it was even there, while playing around with some settings. It may have been a mistake (you probably realize by now that “It may have been” is actually “We made”) where we chose a list of IP addresses in the “Protected Server” field by accident.
You see – the choice to load balance on the Sophos XG Firewall is not presented to you unless you choose this one very important detail – using an “IP List” or “IP Range”:
Once added, magic begins to happen. And the “ohs” are added for shock, wonder, and amazement.
This new section becomes visible and you can choose the method of load balancing and how a health check, if desired, is performed. You can choose between four load balancing methods.
Now, if you added a health check, which is lightly configurable, you will be emailed (assuming you setup notifications on the Sophos XG under ‘Administration->Notification Settings’) when a pool member goes down and when a pool member returns to normal health. During testing, we would receive an email within seconds of a downed node.
Are there drawbacks? Certainly.
- The health check is minimal. You choose a protocol (TCP/ICMP) to monitor, a port, if TCP was chosen, and interval/timeout settings. There is no complex query to look for a specific string or a specific web page. In other words, there are no interactive health check options. It boils down to status 200 or do you respond to a ping.
- The current node status is unknown. Emails are the only method of determining whether all the nodes in a pool are healthy. A command, at the time of this writing, does not exist to determine the state of pool member nodes.
And the benefits?
- The servers we load balanced aren’t heavy load sites. They do receive consistent sessions. No noticeable CPU spike occurred on the 2×4 virtual Sophos XG we are running.
- By golly, load balancing works! We chose “round-robin” as our methodology and were able to verify new requests going to both back end web servers.
- While the health check is rudimentary, we were quickly alerted of potential issues across our pool members via email. And when they returned a second email was generated to alert of the “up” status.
- Load balancing on a device you already own without the need to buy a different device – this cuts costs and eliminates a point of failure in the network.
- Since the FW acts as the default gateway for the load balanced server group (all traffic will be returning to the FW), the load balanced traffic preserves the origin IP. With a traditional out of band load balancer, you would normally need to resort to other network tricks/architecture or enabling the “x-forwarded-for” header, to achieve this functionality.
In the end, we setup 15-20 load balanced web sites and are happy with the results. Our page response time has actually gone down. All thanks to a happy mistake.
Check out this Sophos KB for official documentation on this feature: https://community.sophos.com/kb/en-us/132277