Before doing anything related to multi-WAN (installing or configuring), ensure that each WAN interface is working and that the default routing table is correctly configured for each WAN connection. Test each interface with a manual ping before modifying or implementing routing rules! It is essential to do some pre-configuration and test your connectivity for each WAN interface prior to this.

The main areas to check are:

1. Configure metric values for each WAN network interface.
2. Verify the routing table for each WAN network interface.
3. Do basic network tests on each WAN to ensure connectivity is working.

• You must configure each WAN interface with a different routing metric. This metric will only have an effect on the default routing table.
• The default (primary) WAN interface should have the lowest metric (e.g. 10) and each additional WAN interface a higher metric (e.g. 20, 30, etc.). Values are not important, but should always be unique.
• Every WAN interface should have a default gateway configured.

Note: PPPoE connections only show the “Use gateway metric” option if “Use default gateway” option is enabled.

WAN is the default wan interface in this example, and so will get a metric of 10.

• Network > Interfaces
  • WAN > Edit
    • Advanced Settings
• Use default gateway: enabled
• Use gateway metric: 10
  • Save & Apply

WANB is the second wan interface in this example, and so will get the a metric of 20.

• Network > Interfaces
  • wanb > Edit
    • Advanced Settings
• Use default gateway: enabled
• Use gateway metric: 20
  • Save & Apply

If configured correctly, you should have a default gateway (the lines with a target address of 0.0.0.0/0) with a unique metric set for each WAN interface. For example:

# ip route show
default via 10.0.3.2 dev eth1  proto static  src 10.0.3.15  metric 10 
default via 10.0.4.2 dev eth2  proto static  src 10.0.4.15  metric 20

Check that each WAN interfaces works by trying to ping www.google.com out from each interface. Ensure all interfaces are correctly sending and receiving traffic before proceeding.

• WAN is hardware interface eth0.1 in this example:

# ping -c 1 -I eth0.1 www.google.com
PING www.google.com (209.85.148.103): 56 data bytes
64 bytes from 209.85.148.103: seq=0 ttl=54 time=19.637 ms
 
--- www.google.com ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 19.637/19.637/19.637 ms

• Ensure the single ping is successful on this interface (“1 packets transmitted, 1 packets received, 0% packet loss” should be displayed)

• WANB is hardware interface eth0.2 in this example:

# ping -c 1 -I eth0.2 www.google.com
PING www.google.com (209.85.148.99): 56 data bytes
64 bytes from 209.85.148.99: seq=0 ttl=56 time=25.552 ms
 
--- www.google.com ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 25.552/25.552/25.552 ms

• Ensure the single ping is successful on this interface (“1 packets transmitted, 1 packets received, 0% packet loss” should be displayed)

• Repeat as above to ensure every WAN connection that has been created is working

When implementing multi-WAN routing you may experience issues with your ISPs DNS or email services depending your setup. This is due to many ISPs configuring their DNS/email servers to only allow source IP addresses within their network. Any attempts to use such services from “unknown” IP addresses will likely result in the traffic being dropped due to the source address not matching the ISP network.

For DNS, you can either use public open DNS resolvers outside of your ISP network to avoid this problem.

In a similar fashion to DNS. An ISP mail server will typically only accept POP3/IMAP/SMTP traffic from IP addresses within their network and block any attempt of sending mail from unknown IP addresses. You will have to ensure mail traffic goes through the specific WAN.

While multi-WAN is often designed around redundancy, in some cases, you may need to force traffic over a specific WAN to overcome this problem.