Dual-WAN Failover Architecture with Starlink
When your primary line drops, the POS, VoIP, warehouse scanners and cloud ERP stop with it. A properly engineered dual-WAN setup switches to Starlink automatically, before staff notice.
How dual-WAN failover works
Assess your primary line
Map your fixed connection's reliability, bandwidth needs and single points of failure — this sets the failover threshold and health-check parameters.
Add Starlink as the secondary WAN
Terminate Starlink on a dedicated WAN port of a multi-WAN router. Where no fixed line exists, Starlink becomes primary and a cellular or fixed line covers backup.
Configure router-level health checks
The router probes the primary line continuously and switches WAN paths on failure — below the application layer, invisible to staff.
Test with a real line-pull
Physically disconnect the primary WAN and verify VoIP re-registers, VPN tunnels re-establish, and switchover time meets your target. A failover that was never tested does not exist.
What a resilient design accounts for
independent WAN paths
Fixed line and satellite fail independently — a fiber cut and a sky obstruction are unrelated events, which is the entire point of dual-WAN.
Router-level health checks
Continuous probing of the primary path with configurable thresholds — failover triggers on real loss, not a single dropped packet.
VoIP session continuity
SIP registrations and RTP streams must survive a WAN change. Plan re-registration intervals and NAT keep-alives so calls don't drop silently.
VPN tunnels across the switch
IPsec and WireGuard tunnels need to detect the underlying path change and re-key without manual intervention on either end.
CGNAT-aware VPN design
Starlink's standard plans sit behind CGNAT — a site-to-site tunnel must be initiated outbound from the Starlink side, or routed through a rendezvous point.
UPS across the whole chain
Router, antenna and switch all need backed-up power — a failover that trips during a blackout because the router lost power isn't a failover.
What we help you build
Components and guidance for a dual-WAN setup that actually fails over.
- Multi-WAN router selection
- Starlink hardware and mounting
- UPS sizing for the failover chain
- VPN and VoIP configuration review
- Failover test plan and checklist
Frequently asked questions
Should Starlink be primary or secondary?
If you have a reliable fixed line, keep it primary and use Starlink as backup — simpler and cheaper to run. Where no fixed line reaches the site, Starlink becomes primary and a cellular connection covers failover.
Will staff notice the switchover?
Not if health checks and failover thresholds are tuned correctly — the router changes WAN paths in seconds, and well-configured VoIP and VPN sessions re-establish automatically.
Why does CGNAT matter for VPN tunnels?
Starlink's standard plans put you behind carrier-grade NAT, so inbound connections can't reach you directly. The tunnel needs to be initiated from your side, or you need a static IP add-on or a rendezvous server.
What breaks if failover isn't designed properly?
VoIP registrations can silently drop, VPN tunnels can hang instead of re-establishing, and some cloud sessions may need to fully reconnect — all invisible until the primary line actually fails.
How do we know the failover actually works?
Only by testing it: physically pull the primary line, time the switchover, and confirm VoIP, VPN and critical applications recover. Schedule this periodically, not just once at installation.
Design a failover that holds up
Talk to our engineers about router selection, Starlink integration and UPS sizing for your site.