MikroTik Trainingmikrotiktraining.bd
Static routing

Dual-WAN Failover on MikroTik: check-gateway vs Recursive Routing

Why a backup default route with a higher distance is not always enough, and how recursive routes detect an upstream failure that check-gateway misses.

By Titas Sarker Published 26 Oct 2026 RouterOS v7.x
Commands in this article follow RouterOS v7 documentation but have not yet been marked as lab-tested on this site. Always test changes in a lab or maintenance window and keep a backup.

Problem

You have two ISPs. When the primary ISP stops passing traffic, the router keeps sending everything to it — your users are offline even though the backup link is fine.

Symptoms

  • The primary default route stays active while the Internet is down.
  • Failover only happens when the cable is unplugged.

Likely causes

  • check-gateway=ping only tests the next hop. If the ISP's gateway still answers but its upstream is broken, the route never fails.
  • Both routes have the same distance, or the backup route is missing.

Prerequisites

  • Two working WAN links. This guide uses documentation addresses: ISP1 gateway 203.0.113.1, ISP2 gateway 198.51.100.1.
  • NAT (masquerade) configured for both WAN interfaces.

Warning: Route changes affect all traffic. Apply them in a maintenance window, with Safe Mode on.

Solution

Option A — simple: distance plus check-gateway

Good when failures usually mean the link itself goes down.

RouterOS CLI
/ip route
add dst-address=0.0.0.0/0 gateway=203.0.113.1 distance=1 check-gateway=ping comment="WAN1 primary"
add dst-address=0.0.0.0/0 gateway=198.51.100.1 distance=2 comment="WAN2 backup"

Option B — recursive: test a host beyond the ISP

Route a well-known public address only through ISP1, then point the primary default route at that address. If the address becomes unreachable through ISP1, the primary route goes inactive and the backup takes over.

RouterOS CLI
/ip route
add dst-address=1.1.1.1/32 gateway=203.0.113.1 scope=10 comment="WAN1 probe host"
add dst-address=0.0.0.0/0 gateway=1.1.1.1 target-scope=11 check-gateway=ping distance=1 comment="WAN1 primary (recursive)"
add dst-address=0.0.0.0/0 gateway=198.51.100.1 distance=2 comment="WAN2 backup"

The target-scope=11 on the default route lets RouterOS resolve the gateway 1.1.1.1 through the host route, whose scope=10 is lower.

Verification

RouterOS CLI
/ip route print where dst-address=0.0.0.0/0

The primary route should be active (A flag). To test, block ICMP to the probe host on the ISP1 side (or disconnect the ISP1 upstream). Within a few ping intervals the primary route should become inactive and the backup should take over.

Common errors

  • The probe host is also used by users. Traffic to 1.1.1.1 will always go via ISP1. Pick a probe address your users do not depend on.
  • Recursive route never becomes active: check that target-scope on the default route is greater than or equal to the scope of the host route.
  • Failover works but sessions break: existing connections are tied to the old WAN's NAT address. That is expected; new connections use the backup.

Rollback

RouterOS CLI
/ip route remove [find comment~"WAN1"]
/ip route add dst-address=0.0.0.0/0 gateway=203.0.113.1 comment="WAN1 primary"
Go deeper in class

This topic is covered hands-on in MTCRE — MikroTik Certified Routing Engineer.

View MTCRE