Failover con dos proveedores de Internet en MikroTik (RouterOS 7)

Si tu empresa depende de Internet, un solo proveedor es un punto único de fallo. Con dos conexiones y un router MikroTik puedes configurar un failover: cuando el enlace principal se cae, el tráfico pasa automáticamente al de respaldo, y vuelve solo cuando el principal se recupera. En esta guía lo configuras en RouterOS 7, primero con el método básico y después con el método recomendado, que detecta caídas reales de Internet.

El escenario

Sustituye las IP por las de tus proveedores. Si alguno entrega la dirección por DHCP o PPPoE, al final verás cómo adaptarlo.

Paso 1: NAT para las dos salidas

Los equipos de la LAN deben salir a Internet por cualquiera de los dos enlaces, así que necesitas una regla de enmascaramiento (masquerade) en cada interfaz WAN. La forma más limpia es usar la lista de interfaces WAN:

/interface list member
add interface=ether1 list=WAN
add interface=ether2 list=WAN

/ip firewall nat
add chain=srcnat out-interface-list=WAN action=masquerade comment="NAT ambas WAN"

Si usas la configuración por defecto de MikroTik, la regla de NAT con out-interface-list=WAN ya existe; solo añade ether2 a la lista.

Paso 2 (método básico): distancia y check-gateway

La forma más sencilla son dos rutas por defecto con distinta distancia. Gana la de menor distancia, y check-gateway=ping la desactiva si el gateway deja de responder:

/ip route
add dst-address=0.0.0.0/0 gateway=192.168.1.1 distance=1 check-gateway=ping comment="ISP1 principal"
add dst-address=0.0.0.0/0 gateway=192.168.2.1 distance=2 check-gateway=ping comment="ISP2 respaldo"

Su limitación: solo comprueba que el router del proveedor responde. Si el módem sigue encendido pero el proveedor no tiene salida a Internet (algo muy común), el failover no se activa. Para eso existe el método recursivo.

Paso 2 (método recomendado): rutas recursivas

La idea es comprobar un host de Internet a través de cada proveedor. Si ese host deja de responder por el ISP 1, la ruta principal se desactiva aunque el módem siga vivo.

Primero, rutas de host que fuerzan a cada destino de prueba a salir por un proveedor concreto:

/ip route
add dst-address=9.9.9.9/32 gateway=192.168.1.1 scope=10 comment="Monitor ISP1"
add dst-address=208.67.222.222/32 gateway=192.168.2.1 scope=10 comment="Monitor ISP2"

Después, las rutas por defecto usan esos hosts como "gateway" (de ahí lo de recursivas), con check-gateway=ping:

/ip route
add dst-address=0.0.0.0/0 gateway=9.9.9.9 target-scope=11 distance=1 check-gateway=ping comment="Default via ISP1"
add dst-address=0.0.0.0/0 gateway=208.67.222.222 target-scope=11 distance=2 check-gateway=ping comment="Default via ISP2"

• scope=10 en las rutas de host y target-scope=11 en las rutas por defecto permiten a RouterOS resolver el gateway de forma recursiva.
• Usa como monitores direcciones que no utilices para otra cosa. Si pones 8.8.8.8 como monitor del ISP 1, todo el tráfico de tu red hacia 8.8.8.8 (por ejemplo, las consultas DNS) saldrá siempre por el ISP 1, incluso cuando esté caído.
• Elimina o desactiva las rutas del método básico si las habías creado.

Paso 3: si un proveedor usa DHCP o PPPoE

Con IP dinámica no puedes escribir el gateway a mano. Para el método básico, deja que el cliente cree la ruta con su distancia:

/ip dhcp-client
set [find interface=ether1] add-default-route=yes default-route-distance=1
set [find interface=ether2] add-default-route=yes default-route-distance=2

En PPPoE, la interfaz pppoe-out tiene la opción equivalente default-route-distance. Para el método recursivo con IP dinámica, la ruta de host del monitor puede apuntar a la interfaz PPPoE como gateway (por ejemplo, gateway=pppoe-out1), ya que es un enlace punto a punto; en DHCP se suele usar un script del cliente DHCP que actualiza el gateway del monitor cuando cambia.

Paso 4: probar el failover

1. Lanza un ping continuo desde una PC de la LAN a un sitio de Internet.
2. Desconecta el cable de ether1, o bloquea temporalmente la ruta del monitor con una regla de firewall para simular que el ISP 1 no tiene Internet.
3. En /ip route print verás que la ruta del ISP 1 queda inactiva y la del ISP 2 pasa a estar activa (marca A). El ping se corta unos segundos y se recupera.
4. Restablece el enlace y comprueba que el tráfico vuelve al principal.

El tiempo de conmutación depende del check-gateway: RouterOS hace ping cada pocos segundos y marca el gateway como caído tras varios fallos seguidos, así que el corte suele ser de algunos segundos. Las conexiones abiertas en ese momento (una videollamada, una descarga) se reinician, porque cambian de IP pública.

Errores frecuentes

• Olvidar el NAT en la segunda WAN: el failover cambia la ruta, pero el tráfico sale con IP privada y nada funciona.
• Usar como monitor una IP que también usas como DNS, como se explicó arriba.
• Conexiones "pegadas" tras volver al principal: el tráfico nuevo usa el ISP 1, pero algunas conexiones viejas pueden seguir por el ISP 2 hasta que terminan. Es normal.
• Firewall de input que bloquea las respuestas de los pings de monitorización: la configuración por defecto las permite, pero revisa si has personalizado las reglas.

Preguntas frecuentes

¿Puedo usar los dos enlaces a la vez?

Sí, eso es balanceo de carga. En MikroTik se hace normalmente con PCC (Per Connection Classifier), que reparte las conexiones entre los enlaces y se combina con el failover. Es más complejo porque requiere marcar conexiones y rutas, y lo trabajamos en detalle en el curso.

¿Y si tengo tres proveedores?

El método es el mismo: un monitor por proveedor y una ruta por defecto por cada uno, con distancias 1, 2 y 3.

Aprende MikroTik a nivel profesional

Failover, balanceo PCC, firewall, VPN y QoS: todo eso lo practicas con laboratorios en el curso de MikroTik MTCNA de cero a experto. Si quieres conectar a tu red desde fuera de forma segura, sigue con nuestra guía de VPN WireGuard en MikroTik.