Best 5G and LTE Failover Routers for a Homelab: Dual-WAN with OPNsense

One cut fiber line takes down a homelab’s VPN, remote Home Assistant and the alert that would have told you about it. A cellular router on a second WAN port fixes that. The box you pick matters less for its peak 5G speed than for one setting: whether it hands OPNsense the carrier IP or hides it behind its own NAT. That setting decides how cleanly a 5G failover router fits behind a firewall you already run.

Original content from computingforgeeks.com - post 176344

We built the failover side in October 2026 on OPNsense 26.7.7, nested in a Proxmox VM with a fiber uplink and a simulated 5G link, so every timing below was measured rather than quoted. The routers were checked against maker datasheets, carrier certification pages and Amazon US listings on October 21, 2026. This guide covers the four boxes worth buying, the gateway group that switches between them, and the failover and failback times you get with default and tuned monitoring.

The short list

Every pick below runs as WAN2 for OPNsense and covers the US low band that rural and indoor coverage depends on (T-Mobile n71 on 5G, band 71 on LTE). We ranked them by how little they get in the way of the firewall:

• Best overall, Teltonika RUTM50: dual-SIM 5G with a Passthrough mode in the web UI and AT&T, FirstNet, T-Mobile and Verizon certification. About $550 to $650.
• Best value 5G, GL.iNet GL-X3000 Spitz AX: the same Quectel RM520N-GL modem family for much less, but passthrough is an unofficial SSH command, so plan on double NAT. About $350 to $400.
• Cheapest reliable backup, Teltonika RUT241: LTE Cat 4 with the same RutOS Passthrough menu, for a line that only has to carry you through an outage. About $175 to $200.
• DIY modem, Waveshare RM520N-GL 5G to Gigabit Ethernet kit: a bare 5G modem that dials the carrier itself and passes the IP to OPNsense over Ethernet, configured by AT commands. About $340 to $370.

Prices move weekly on all of these, so treat the ranges as where they sat on the check date and check the current price on Amazon before you order. Teltonika has no Amazon storefront: the RUTM50 and RUT241 listings we link are sold by SolidSignal and shipped by Amazon, and the RUTM54 is sold and shipped by SolidSignal. The GL.iNet listing is sold by GL Technologies, GL.iNet’s own Amazon account, and the Waveshare kit by Waveshare.

How we picked and what we tested

Our failover numbers come from a lab, and the product specs come from paper. We never had a SIM in any of these routers, so radio behaviour, cell handover and carrier idle timers are outside what we measured. What we did measure is identical whichever box you buy. That covers how OPNsense notices the fiber is gone, how long new connections take to reach the 5G WAN, and what happens to sessions that were already open.

• Firewall: OPNsense in a nested VM with three virtio NICs (LAN, fiber WAN, 5G WAN), started on the release image and updated to the current point release halfway through, with no change in the timings. The screenshots are from the release image, before that update.
• Fiber ISP: a Linux network namespace with a static RFC 5737 address and about 10 ms to the monitor IP.
• 5G link: a second namespace handing out a 100.64.10.x address by DHCP, the way a router in passthrough mode hands out a carrier CGNAT address, with 45 ms of netem delay and 10 ms of jitter, which put the monitor at 52 to 60 ms.
• Client: a LAN host firing a fresh HTTP request every 0.25 s with a 1 s timeout, holding an SSH session, a 200 ms ping and a fixed-port UDP flow, so new and existing connections could be timed separately.

Every router spec comes from the manufacturer datasheet, checked against the carrier’s certification page or the vendor wiki. Seller, stock and price come from the live Amazon listing. Two candidates people ask about did not make it: the Teltonika RUTX50 has no n71 on the codes sold in the US, and the Netgear Nighthawk M7 has no built-in Ethernet port, only a USB-C adapter or a cradle.

The failover layout

OPNsense stays the router for the whole house, and the cellular box is demoted to a modem. In passthrough mode the 5G router gives its carrier address to the device on its LAN port by DHCP. OPNsense then sees a plain DHCP WAN and owns NAT, firewall rules and VPNs on both lines:

The alternative is router mode, where the 5G box runs its own NAT and OPNsense sits behind it. Outbound failover still works that way, and GL.iNet staff say as much for their routers. You pay with double NAT on the backup line, though: inbound port forwards stop working and anything that needs a reachable address on WAN2 breaks. Most carriers put you behind CGNAT anyway, so the bigger win from passthrough is a firewall that can see the real link state and a single NAT layer to debug at 2 a.m.

The four boxes side by side

These are the specs that change the decision for a WAN2 box. Throughput is not in the table because the cellular link is the bottleneck on all of them except the RUT241, whose ports are covered in its section:

Router	Radio	US low band	Passthrough	Ethernet	Power	Price band
Teltonika RUTM50	5G Sub-6, Quectel RG520N-NA	n71 and B71	Web UI: Mode Passthrough	5 x 1 GbE (1 WAN, 4 LAN)	9 to 50 V DC, passive PoE in	$550 to $650
GL.iNet GL-X3000	5G Sub-6, Quectel RM520N-GL	n71	SSH command only, experimental	2.5 GbE WAN, 1 GbE LAN	12 V adapter, 9 to 36 V in	$350 to $400
Teltonika RUT241	LTE Cat 4, 150 Mbps down	B71	Web UI: Mode Passthrough	2 x 100 Mbps (WAN, LAN)	9 to 30 V DC, passive PoE in	$175 to $200
Waveshare 5G ETH kit	5G Sub-6, Quectel RM520N-GL	n71	AT commands (Quectel IPPT)	1 x RTL8125, sold as Gigabit	9 to 12 V DC or 5 V USB	$340 to $370

None of the four supports mmWave, which does not matter for a fixed backup line indoors. The column that does matter is passthrough: only the two Teltonika routers put it behind a documented menu, and that’s most of the reason the RUTM50 wins.

Teltonika RUTM50 for a 5G line you can trust

We’d put the RUTM50 in a rack and stop thinking about it. It runs a Quectel RG520N-NA on a Qualcomm SDX62 and covers n41, n71 and n77 on the North America code. Teltonika lists AT&T, FirstNet, T-Mobile and Verizon certification for it. T-Mobile’s own IoT certification page rates it 3 of 3. Passthrough lives in the web UI under Network, WAN, the mobile interface, General Settings, Mode. A MAC field there pins the carrier address to the OPNsense WAN port, as the Teltonika WAN page shows.

• Two SIM slots: a second carrier for a failover inside the failover, which is the only way to survive one carrier’s regional outage.
• Five gigabit ports: one WAN, which can become a LAN port, and four LAN, so the router can also sit on a management VLAN without a switch.
• Power: a 9 to 50 V DC industrial connector plus passive PoE in on LAN1. That is not 802.3af or at, so a standard PoE switch will not power it.
• Draw: 5 W idle and 18 W maximum by the datasheet, small enough to leave on the same UPS as the firewall.

Skip it if the line will only ever be a slow emergency path, because LTE does that job at a third of the price. If you also want an eSIM, the RUTM54 adds one on top of the two SIM slots, runs RutOS with a Telit modem, and costs about $650 to $700.

GL.iNet Spitz AX when price comes first

GL.iNet’s Spitz AX carries a Quectel RM520N-GL with a broad band list that includes n41, n71 and n77, and GL.iNet sells it on Amazon through its own GL Technologies account; the listing we link adds a travel eSIM to the same router. It has two Ethernet ports against five on the RUTM50, a 2.5 GbE WAN and a gigabit LAN, and OPNsense plugs into the gigabit one. The OpenWrt base means you can SSH in and see exactly what the modem is doing. GL.iNet lists T-Mobile and AT&T IoT certification on the product page; it does not list Verizon.

Passthrough is the catch. There is no setting for it in the GL.iNet firmware, only an experimental RPC call over SSH. In the long-running forum thread, GL.iNet staff said in July 2026 that it did not work on the 4.9 beta, and in September that it would reach the GUI only after full testing. We’d run it in router mode, accept double NAT on the backup line, and keep the SSH trick for when you need it. The GL-XE3000 Puli AX is the same modem with a 47.4 Wh battery, about $400 to $450, which makes sense if the 5G box cannot sit on the UPS.

Pass on it if you need inbound connections over the backup line or a certification Verizon business support will recognise. GL.iNet’s firmware is also a reason to buy it if you already run OpenWrt elsewhere; our OpenWrt router guide covers the rest of that family.

Teltonika RUT241 as the cheap LTE backup

A backup line has one job, and the RUT241 does it for a third of the RUTM50’s price. It’s LTE Cat 4, rated 150 Mbps down and 50 Mbps up, on the North America code RUT241098000 with bands 2, 4, 5, 12, 13, 14, 66 and 71. It shares the RUTM50’s RutOS Passthrough menu, so OPNsense gets the carrier address the same way. Its two Ethernet ports are 100 Mbps, below the 150 Mbps Cat 4 rating, so on a strong signal the port caps the line before the radio does. For a line that only carries you through an outage, that is a limit we would accept.

Its power input is 9 to 30 V DC or passive PoE on LAN1, again not 802.3af. One owner on the Teltonika forum also reported heavy ICMP loss on the gateway monitor while the RUT241 sat idle in passthrough as a backup WAN, with no public fix. Watch the Loss column on the OPNsense gateway page for a day after setup, because a monitor that reads loss on an idle LTE line will flap your failover.

Waveshare RM520N-GL kit for a DIY modem

Waveshare’s kit is a Quectel RM520N-GL on a carrier board with a Realtek RTL8125 Ethernet chip, a metal case and four antennas. There is no web interface. The modem dials the carrier itself and, once set to Quectel’s IP passthrough mode, hands the carrier IP to whatever plugs into the RJ45 port. You send AT commands from a PC over the kit’s USB 3.1 port with a serial terminal on the modem’s AT port. Waveshare’s wiki sets up passthrough with these commands, which we took from the wiki and did not run ourselves:

AT+QCFG="data_interface",1,0
AT+QCFG="pcie/mode",1
AT+QETH="eth_driver","r8125"
AT+QMAPWAC=1
at+qmap="mpdn_rule",0,1,0,1,1,"FF:FF:FF:FF:FF:FF"
AT+CFUN=1,1

The last command reboots the modem, after which OPNsense should pull an address by DHCP on the port facing the kit. If your SIM needs an APN, the wiki sets it first with AT+CGDCONT. RM520N-GL owners on the Quectel forum run IP passthrough behind pfSense, and one reported “duplicate echo reply received” messages from the gateway monitor, which is worth recognising before you go chasing it.

• One port at a time: the modem serves either Ethernet or USB, not both.
• Power: 9 to 12 V through the DC jack with a 12 V adapter in the box, or 5 V over USB. Order the listing with the RM520N-GL in the title, because Waveshare also sells the bare carrier board without a modem.
• Certification: the module carries Verizon and AT&T approval, but the assembled kit is not certified as a unit, which matters if a carrier ever asks what’s on its network.
• Where to buy: the Amazon listing, sold by Waveshare, has the RM520N-GL fitted. On October 21 it was the EU-plug version with two left and 2.6 stars from two reviews, so budget for a US 12 V adapter and check the current price.

It is the wrong box if you want dual SIM or a UI you can hand to someone else at the house. Buy it if you’d rather own every layer and you don’t mind a serial terminal.

Inseego’s Wavemaker FX3100 also has a passthrough toggle in its web UI, under Advanced, LAN, IP Passthrough. We left it off the list because the only Amazon listing on the check date was a third-party seller that did not say which carrier SKU it ships, and the SKU decides the band set.

How fast OPNsense fails over to the 5G line

With default gateway monitoring, new connections reached the 5G WAN 15 to 20 seconds after the fiber died, and traffic went back to fiber about 49 seconds after it recovered. Five upstream-outage runs on two point releases landed in that window every time, and the tuned and loss runs moved it in predictable ways:

Setup	Failure	New connections on 5G	Failed 1 s requests	Back on fiber
Defaults, Member Down (5 runs)	ISP outage, link up, 65 to 99 s	15.4 to 19.5 s	12 to 15	48.7 to 49.4 s
Defaults, Member Down	Cable pulled, 70 s	17.8 s	13	3.8 s
Tuned fiber monitor: Time Period 10 s, Loss Interval 2 s	ISP outage, link up, 74 s	5.4 s	4	9.2 s
Member Down	15% random loss, 110 s	Never	43	n/a
Packet Loss trigger	25% random loss, 148 s	32.7 s, stayed on 5G	16	40.8 s
Member Down	25% random loss, 151 s	48.3 s, flapped 4 times	45	0.3 s

Switching itself is not the slow part. OPNsense compiles the gateway group into a pf rule with route-to pointing at the active tier, so failing over means reloading the ruleset. The wait is dpinger, the monitor, which averages packet loss over a 60 second window and calls a gateway down when that average crosses 20% or when latency passes the 500 ms high threshold. In the default run, the fiber went from Online to loss 11 seconds into the outage and to down at 16 seconds, at 21% averaged loss. That also means Member Down does not wait for 100% loss, whatever the docs’ wording suggests.

Failback is slower for the same reason. After the fiber came back, the 60 second window still held the outage, so the gateway sat in down until the average drained below 20% at about 48 seconds. The cable-pull run is the exception. When the port lost carrier, OPNsense restarted dpinger on link up with an empty window, so fiber was back in 3.8 seconds. Real outages usually look like the first row, with the ONT still lit and the ISP dead behind it.

Tuning the gateway monitor

Shortening the window on the fiber gateway is the one change that matters. We set Time Period to 10 seconds and Loss Interval to 2 seconds on the fiber gateway only and left the 5G gateway at defaults. Failover dropped to 5.4 seconds with 4 failed requests, and failback to 9.2 seconds:

You can confirm the new values took effect by reading the dpinger command lines from the OPNsense shell:

ps ax | grep [d]pinger

The fiber monitor now runs with -l 2s -t 10s, while the 5G monitor keeps the default -l 4s -t 60s:

75612  -  Is    0:00.01 /usr/local/bin/dpinger -f -S -r 0 -i WAN1_GW -B 198.51.100.2 -p /var/run/dpinger_WAN1_GW.pid -u /var/run/dpinger_WAN1_GW.sock -s 1s -l 2s -t 10s -d 1 9.9.9.9
76504  -  Is    0:00.01 /usr/local/bin/dpinger -f -S -r 0 -i WAN2_DHCP -B 100.64.10.58 -p /var/run/dpinger_WAN2_DHCP.pid -u /var/run/dpinger_WAN2_DHCP.sock -s 1s -l 4s -t 60s -d 1 1.0.0.1

A 10 second window reacts to a short burst of loss as readily as to a real outage, so it fits a primary line that is normally clean. On a fiber or cable line that drops a few percent at peak hours, keep a longer window and accept the slower switch, because every flap moves traffic onto a metered SIM and back.

Member Down or Packet Loss for a cellular backup

The Trigger Level on the group decides what counts as failure, and it is really a cost decision. In the current release the options read Member Down, Packet Loss, High Latency, and Packet Loss and High Latency, which is not quite what the docs list. The two we tested behaved like this on a degraded fiber line rather than a dead one:

• Member Down at 15% loss: never failed over. The fiber sat in the loss state for about 65 seconds of the 110 second impairment, never reached down, and the LAN lived with it.
• Member Down at 25% loss: failed over after 48 seconds, then flapped between fiber and 5G four times during the 151 second impairment as the average crossed 20% in both directions.
• Packet Loss at 25% loss: moved to 5G after 32.7 seconds once the average passed the 10% low threshold, and stayed there for the whole impairment.
• Packet Loss at 15% loss: took almost two minutes and flapped, because the measured loss wandered between 3% and 16% around the threshold.

So Packet Loss gives the better experience on a sick primary line, at the price of sending more of your traffic over the SIM. On an unlimited plan we’d pick Packet Loss. On a capped data plan we’d keep Member Down and accept a bad hour on degraded fiber over a surprise bill. Either way, don’t set the thresholds right at the loss level you expect, because that’s where both triggers flap.

What happens to SSH, VPNs and long-lived flows

Failover only moves new connections. A connection that already has a pf state stays on the gateway it started on, which is why the ping in our lab got zero replies through every default outage. Two per-gateway options change that, and both did exactly what their help text says:

• Failover States, on the fiber gateway: kills that gateway’s states when it goes down so clients reconnect over 5G. Without it, an SSH session with no client keepalive froze for the whole 93 second outage and resumed when fiber returned; with it, the session was cut and had to reconnect. A client with ServerAliveInterval 5 gave up after about 20 seconds (we tested it without Failover States).
• Failback States, on the 5G gateway: kills its states when a gateway with a better priority comes back. An SSH session opened over 5G during the outage was cut about one second after the fiber left the down state, so nothing lingers on the metered line.

Failback States keys off the gateway Priority number, not the group tier, so give the 5G gateway the higher number (we used 10 for fiber and 20 for 5G). Whether you want Failover States depends on what runs on the LAN. An SSH session or a database connection that would rather wait out a short outage is better off without it. A stream that reconnects on error recovers faster with it.

The surprise was continuous flows. A fixed-port UDP flow sending every 200 ms, the same pattern as a WireGuard keepalive from a LAN host, lost 199 of 199 packets during a 40 second outage even with Failover States on. OPNsense’s recovery script kills the states before it reloads the ruleset. A flow that sends five times a second re-creates its state through the old route-to in that gap, so it stays pinned to the dead WAN until fiber returns. We did not test a real WireGuard peer, but plan for a LAN-side tunnel to stay down during the outage and restart it from a script if it has to move.

Building the gateway group

Setup takes about ten minutes once the 5G box is in passthrough and plugged into a spare OPNsense port. If you’re starting from scratch, our guide to installing OPNsense on Proxmox gets you to a working LAN first. The OPNsense multi-WAN how-to is the upstream reference:

1. Assign the port facing the 5G router as a new interface and set IPv4 to DHCP, since passthrough hands out the carrier address that way.
2. Under System, Gateways, Configuration, give the fiber gateway priority 10 and the 5G gateway priority 20, tick Upstream Gateway on both so either can become the default gateway, and set a monitor IP on each that no gateway hands out as DNS. We used 9.9.9.9 for fiber and 1.0.0.1 for 5G.
3. Tick Failover States on the fiber gateway and Failback States on the 5G gateway if you want sessions moved, as the last section explains.
4. Under System, Gateways, Group, create a group with fiber on Tier 1, 5G on Tier 2 and the Trigger Level you chose.
5. Edit the LAN pass rule and set its Gateway to the group. Add a rule above it that passes DNS to the firewall itself with the default gateway, or a gateway-bound rule sends LAN DNS out a WAN instead of to Unbound. Do the same for your other private networks (VLANs, VPN subnets, static routes), or traffic between your own subnets follows the group out a WAN.
6. Under System, Settings, General, tick Allow default gateway switching so traffic from the firewall itself (Unbound, updates, a WireGuard endpoint on the firewall) also moves.

The current release rebuilt the group page on the new MVC framework. The menu path is the same, but the form is now a dialog, so screenshots in older guides no longer match it:

Step 6 is easy to skip because LAN failover works without it. In every run without it, requests from the firewall itself failed for the whole outage. The OPNsense docs make the same point about Unbound, whose lookups are traffic from the firewall:

That DNS override option caused the one real trap in the lab. The 5G link offered 1.1.1.1 as its DNS server, and with the override ticked OPNsense added a host route for 1.1.1.1 through the 5G gateway. If 1.1.1.1 had been the fiber monitor IP, the routing table would no longer have matched the intent. Pick monitor IPs the carrier does not hand out, or exclude the 5G interface from the override. Changing a monitor IP later also left the old host route in the table until a reboot.

Reading gateway state from the shell

OPNsense’s web UI refreshes slowly during an outage, so we watched the gateways from the OPNsense console instead. Enable SSH first if you haven’t (how to start the SSH server on OPNsense), then ask the gateway plugin for its status:

pluginctl -r return_gateways_status

A healthy pair shows status none on both, with the kill-states flags matching what you ticked:

{
    "dpinger": {
        "WAN1_GW": {
            "status": "none",
            "monitor": "9.9.9.9",
            "gateway": "198.51.100.1",
            "monitor_killstates": "1",
            "monitor_killstates_priority": "0",
            "priority": "10",
            "ipprotocol": "inet",
            "name": "WAN1_GW",
            "stddev": "0.4 ms",
            "delay": "10.6 ms",
            "loss": "0.0 %"
        },
        "WAN2_DHCP": {
            "status": "none",
            "monitor": "1.0.0.1",
            "gateway": "100.64.10.1",
            "monitor_killstates": "0",
            "monitor_killstates_priority": "1",
            "priority": "20",
            "ipprotocol": "inet",
            "name": "WAN2_DHCP",
            "stddev": "23.6 ms",
            "delay": "58.4 ms",
            "loss": "0.0 %"
        }
    }
}

Alarm history lives in the gateway log, and it’s the quickest way to see when each threshold tripped:

grep Alarm /var/log/gateways/latest.log

These four lines from one outage of about 99 seconds show the sequence behind the failover table, from loss at 12% to down at 21%, then back through loss to online:

<165>1 2026-10-21T07:42:47+00:00 fw-lab-01.internal dpinger 7192 - [meta sequenceId="1"] MONITOR: WAN1_GW (Addr: 9.9.9.9 Alarm: none -> loss RTT: 11.2 ms RTTd: 1.6 ms Loss: 12.0 %)
<165>1 2026-10-21T07:42:52+00:00 fw-lab-01.internal dpinger 7192 - [meta sequenceId="2"] ALERT: WAN1_GW (Addr: 9.9.9.9 Alarm: loss -> down RTT: 11.2 ms RTTd: 1.7 ms Loss: 21.0 %)
<165>1 2026-10-21T07:45:02+00:00 fw-lab-01.internal dpinger 7192 - [meta sequenceId="1"] ALERT: WAN1_GW (Addr: 9.9.9.9 Alarm: down -> loss RTT: 10.9 ms RTTd: 1.2 ms Loss: 20.0 %)
<165>1 2026-10-21T07:45:13+00:00 fw-lab-01.internal dpinger 7192 - [meta sequenceId="2"] MONITOR: WAN1_GW (Addr: 9.9.9.9 Alarm: loss -> none RTT: 10.9 ms RTTd: 1.1 ms Loss: 1.0 %)

A gateway that drifts between none and loss on an idle line, with no outage behind it, is the flapping case from the RUT241 section. Give it a longer window or a different monitor IP before you trust the group.

Why not a 5G modem inside OPNsense

Plugging an M.2 or USB 5G modem straight into the firewall looks cheaper and tidier, and on Linux it would be. The FreeBSD base under current OPNsense has no QMI driver and no MHI driver, so an M.2 modem in PCIe mode will not attach at all. The USB options that do exist each come with a limit:

• MBIM through umb(4): in FreeBSD since 15.0 and shipped in OPNsense’s base, but IPv4 only and with no interface type for it in the OPNsense GUI, which still offers PPP, PPPoE, PPTP and L2TP. Netgate staff saw about 15 Mbit/s at best on a Sierra EM7455 with MBIM or PPP.
• Serial PPP through u3g(4): works with Quectel and Sierra modules, at the same low speed in that test.
• ECM or RNDIS: the drivers exist, but the one report we found of an RM520N in RNDIS mode on OPNsense came up behind the modem’s own NAT.

That’s why the Waveshare pick is the Ethernet board and not the USB dongle Waveshare also sells: the modem does the data call itself, and OPNsense needs no cellular driver at all. If the firewall box is still undecided, our pfSense and OPNsense hardware guide lists boxes with the spare port this needs. Read the Intel i226 drop fix before you trust any 2.5 GbE port as a WAN.

Carrier home internet gateways are a different trade. T-Mobile’s support pages say its gateways cannot enable bridge mode, so OPNsense would sit behind double NAT. Verizon documents IP Passthrough on its Internet Gateway (ARC-XCI55AX), using the LAN2 port and switching off the Wi-Fi radios. A data SIM in one of the routers above is still the cleaner WAN2, because the plan and the hardware are not tied together.

A failover drill before you trust it

A gateway group that has never failed over has not been tested. The cheapest time to find a wrong monitor IP is a quiet evening, not the night the fiber gets cut. We’d run this drill once after setup and again after every OPNsense upgrade:

1. Pull the optical fiber out of the ONT and leave the Ethernet cable between ONT and firewall connected, so the firewall port keeps its link the way it does in a real ISP outage, and time how long a browser takes to load a fresh page.
2. Run the shell status command during the outage and confirm the fiber reads down and the 5G gateway none.
3. Check that the firewall itself can resolve names, which proves Allow default gateway switching is on.
4. Restore the fiber and confirm new connections and any metered-line sessions come back within the window you expect, about 49 seconds on defaults and about 9 with the tuned monitor.
5. Look at the data counter on the cellular router afterwards, so you know what an outage costs on your plan.

Put the cellular router on the same UPS as the firewall and the ONT, because a power cut is the outage people forget to test. Our homelab UPS guide sizes one for exactly this load. If the backup line will also carry remote access, Tailscale on OPNsense reconnects over whichever WAN is up and copes with the carrier’s CGNAT.