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 Monitor IP.
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®, 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 pfSense 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 Monitor IP.
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 be marked 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 pfSense 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 spammy ads, so we provide a couple sites that simply report 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.
If the IP address never changes, try several different sites, and make sure the browser really is requesting the page again, and not returning something from its cache or using a persistent connection to the server. Manually deleting the cache, closing and reopening the browser, and trying multiple web browsers are good things to attempt before troubleshooting the load balancer configuration further.
Using curl as described in Verifying load balancing is a better test as it ensures cache and persistent connections will have no impact on the results.
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 simply directed on a round robin basis without regard for bandwidth usage.