The problem with things that work by “Magic” is that they must always “Just Work”

Roughly 24 hours ago, the primary Internet at our mountain cabin went down for 90 minutes. No big deal, we’re not there, and there’s an LTE backup on WAN2. However, the “Site Magic” VPN tunnel never re-established itself.

In the past I’ve run EdgeRouters and USGs w/ IPSec tunnels so I’m familiar with Ubiquiti’s self-imposed challenges with multi-WAN, and that even with single-WAN the IPSec tunnels are not as resilient as they ought to be.

But Site Magic is supposed to be “magic.” It’s supposed to make it all better. It’s supposed to be so good that they don’t need bother giving me any tools to troubleshoot or give it a kick in the ass when it doesn’t work. A cursory Google search didn’t lead me to any “secret” CLI commands to provide more than the unifi.ui.com interface.

I’d say I’m disappointed… but, honestly, this kind of thing is typical of them and is why I want to quit their gateways.

Cheater’s NAT Bypass

Randomly came across a post looking for a method to disable NAT on the ARM-based UniFi routers… and, as usual, nobody had suggested the easy way.

The hard ways are:

  1. Reconfigure Networks as VLAN-only, configure DHCP to hand out the address of your other router. Disadvantage: UniFi doesn’t see the routed traffic so lots of information that UniFi provides will no longer be available.
  2. Use a script to remove NAT rules. Disadvantage: Has to run at boot, and whenever the device re-provisions, and ultimately is fragile across firmware updates and Ubiquiti randomly changing things.

But there is another way that doesn’t require running scripts on the device, doesn’t require reconfiguring all the Networks, and keeps all the traffic flowing through the UniFi router.

Simply have the other router somewhere on the LAN side and create two static routes pointing to it:

  • 0.0.0.0/1
  • 128.0.0.0/1

And that’s it. Those routes “win” over the NAT-ed WAN 0.0.0.0/0 route because they’re more specific.