This section describes some of the most common problems with multi-WAN and how to troubleshoot them.
Verify Firewall Rule Configuration¶
The most common error when configuring multi-WAN is improper firewall rules. Remember, the first matching rule wins and any further rules are ignored. If a policy routing rule is below the default LAN rule in the list, no traffic will ever match that rule because it will match the default LAN rule first. Review Policy Routing Configuration and verify the rules are correct.
If the rule ordering and configuration appears correct, it may help to enable logging on the rules. See Troubleshooting Firewall Rules for more information. Ensure the appropriate policy routing rule is passing the traffic.
Policy routing does not work for web traffic or all traffic¶
When a proxy package that can transparently capture HTTP traffic is used, such as squid, it overrides any policy routes that are defined for client traffic on that port. So no matter which gateway is set in firewall rules, traffic for HTTP (TCP port 80) will still go through squid and follow the firewall’s default route.
Failover not working¶
If problems occur when an Internet connection fails, typically it is because the monitor IP address is still answering, so the firewall thinks the connection is still available. Check Status > Gateways to verify. An IP address on the modem may be used as a monitor IP address, which will still be accessible even if the Internet connection is down.
Load balancing not working¶
Check that the Gateway Group is properly configured for load balancing, with at least two gateways on the same tier.
Check that the firewall rules being matched direct traffic to the correct load balancing gateway group.
Check that all of the gateways in the group show as Online under Status > Gateways. Connections marked as Offline will not be used.
Check the testing methodology. Rather than testing with a web browser, try testing with curl as described in Verifying load balancing.
Check that the traffic is not using a proxy or otherwise being initiated from a daemon on the firewall itself.
A gateway is incorrectly marked offline¶
If a gateway is listed as offline, but the WAN is actually up, several things could be at fault:
First, test to see if the monitor IP address responds to a ping from a client device on the LAN, and again from Diagnostics > Ping.
If the device with the monitor IP address or other intermediate hop drops ICMP echo request packets without a payload, manual pings would work but the gateway monitoring would fail. See Data Payload and set the payload to a value of
If the gateway or monitor IP address does not respond to ICMP echo requests, enter a different monitor IP address to use instead.
If the monitor IP address is configured as a DNS server for a different WAN, the static routes could be causing a conflict and the echo requests to the gateway may not be following the expected path. Set a non-conflicting monitor IP address on the gateway.
If there is an outbound NAT rule on the WAN with a Source of any, it can cause problems with traffic on the firewall, including monitoring traffic, because that will also NAT traffic from the firewall itself. This can be especially problematic if the source address is changed to a CARP VIP. Fix the outbound NAT.
If all else fails, it’s possible the circuit really is down, but the testing
methodology appears to show it up. Verify the Interface and Gateway settings and
run the test again, and try
traceroute to make sure the traffic is leaving
using the expected path.