Multi-WAN failover keeps users online when a primary internet path becomes unusable. The difficult part is deciding what counts as a failure. A gateway can still answer ping even when the wider internet is broken, and a link can be technically up while suffering severe packet loss. Good failover checks the service path you actually care about.
Video walkthrough
The simplest model
For a basic network, two default routes with different distances can provide simple failover when the gateway itself becomes unreachable. This is easy to understand but may not detect failures farther upstream.
Why recursive checks are useful
A recursive route can test reachability to a stable internet target through a specific WAN. If the target becomes unreachable, RouterOS can withdraw the associated default path. Choose check targets carefully and preferably use more than one independent signal for critical networks.
Policy routing complicates failover
If some clients, services, or VLANs are forced to a specific WAN, those policy rules also need a failover plan. Otherwise the main default route may switch successfully while marked or table-specific traffic remains stuck on the failed provider.
NAT must match routing
Each egress path needs appropriate source NAT. With dynamic WAN addresses, masquerade is common; with static allocations, explicit src-nat may be preferable. Confirm that return traffic follows the expected path and that connection tracking is not creating confusing results during failover.
Test more than cable removal
Test at least three scenarios: physically disconnect the WAN, keep Ethernet up but remove upstream internet, and create heavy loss or high latency. Record how long users take to recover. Some applications with long-lived sessions will need to reconnect because their public source IP changes.
Avoid calling load balancing “bonding”
Standard multi-WAN routing distributes connections; it does not combine two consumer links into one single TCP connection. True bonding requires support at both ends or an overlay service. Clear terminology prevents unrealistic expectations from users.
Frequently asked questions
Can two 500 Mbps WANs make one 1 Gbps speed test?
Not necessarily. Connection-based load balancing usually places one flow on one WAN. Aggregating a single flow requires a different architecture.
What should I health-check?
Use targets that verify the path beyond the local modem or gateway and that are stable enough for automation.
Will ongoing calls survive failover?
Some may not. A public IP change can break existing sessions, so clients may need to reconnect.
Next step
Document the result of your test and keep a known-good export. If your network behaves differently from the example, diagnose the topology rather than adding more rules blindly. Continue with a related guide from the tutorial library.