In mid-2026, I set up a Starlink Mini to finally replace the barely tolerable 4G mobile internet where I live. Starlink was faster, more stable, and finally meant I could do things like make a video call. Still, Starlink depends on powered equipment and reasonable weather, none of which I can take for granted where I live.
Frequent power outages, storms, and heatwaves made me reluctant to retire the USB 4G modem I have been using here for years. Moving all my devices over to its Wi-Fi every time the weather stopped Starlink from working also didn’t exactly appeal to me. So, I moved the old 4G modem onto my edge OpenWRT router, and have my network a second way out with MultiWAN.
I made OpenWRT the traffic cop for both connections
The backup had to sit at the edge of my network, not beside it
My OpenWRT router is installed as a virtual machine and has the gloriously excessive hostname starlink-edge-lan-rtr01.home.local. That’s because it sits right at the edge of my LAN as the main ingress router, with every single network request passing through it.
The Starlink WAN sits on the interface eth1 as the primary WAN, while I passed the USB modem directly into the ESXi VM and attached it to eth2. From the perspective of the rest of my network, nothing else changes. Every device still uses the same gateway, IP address, and DNS settings configured by OpenWRT.
Just plugging in the modem wasn’t plug-and-play. I needed to install a few USB drivers on OpenWRT to allow the router to recognize the Ethernet over USB device:
apk updateapk add usbids usbutils kmod-usb-common kmod-usb-core kmod-usb-net kmod-usb-net-cdc-ether kmod-usb-net-cdc-ncm kmod-usb-net-rndis libusb-1.0-0These packages can also be installed via the LuCI web interface through System >Software > and search for and install each one at a time.
usbutils and usbids helped OpenWRT identify the modem, while the kmod-usb-net packages added support for USB Ethernet protocols CDC Ethernet, CDC NCM, and RNDIS. Finally, libusb allows OpenWRT to communicate with the device.
I confirmed the model and that its new network device appeared:
lsusbip link show eth2logread | grep -Ei 'usb|rndis|cdc|ncm|eth2'Once I knew OpenWRT could see the 4G modem, I created a new DHCP interface called wanb, attached it to eth2, and added it to OpenWRT’s existing WAN firewall rule. Once OpenWRT received an IP address from the 4G modem, the web UI LuCI showed Starlink and 4G connected at the same time.
I taught OpenWRT when to abandon Starlink
A second WAN is useless if the router never notices the first one has failed
At first, I thought relying on route metrics would reliably tell OpenWRT which interface to send traffic. I initially set the routing metrics as such:
- wan: 20
- wanb: 10
That worked just fine when I physically disconnected eth1, but it caused another problem. In a real-world situation, the Ethernet link to the Starlink disk, the upstream services, and routes beyond the gateway remained up. So, as far as the routing table was concerned, the road out still existed, but it no longer led anywhere.
Some better routing policy was needed, and OpenWRT’s MWAN3 MultiWAN manager was how I did it. I installed:
apk add mwan3 luci-app-mwan3And enabled and restarted the service:
/etc/init.d/mwan3 enable/etc/init.d/mwan3 restartIn OpenWRT’s LuCI interface, I enabled both wan and wanb as monitored interfaces. I gave each multiple tracking addresses, including 1.1.1.1 and 9.9.9.9, so one unresponsive server didn’t accidentally trigger a false failover.
MultiWAN then created an automatic policy with the correct order I needed. Its wan_m1_w3 member uses metric 1, while wanb_m2_w2 uses metric 2. I then assigned that policy to default_rule_v4, which made Starlink always the first choice, and 4G the fallback.
I could check MWAN3 and the underlying interfaces from SSH whenever I needed:
mwan3 statusubus call network.interface.wan statusubus call network.interface.wanb statusSo, in my setup, this was strictly failover and not load balancing, which MultiWAN can also do. Ordinary traffic now stays on Starlink and won’t fail over to 4G unless MWAN3 decides that Starlink has become unavailable.
The first real failover test was brutally simple
I disconnected Starlink and watched the router choose 4G
I tested the finished setup from a Windows machine connected to the 192.168.24.0 subnet, the same as OpenWRT’s LAN interface. In one PowerShell window, I started a continuous ping so I could see exactly when the connectivity disappeared.
ping 1.1.1.1 -tIn another, I ran this short script that checked my public IP every five seconds:
while ($true) { $time = Get-Date -Format "HH:mm:ss" try { $ip = Invoke-RestMethod "https://api.ipify.org" -TimeoutSec 3 "$time $ip" } catch { "$time OFFLINE" } Start-Sleep 5}Once Starlink’s addresses had appeared a few times, I SSH’d into OpenWRT and deliberately stopped the wan interface:
ifdown wanThe ping stumbled briefly while MWAN3 reached its failure threshold. It then marked wan as offline, and selected wanb under my wan_wanb MultiWAN policy. The PowerShell script then reported my mobile carrier’s public IP.
I restored Starlink with ifup wan. MWAN3 waited again for enough successful checks, decided the link was alive again, and returned new traffic to the primary connection. With every shutdown and reinstatement of the wan interface, I experienced no longer than a one-second outage.
This is still failover and not bonded internet. The two download speeds aren’t combined, and an active call, VPN, or download can absolutely still break when the public internet changes. But my laptop, phones, TVs, and all the devices that share my home network can still stay connected (albeit with a brief interruption) and remain on the same LAN.
It is not seamless, but it beats rebuilding my connection manually
Slower 4G is a fair trade when the alternative is no internet
Mobile internet also involves CGNAT, data limits, and broken calls or VPN sessions when the public IP changes. So, I can’t pretend this is nothing more than a backup route and not a perfect copy of Starlink.
In my case, the server running OpenWRT and the modem have UPS backup, but the Starlink antenna doesn’t, as it’s installed too far away from the house. The power circuit also regularly trips during storms, and the summer heat here regularly exceeds the operating temperature of the Starlink antenna. A complete blackout could also still take down switches and access points without power, rendering the failover useless.
Still, a hotspot protects one device and forces me to intervene. OpenWRT moves everything that remains powered onto 4G without changing its SSID, gateway, or DNS settings. It then smoothly returns the network to Starlink once it recovers.
The 4G modem doesn’t need to match Starlink’s speed. It only needs to keep essential work and communication going until it’s back up. I still notice when Starlink disappears, especially during a video call. What I no longer do is stop working, find the modem, reconnect everything, and rebuild my network around the outage.