Don’t Forget about Bogons…
After a severe round of early September storms here in Southeast Michigan we’re in the midst of a multi-day power-and-internet outage. While mobile hot spots were kinda working, it was also a pain not having the normal network up, especially as I troubleshot why some Home Assistant devices didn’t come back online. So I set out to up our normal network with a tethered mobile phone as its public internet link instead of the cable modem.
This was super-easy to do, in general, using the aforementioned GL-MT3000 reset to defaults†, connected to an iPhone, in basic router mode, and plugged into the WAN port of my OPNsense router (replacing the cable modem). I did this instead of connecting the iPhone directly because OPNsense doesn’t have all the drivers needed loaded by default — changes I didn’t want to make for a temporary solution — and the router is down in the basement where cell phone signal isn’t quite as good.
(While I considered setting up multi-WAN with failover mode, this is a really rare occurrence, and I won’t be keeping the phone connected after Wide Open West comes back online, so replacing the cable modem was much cleaner and simpler.)
I did run into one wrinkle, though: bogons. OPNsense (25.7.1, at least) has an option to block RFC 1918 (private address) and bogon network ranges, but states that RFC 1918 addresses are not included. This is wrong.
I’d previously had both of these options enabled and unchecked the RFC 1918 box when switching around the interface. This was another fifteen minutes of frustration of looking for something else I was missing before I read the actual bogons list and saw the cause of the problem. Unchecked the bogons box in OPNsense and poof, everything worked.
(Specifically, the internal (LAN/WLAN) default GL-MT3000 config is 192.168.8.0/24. Because OPNsense WAN interface got its address from there, with the bogon boxe checked on this interface interface, the OPNsense router would not forward traffic from the GL-MT3000 internal network. Yet traffic from the OPNsense box itself, via shell utilities, flowed fine to and from that interface, so that misled me for a bit.)
Guess I need to submit a PR to the OPNsense project to fix those documents, or at least open a bug. Maybe once the main network is back up…
† Thanks to the lovely brownout, my GL-MT3000 would no longer boot. I had to use the Debrick via Uboot process to get it working again. Fortunately it wasn’t actually-dead. And now I’ll have to put back the IPv6 tunnel stuff… But at least that’s documented.