Keep a remote site online when Starlink blips — recursive routing, connection marking, NAT, and netwatch failover on RouterOS v7.
Starlink is the best connectivity option for a rural villa, farm, or worksite that fixed broadband never reached — but it is not infallible. Obstructions, satellite hand-offs, congestion, and the occasional firmware reboot all produce short dropouts. For a guest house mid-booking or a business taking card payments, even ten seconds offline is a problem. The fix is a second WAN — 4G/LTE, DSL, or even a second Starlink — and a router that switches over the instant the primary path dies, then switches back when it recovers.
This is exactly the part that separates a clean MikroTik install from a dish bolted to a wall. We will build distance-based recursive failover (which detects a dead internet path, not just a live cable), per-WAN connection marking and NAT so traffic leaves the right interface, MSS clamping for the secondary link, and a netwatch health check that logs and can alert on every switch.
01
The dish reports "online" while the satellite path is already gone — which is exactly why naïve failover fails.
Starlink delivers a strong connection, but its availability profile is different from a fixed line. Brief outages happen during satellite hand-offs, when an obstruction clips the field of view, during congestion, and on firmware reboots. The Ethernet link between the dish and your router stays up through most of these — the cable is fine, the gateway still answers a ping — yet no traffic reaches the wider internet. Any failover scheme that watches only link state or pings the next hop will sit there happily on a dead connection.
Starlink also puts you behind CGNAT: you get a 100.64.0.0/10 address, not a public IP. That means no inbound port-forwarding and no classic VPN endpoint on the Starlink side — a constraint we design around, not against.
02
Two WANs into one router, both via DHCP, with default-route management taken away from the DHCP client so we can control failover ourselves.
Put Starlink on ether1 and the secondary line on ether2. Group them into a WAN interface list so firewall and mangle rules can reference both at once. Crucially, tell each DHCP client not to install its own default route — we add recursive routes by hand in the next section.
[admin@NOCTIS] > /interface ethernet set [find default-name=ether1] name=ether1-starlink /interface ethernet set [find default-name=ether2] name=ether2-lte /interface list add name=WAN /interface list member add list=WAN interface=ether1-starlink /interface list member add list=WAN interface=ether2-lte /ip dhcp-client add interface=ether1-starlink add-default-route=no use-peer-dns=no /ip dhcp-client add interface=ether2-lte add-default-route=no use-peer-dns=no # add-default-route=no is the key flag: we manage the default routes # manually so recursive failover can take over the decision.
03
Probe a real public IP through each WAN. The default route recurses through that probe — lose the path, lose the route.
The trick that makes Starlink failover reliable is recursive routing. We add a /32 route to a public test address (say 8.8.8.8) that is reachable only via the Starlink gateway, then add a default route whose gateway is 8.8.8.8 itself. RouterOS resolves the default route recursively through the probe; if Starlink's path to 8.8.8.8 dies, the probe route goes inactive, the default route deactivates, and the lower-priority route via the secondary WAN takes over. Because the probe is a real internet host, this catches the "dish up, internet down" case that defeats check-gateway on the local gateway.
[admin@NOCTIS] > /ip route add dst-address=8.8.8.8/32 gateway=100.64.0.1 scope=10 \ comment="probe-starlink" /ip route add dst-address=1.1.1.1/32 gateway=192.168.8.1 scope=10 \ comment="probe-lte" /ip route add dst-address=0.0.0.0/0 gateway=8.8.8.8 distance=1 target-scope=10 \ comment="primary: Starlink" /ip route add dst-address=0.0.0.0/0 gateway=1.1.1.1 distance=2 target-scope=10 \ comment="backup: LTE" # 100.64.0.1 is the usual Starlink (CGNAT) gateway; 192.168.8.1 is a # typical LTE modem gateway. Confirm yours with: /ip dhcp-client print
Both WAN gateways arrive over DHCP and can change. Hard-coding them as above works in practice (Starlink's CGNAT gateway is stable), but the robust pattern is to read the gateway from the DHCP lease in a script and update the probe route, or use a small scheduler that re-pins it on lease renewal. At minimum, re-check after any ISP swap.
You cannot port-forward into a Starlink site. For remote management (Winbox, SSH, or waking a server), terminate a WireGuard or Tailscale tunnel from inside the LAN outbound — it punches through CGNAT and gives you a stable address regardless of which WAN is active. See the companion Wake-on-LAN writeup for the Tailscale-over-CGNAT pattern.
04
Mark which WAN a connection belongs to, and masquerade out of whichever interface is currently active.
With two WANs you need source NAT on both, and — for any connection initiated from the outside or pinned to a WAN — a connection mark so replies leave the same interface they entered. For a CGNAT Starlink site most traffic is outbound, so the essential pieces are a masquerade rule per WAN plus an MSS clamp to avoid black-holed large packets on the LTE/PPPoE path.
[admin@NOCTIS] > /ip firewall nat add chain=srcnat out-interface=ether1-starlink action=masquerade /ip firewall nat add chain=srcnat out-interface=ether2-lte action=masquerade /ip firewall mangle add chain=prerouting in-interface-list=WAN \ connection-mark=no-mark action=mark-connection new-connection-mark=from-wan /ip firewall mangle add chain=forward protocol=tcp tcp-flags=syn \ action=change-mss new-mss=clamp-to-pmtu out-interface-list=WAN # MSS clamping prevents stalled TCP sessions on links that can't carry # 1500-byte frames — common on LTE and PPPoE backups.
05
Recursive routing handles the switch silently — netwatch makes it visible and lets you alert on every transition.
The failover above is automatic, but you want to know when it happens — a site living on its LTE backup for three days is burning a data cap. /tool netwatch actively probes a host and runs scripts on state change. Point it at the same public IP your primary path uses and log both directions; pair it with a Telegram or email notification for anything you manage remotely.
[admin@NOCTIS] > /tool netwatch add host=8.8.8.8 type=icmp interval=10s timeout=1s \ up-script="/log info \"WAN: Starlink path UP\"" \ down-script="/log warning \"WAN: Starlink DOWN — running on LTE backup\"" # Forward logs to a syslog server and alert on the 'DOWN' line so a # silent multi-day failover never costs you an LTE overage.
06
Failover restores availability, not security. The backup WAN is a second front door — treat it like one.
It is easy to harden the Starlink interface and forget the LTE modem that only carries traffic a few hours a month. Apply input filtering to the whole WAN interface list, not a single interface, so a new or backup WAN inherits the policy automatically.
[admin@NOCTIS] > /ip firewall filter add chain=input connection-state=established,related action=accept /ip firewall filter add chain=input connection-state=invalid action=drop /ip firewall filter add chain=input in-interface-list=WAN action=drop \ comment="drop everything else sourced from any WAN" # Reach the router for management over your WireGuard/Tailscale tunnel # or the LAN — never by exposing Winbox/SSH/API on a WAN interface.
Being behind Starlink's CGNAT hides you from casual inbound scans, but the moment you fail over to a public-IP LTE/DSL line, that shield is gone. The firewall above must stand on its own — don't rely on CGNAT for protection, because your backup path may not have it.
Takeaways
8.8.8.8 detects a dead internet path; check-gateway=ping on the local gateway does not catch Starlink's "dish up, link down" failure.add-default-route=no on both WANs lets distance-based recursive routes own the failover decision.WAN list keep both paths usable without stalled sessions on LTE/PPPoE.WAN protects every WAN; the firewall must hold on its own because the public-IP backup has no CGNAT shield.NOCTIS installs Starlink and wires it into a proper MikroTik network — multi-WAN failover, VLANs, VPN, and remote monitoring — so a remote villa, farm, or business stays online and secure. From site survey to managed connectivity.
See Starlink installation & managed connectivity →