Once multi-WAN has been configured, best practice is then to test its functionality to verify it functions as expected. The following sections describe how to test each portion of a multi-WAN configuration.
Testing Multi-WAN in a controlled manner immediately after configuration is a key step in the process. Do not make the mistake of waiting until an Internet connection fails naturally for the first test, only to discover problems when they are much more difficult and stressful to fix.
First, navigate to Status > Gateways and ensure all WAN gateways are show as Online under Status, as well as on the Gateway Groups tab. If they do not, verify that a proper monitor IP address is used as discussed in Gateway Settings.
Creating a WAN Failure¶
There are a number of ways to simulate a WAN failure depending on the type of Internet connection being used. For any type, first try unplugging the target WAN interface Ethernet cable from the firewall.
For cable and DSL connections, try powering off the modem/CPE, and in a separate test, unplug the coax or phone line from the modem. For fiber, wireless, and other types of connections with a router outside of pfSense® software, try unplugging the Internet connection from the router, and also turning off the router itself.
All of the described testing scenarios will likely end with the same result. However, there are some circumstances where trying all these things individually will find a fault that would not have otherwise been noticed until an actual failure. One of the most common is unknowingly using a monitor IP address assigned to the DSL or cable modem. Hence when the coax or phone line is disconnected, simulating a provider failure rather than an Ethernet or modem failure, the monitor ping still succeeds since it is pinging the modem. From what the firewall was told to monitor, the connection is still up, so it will not fail over even if the upstream connection is actually down. There are other types of failure that can similarly only be detected by testing all the individual possibilities for failure. The monitor IP address can be edited on the gateway entry as covered in Gateway Settings.
Verifying Interface Status¶
After creating a WAN failure, refresh Status > Gateways to check the current status. As the gateway monitoring daemon notices the loss, the loss will eventually move past the configured alarm thresholds and it will mark the gateway as down.
Verifying Load Balancing Functionality¶
This section describes how to verify the functionality of a load balancing configuration.
Verifying HTTP Load Balancing¶
The easiest way to verify HTTP load balancing is to visit a website that displays the public IP address the client used to access the site. A page on the Netgate site is available for this purpose, and countless other sites offer the same functionality. Search for “what is my IP address” and numerous websites are returned that will show the public IP address making the HTTP request. Many of those sites tend to be full of advertisements, so Netgate provides a handful of sites which report only the client IP address:
Browsers have a habit of keeping open server connections and caching results, so
the best browser-based test is to either load multiple sites, or to close the
browser window between attempts to load a site. During each connection attempt,
a different IP address should be shown if load balancing is working correctly.
If other traffic is present on the network, the IP address may not appear to
change on every page load. Repeat the test several times and the IP address
should change at least a few times. As an alternative to using a browser,
command line utilities such as
curl do not keep persistent sessions and are
more accurate for testing this behavior.
If the IP address never changes, try several different sites, and make sure the browser is requesting the page again, and not returning something from its cache or using a persistent connection to the server. Other good steps include manually deleting the cache, closing and reopening the browser, and trying multiple web browsers. If all of those fail to return the expected result, then start troubleshooting the load balancer configuration further.
Testing load balancing with traceroute¶
traceroute utility (or
tracert in Windows) shows the network path
taken to a given destination. See Using traceroute for details on using
traceroute. With load balancing, running a
traceroute from a client
system behind the firewall should show a different path being taken for each
attempt. Due to the way
traceroute functions, wait at least one minute after
stopping a traceroute before starting another test so that the states will
expire, or try different destinations on each attempt.
Using Traffic Graphs¶
The real time traffic graphs under Status > Traffic Graph and on the Traffic Graphs dashboard widget are useful for showing the real time throughput on WAN interfaces. Only one graph at a time can be shown per browser window when using Status > Traffic Graph, but additional windows or tabs can be opened in the browser to see all WAN interfaces simultaneously. The traffic graphs widget for the Dashboard enables the simultaneous display of multiple traffic graphs on a single page to simplify this process. If load balancing is working correctly, activity will be observed on all WAN interfaces.
The RRD traffic graphs under Status > Monitoring are useful for longer-term and historical evaluation of WAN utilization.
Bandwidth usage may not be exactly equally distributed, since connections are directed on a round robin basis without regard for bandwidth usage.