I have a pretty reliable 300/20 cable connection from Spectrum Internet. It’s worked well for years and I’ve mostly avoided complicated Dual-WAN setups in prior years as they were tough to implement and manage. My connection was good enough that I didn’t see the need. A recent event where a regional fiber was cut and took out my primary connection has made me re-think my decision to avoid Dual-WAN. I assumed that my phone’s hotspot feature would be enough to get by during an outage. However LTE coverage is rather weak in our house and the mobile-phone approach and ultimately turned out to be a poor option in a real-world situation.
- TP Link TL-MR3020 – This router allows us to plug in a USB modem and spit out a NAT’d address through its Ethernet connection.
- Novatel Wireless USB551L – This is a Verizon modem that I found is specifically supported by the MR3020.
- Verizon Wireless SIM Card (full size) – The modem needs its own SIM card to connect, it costs me an extra $10/mo to add to my service.
- Ubiquiti USG – The USG will be our primary gateway to the internet and handles all traffic going through WAN1 and WAN2.
Building the Secondary WAN
To start my secondary WAN network, I first need to setup the TP-Link router. I connected my machine up to the MR-3020 to give it some basic configurations. Since we’re using this device exclusively for its LTE connectivity, we’ll choose the first option for Internet Access. ‘3G/4G Only (Recommended)’. You’ll need to put the switch on the side of the device onto 3G/4G mode as well or you’ll get different options in the web console.
Next we need to set up the network on the TP-Link. Remember its going to give your USG a NAT address. So your fail-over connection will essentially have a double-NAT situation. However that’s reasonable for most outgoing traffic, particularly for a secondary connection. I’m going to use the 192.168.101.0/24 network for this device since my cable modem is on 192.168.100.1, this just makes things easy to remember. If I ever need to get to the settings of either device, I just remember WAN 1 = .100.1, WAN 2 = 101.1.
We could use static IPs here, but I actually want this to be as ‘configuration-less’ as can be. I want to be able to plug anything into my WAN 2 connection the USG that provides an IP and a connection. Enabling DHCP on here also allows me to connect directly to the wireless network this device puts out as well.
I use a name of ‘al-failover’ for the WiFi and hide the SSID. I’ll know its there if I need to connect to it, and it also provides me an easy want to get a completely clean connection outside of my USG for troubleshooting. I just connect my laptop over to ‘al-failover’ and I’m in front of the USG going out though the LTE modem. Also useful if you want to test coming in from the outside of your USG through your primary WAN connection (say to test Remote User VPNs or Port Forwarding).
Configuring the USG
By default, the USG has its third port configured as a VOIP network. Sounds good if you need that for enterprise VOIP networks, but here in the homelab we’d rather have the redundancy of a secondary WAN connection. On the Site configuration page in the Unifi controller we need to enable WAN2.
After the USG finishes provisioning, we can connect the TP-Link to the LAN2/WAN2 port on the USG. Some older USGs have this port labeled as VOIP, but newer revisions call it LAN2/WAN2. Once everything settles out, you should see your WAN2 connection light up on your USG device in the controller. The WAN2 connection should be showing a 192.168.101.x address that it’s being assigned from the private side of the TP-Link router.
Now that we have all of our connections in place, let’s SSH into our USG and check out the load-balance status and watchdog features. From the SSH terminal of your USG, type ‘show load-balance status’. You should seen an output like this, showing you that both connections are in place and you’re in a failover configuration.
We can also check out the ‘watchdog’ by typing ‘show load-balance watchdog’. This is the process that watches each WAN connection and triggers the resulting failover in the event it cannot reach ‘ping.ubnt.com’. I was a bit skeptical at first with using Ubiquiti’s ping host but its hosted by AWS CloudFront so it should be fast and reliable for most people.
In this case, it is reachable by both connections since I’m connected properly to both.
However when I remove a the WAN1 connection you’ll notice the watchdog picks it up and flags it as unreachable. This triggers routing changes in the USG and now all my traffic is going out WAN2. In my testing, I’ve had all of this work so fast that I couldn’t tell it happened from running a ping to 220.127.116.11. Every ping went through and there was only a slight decrease in latency.
Now I’m officially failed over. While Ubiquiti still doesnt provide an alert when the WAN connection fails over, it does track the port statistics on the WAN2 connection. So I can go back and see when I’ve failed over to WAN2 simply by looking at its traffic stats compared to my WAN 1 statistics.