Contratas un segundo enlace ISP para “resiliencia”, lo conectas a un puerto libre del MikroTik y te sientes responsable.
Entonces el VPN empieza a oscilar, las llamadas suenan como un robot tragándose un módem y el equipo de finanzas no puede acceder al ERP salvo si se colocan en una esquina concreta de la oficina.
Dual WAN es fácil de activar. Hacer que se comporte—especialmente con túneles VPN—es donde están los cadáveres.
Esta es la guía de campo para realizar failover en MikroTik sin convertir la red de la oficina en un experimento barato de caos.
Qué estás realmente construyendo (y por qué falla)
Cuando la gente dice “failover”, normalmente quiere decir “si ISP A muere, usar ISP B”. Para VPNs, eso es solo la cáscara exterior.
El sistema real es una cadena de dependencias: decisiones de enrutamiento, comportamiento del NAT, alcanzabilidad del par del túnel, estado de sesión y con qué rapidez detectas el problema sin oscilar.
El enemigo no es la falta de funciones. RouterOS tiene las perillas. El enemigo son las configuraciones parciales que se pelean entre sí:
rutas por defecto compitiendo con rutas de política, connection tracking que fija flujos a un enlace muerto, NAT reescribiendo respuestas por la interfaz equivocada
y comprobaciones de salud que miden la cosa equivocada.
Aquí está el modelo mental más importante: el failover de VPN no es un único evento; es un cambio controlado de ruta preservando determinismo.
Determinismo significa: para cualquier flujo dado, puedes predecir qué WAN usa, qué IP de origen usa, qué hace el NAT y por qué túnel sale.
Si no puedes predecirlo, tus usuarios lo “descubrirán” mediante cortes.
Broma #1: Dual WAN es como comprar dos paraguas y asumir que la lluvia se programará alrededor de tus reuniones.
Los tres modos de fallo que ves en el campo
- Enrutamiento asimétrico: salida usa ISP A, la respuesta de entrada viene por ISP B (o viceversa). Las VPN y los firewalls stateful odian esto.
- Falsa salud: el gateway responde a ping pero el upstream está muerto; tu “failover” nunca se dispara porque mediste el salto equivocado.
- Tormentas de flapping: pérdidas de paquetes pequeñas hacen que el router rebote rutas/túneles cada pocos segundos. El VPN está “arriba”, pero nada se mantiene arriba.
Una cita, porque es verdad en operaciones
Werner Vogels (idea parafraseada): “Todo falla, todo el tiempo.” Construye sistemas que esperen eso y tu rotación on-call podrá dormir.
Hechos y contexto histórico (breve, útil, algo deprimente)
- IPsec precede a la comodidad de las “VPN en la nube” modernas. El trabajo central de los RFC data de los años 1990, lo que explica algunos de sus bordes afilados.
- El NAT traversal (NAT-T) se volvió normal porque todos insistieron en NAT. Encapsular ESP en UDP/4500 fue un compromiso práctico, no elegante.
- Los firewalls stateful cambiaron las expectativas de enrutamiento. Una vez que rastreas conexiones, “cualquier camino de vuelta” deja de ser aceptable; el tráfico de retorno debe coincidir con el estado.
- Multi-WAN se popularizó en PyMEs antes de estar bien implementado. Muchas oficinas pequeñas adoptaron ISP duales mucho antes de tener personal para operar enrutamiento por políticas de forma segura.
- BFD (Bidirectional Forwarding Detection) existe porque los protocolos de enrutamiento necesitaban detección de fallos más rápida que los timers de hello. MikroTik soporta BFD con algunos protocolos, pero la mayoría de diseños SMB nunca lo usa.
- “check-gateway=ping” no es un oráculo de alcanzabilidad. Te dice sobre un objetivo solo, y ese objetivo puede seguir respondiendo mientras Internet está en llamas.
- WireGuard es joven (década de 2010) e intencionalmente minimalista. Esa simplicidad facilita razonar sobre el failover comparado con pilas heredadas, pero aún necesitas disciplina de enrutamiento.
- El Carrier-grade NAT (CGNAT) rompió supuestos silenciosamente. Tu “IP pública” puede no ser tuya, y la iniciación de VPN entrante puede volverse imposible sin ayuda.
- Los timeouts del connection tracking importan más de lo que la gente piensa. Con failover, entradas conntrack obsoletas pueden fijar flujos a un egress muerto incluso después de cambiar rutas.
Principios de diseño que mantienen el failover de VPN sensato
1) Decide qué significa “éxito”: ¿enlace arriba, Internet arriba o VPN usable?
Un enlace físico puede estar arriba mientras el proveedor está haciendo blackhole a rutas. Un gateway por defecto puede responder mientras el DNS upstream está muerto.
Y un VPN puede mostrar “establecido” mientras tus aplicaciones hacen timeouts por problemas de MTU o enrutamiento asimétrico.
Tu objetivo de comprobación de salud debería coincidir con el nivel que te importa:
ping al gateway ISP detecta fallos L2/L3; ping a IP pública detecta alcanzabilidad upstream;
comprobación del extremo remoto del VPN detecta la viabilidad real del servicio. La mayoría de oficinas necesita al menos comprobación de alcanzabilidad upstream.
2) Prefiere enrutamiento determinista sobre “magia”
MikroTik puede hacer mucho automáticamente, pero los comportamientos automáticos suelen ser “razonables” solo en entornos de WAN única.
Dual WAN + VPN requiere elecciones explícitas:
- ¿Qué IP de origen debe usar cada túnel?
- ¿Qué WAN debe preferir cada túnel?
- ¿Qué tráfico puede hacer failover y qué debe permanecer fijo?
- ¿Cómo evitas que sesiones existentes queden pegadas a un WAN muerto?
3) Diseña para failover estable, no para failover veloz
Sí, quieres recuperación rápida. No, no quieres un router que cambie de opinión cada vez que un paquete estornude.
Añade histéresis: múltiples fallos consecutivos antes de cambiar y múltiples éxitos consecutivos antes de volver.
4) Trata el NAT como parte del enrutamiento (porque lo es)
Con dos WAN, las reglas NAT deben ser conscientes de la interfaz y alinearse con tu política de enrutamiento.
Si el tráfico sale por ISP B pero se NATea a la dirección de ISP A, te has causado un corte a ti mismo.
5) Mantén el enrutamiento del VPN aislado del enrutamiento de Internet de la oficina
Los fallos más limpios son fallos con alcance limitado. Pon la lógica de decisión del VPN en tablas de enrutamiento separadas (VRF si lo haces en serio),
o al menos tablas separadas con marcas de enrutamiento, y mantiene el tráfico de navegación por defecto fuera de esa lógica.
Broma #2: Si no puedes explicar tu enrutamiento por políticas en un diagrama de pizarra, tu router ya está conspirando contra ti.
Tres arquitecturas viables (elige una, no las mezcles)
Arquitectura A: Ruta por defecto activa/standby simple con iniciación limpia del VPN
Este es el diseño “oficina pequeña que quiere menos sorpresas”. Mantienes una ruta por defecto primaria vía WAN1 y secundaria vía WAN2 con mayor distancia.
Los peers VPN son alcanzables por el WAN activo; cuando WAN1 falla, el router cambia la ruta por defecto y el VPN se reestablece desde WAN2.
Pros: más fácil, menos reglas mangle, menor probabilidad de autodenegación por routing de políticas. Contras: las sesiones existentes mueren en el failover. Está bien; estás conmutando, no operando cirugía.
Mejor para: uno o dos túneles site-to-site, IPsec con peers dinámicos o WireGuard donde la reconexión es barata.
Arquitectura B: Enrutamiento por políticas con egress de VPN fijado + failover por túnel
Aquí enrutas explícitamente el tráfico del túnel VPN (IKE/ESP o WireGuard UDP) por un WAN preferido, pero permites fallback.
Usas marcas de enrutamiento para que “tráfico hacia el peer VPN” use una tabla dedicada con dos rutas por defecto: WAN1 primaria, WAN2 de respaldo.
Pros: aisla el control del VPN del tráfico de navegación de la oficina; evita flapping aleatorio de túneles por cambios generales de ruta.
Contras: más reglas, más formas de dispararte en el pie, requiere disciplina con listas de direcciones y reglas de rutas.
Arquitectura C: Dos túneles (uno por ISP) + enrutamiento dinámico o prioridad manual
Este es el enfoque “hazlo bien o no lo hagas” para conectividad inter-sitio seria. Construyes dos túneles independientes:
uno con origen en WAN1 y otro en WAN2. Luego ejecutas un protocolo de enrutamiento (o rutas estáticas con comprobadores) sobre los túneles.
Pros: redundancia real a nivel VPN, menor dependencia de un único túnel rekeyeando correctamente durante un evento del ISP.
Contras: más complejidad, requiere soporte del lado remoto y exige filtrado de rutas y métricas cuidadosas.
Si puedes ejecutar enrutamiento dinámico, también puedes usar BFD para detección rápida en algunas configuraciones. Si no puedes, mantenlo estático y estable.
Elección con opinión
Para la mayoría de oficinas: Arquitectura B es el punto dulce. Aísla el comportamiento del VPN sin forzarte a introducir protocolos de enrutamiento completos.
La Arquitectura A es aceptable si te conformas con desconexiones cortas. La Arquitectura C es para cuando las “desconexiones cortas” te hacen recibir gritos en reuniones trimestrales.
Tareas prácticas: comandos, salidas y decisiones
Estos son chequeos reales que puedes ejecutar mientras construyes o depuras. Cada tarea incluye: un comando, qué significa la salida típica y la decisión que tomas.
Los comandos son CLI de RouterOS salvo que se indique otra cosa. Puedes pegarlos en una sesión de terminal de MikroTik.
Tarea 1: Confirma el estado de la interfaz y velocidad/duplex (no asumas que el cableado está bien)
cr0x@server:~$ /interface/ethernet/print detail where name~"ether1|ether2"
0 name="ether1" default-name="ether1" mtu=1500 l2mtu=1598 mac-address=DC:2C:6E:AA:BB:01 arp=enabled
speed=1Gbps full-duplex=yes auto-negotiation=yes link-downs=0
1 name="ether2" default-name="ether2" mtu=1500 l2mtu=1598 mac-address=DC:2C:6E:AA:BB:02 arp=enabled
speed=100Mbps full-duplex=yes auto-negotiation=yes link-downs=7
Significado: ether2 tiene link-downs y negoció a 100Mbps. Eso no es “correcto”; es una pista.
Decisión: cambia el cable, revisa la entregada por el ISP o fija velocidad/duplex si el equipo upstream es limitado. Un enlace WAN inestable hace que la lógica de failover parezca rota.
Tarea 2: Ve tus rutas por defecto y si están activas
cr0x@server:~$ /ip/route/print where dst-address="0.0.0.0/0"
Flags: D - dynamic, A - active, c - connect, s - static
# DST-ADDRESS GATEWAY DISTANCE
0 As 0.0.0.0/0 198.51.100.1 1
1 s 0.0.0.0/0 203.0.113.1 5
Significado: la ruta WAN1 está activa; WAN2 está en espera (mayor distancia).
Decisión: si ambas están activas cuando esperabas una, obtendrás comportamiento tipo ECMP y fallos aleatorios de sesión a menos que lo planifiques.
Tarea 3: Verifica el comportamiento de “check-gateway” y si te está mintiendo
cr0x@server:~$ /ip/route/print detail where dst-address="0.0.0.0/0"
0 A S dst-address=0.0.0.0/0 gateway=198.51.100.1 distance=1 check-gateway=ping
1 S dst-address=0.0.0.0/0 gateway=203.0.113.1 distance=5 check-gateway=ping
Significado: estás haciendo ping a la IP del gateway, no a Internet.
Decisión: para un failover real, prefiere rutas recursivas con un objetivo público (o comprobaciones con scripts) de modo que pruebes más allá del primer salto.
Tarea 4: Comprueba objetivos de enrutamiento recursivo (enfoque recomendado para alcanzabilidad upstream)
cr0x@server:~$ /ip/route/print where comment~"rec-check"
Flags: D - dynamic, A - active, c - connect, s - static
# DST-ADDRESS GATEWAY DISTANCE COMMENT
0 As 1.1.1.1/32 198.51.100.1 1 rec-check-wan1
1 s 0.0.0.0/0 1.1.1.1 1 default-via-wan1
2 s 8.8.8.8/32 203.0.113.1 1 rec-check-wan2
3 s 0.0.0.0/0 8.8.8.8 5 default-via-wan2
Significado: las rutas por defecto son recursivas vía IPs públicas. Si la IP pública deja de ser alcanzable por ese WAN, la ruta por defecto cae.
Decisión: usa esto cuando quieras failover basado en “alcanzabilidad de Internet”, no en “el gateway responde ARP”.
Tarea 5: Confirma que el router puede alcanzar objetivos de salud vía el WAN previsto
cr0x@server:~$ /ping 1.1.1.1 routing-table=main count=3
SEQ HOST SIZE TTL TIME STATUS
0 1.1.1.1 56 57 11ms
1 1.1.1.1 56 57 10ms
2 1.1.1.1 56 57 11ms
sent=3 received=3 packet-loss=0% min-rtt=10ms avg-rtt=10ms max-rtt=11ms
Significado: existe alcanzabilidad, pero esto aún no prueba el camino específico del WAN a menos que lo restrinjas.
Decisión: si necesitas comprobaciones por WAN, usa reglas/tablas de enrutamiento y ping con routing-table=....
Tarea 6: Inspecciona reglas de enrutamiento (policy routing) y detecta reglas en sombra
cr0x@server:~$ /routing/rule/print
Flags: X - disabled
# SRC-ADDRESS DST-ADDRESS ACTION TABLE
0 10.10.10.0/24 lookup main
1 203.0.113.10/32 lookup to_wan1_vpn
2 203.0.113.11/32 lookup to_wan2_vpn
Significado: estás enroutando tráfico a peers VPN específicos vía tablas dedicadas.
Decisión: asegúrate de que el orden tenga sentido; una regla amplia anterior puede robar tráfico a reglas posteriores más específicas.
Tarea 7: Valida que las reglas NAT sean conscientes de la interfaz (y estén ordenadas correctamente)
cr0x@server:~$ /ip/firewall/nat/print
Flags: X - disabled, I - invalid, D - dynamic
# CHAIN ACTION SRC-ADDRESS OUT-INTERFACE COMMENT
0 srcnat masquerade 10.10.10.0/24 ether1 NAT-to-WAN1
1 srcnat masquerade 10.10.10.0/24 ether2 NAT-to-WAN2
2 srcnat accept 10.10.10.0/24 (none) no-NAT-to-VPN
Significado: la regla “no-NAT-to-VPN” está al final, por lo que nunca coincidirá antes de masquerade.
Decisión: mueve las reglas accept por encima de masquerade. El orden del NAT no es un debate filosófico; es un motor de ejecución línea por línea.
Tarea 8: Verifica SAs IPsec activas y confirma qué dirección local usan
cr0x@server:~$ /ip/ipsec/active-peers/print detail
0 address=203.0.113.200 local-address=198.51.100.10 state=established
nat-traversal=yes ike2=yes exchange-mode=ike2
Significado: el túnel está establecido y tiene origen en la IP pública de WAN1.
Decisión: si ocurre failover y sigue originando desde el WAN muerto, necesitas manejo explícito de local-address o política de rutas para el tráfico hacia el peer.
Tarea 9: Revisa políticas IPsec y si son demasiado amplias (causando fugas de ruta)
cr0x@server:~$ /ip/ipsec/policy/print
Flags: T - template, D - dynamic, X - disabled, A - active
# SRC-ADDRESS DST-ADDRESS SA-SRC-ADDRESS SA-DST-ADDRESS
0 A 10.10.10.0/24 10.20.20.0/24 198.51.100.10 203.0.113.200
1 0.0.0.0/0 0.0.0.0/0 198.51.100.10 203.0.113.200
Significado: hay una política 0/0. Eso es una trampa de “encaminar todo tráfico dentro del túnel” a menos que realmente estés construyendo túnel completo.
Decisión: elimina o desactiva políticas amplias a menos que puedas explicárselas a tu yo futuro a las 3 a.m.
Tarea 10: Verifica handshakes de WireGuard y transferencia en cada enlace
cr0x@server:~$ /interface/wireguard/peers/print detail
0 interface=wg0 public-key="..." endpoint-address=203.0.113.210 endpoint-port=51820
allowed-address=10.20.20.0/24 persistent-keepalive=25s
last-handshake=1m12s rx=145.2MiB tx=162.9MiB
Significado: los handshakes ocurren; el tráfico fluye. Si last-handshake crece durante el “failover”, no te estás reestableciendo.
Decisión: verifica el enrutamiento del endpoint y reglas NAT; considera dos peers/endpoints si el lado remoto soporta ambos ISPs.
Tarea 11: Revisa connection tracking por flujos pegados al WAN equivocado
cr0x@server:~$ /ip/firewall/connection/print where dst-address~"203.0.113.200" and protocol=udp
Flags: S - seen-reply, A - assured, C - confirmed, D - dying
# PROTO SRC-ADDRESS:PORT DST-ADDRESS:PORT TIMEOUT TCP-STATE
0 SAC udp 198.51.100.10:4500 203.0.113.200:4500 00:00:27
Significado: el flujo NAT-T de IPsec está rastreado y fijado a un origen concreto. Durante el failover, entradas antiguas pueden seguir intentando el camino muerto.
Decisión: después del cambio de ruta, puede que necesites limpiar entradas conntrack específicas (quirúrgicamente) para forzar la re-establecimiento.
Tarea 12: Vacía solo lo que debes (reset quirúrgico de conntrack)
cr0x@server:~$ /ip/firewall/connection/remove [find dst-address~"203.0.113.200" and protocol=udp]
Significado: elimina flujos rastreados hacia el peer para que el túnel pueda renegociar usando la nueva ruta.
Decisión: evita vaciar todas las conexiones a menos que disfrutes explicarle al CEO por qué se cayeron todas las llamadas.
Tarea 13: Captura tráfico para confirmar qué interfaz se usa realmente
cr0x@server:~$ /tool/sniffer/quick interface=ether1 ip-address=203.0.113.200
TIME NUM DIR SRC-ADDRESS DST-ADDRESS PROTOCOL SIZE
0.01 1 tx 198.51.100.10 203.0.113.200 udp 146
0.02 2 rx 203.0.113.200 198.51.100.10 udp 146
Significado: el tráfico está usando ether1. Si crees que fallaste a ether2 pero ves paquetes en ether1, el enrutamiento/NAT no hace lo que crees.
Decisión: confía en la captura de paquetes por encima de los dashboards y las intuiciones.
Tarea 14: Observa cambios de ruta en vivo mientras simulas una falla
cr0x@server:~$ /log/print follow where topics~"route"
12:01:14 route,info default-via-wan1 inactive
12:01:14 route,info default-via-wan2 active
12:01:16 route,info default-via-wan1 active
12:01:17 route,info default-via-wan2 inactive
Significado: estás flapeando. Eso no es “rápido”; es inestable.
Decisión: introduce histéresis: intervalos de comprobación más largos, múltiples fallos antes de cambiar y failback retrasado.
Tarea 15: Revisa carga de CPU durante eventos de failover (la crypto VPN puede ser el cuello de botella)
cr0x@server:~$ /system/resource/print
uptime: 3d4h22m
version: 7.16.1 (stable)
cpu-load: 84
free-memory: 214.3MiB
total-memory: 512.0MiB
Significado: CPU alta durante rekey o reconstrucción de túnel puede retrasar la convergencia y hacer que las comprobaciones de salud fallen.
Decisión: reduce la carga criptográfica (elección de algoritmos), reduce el churn de túneles o mejora hardware. “Pero es solo una oficina” no es un plan de capacidad.
Tarea 16: Verifica MTU/MSS clamp si ves fallos específicos de aplicaciones
cr0x@server:~$ /ip/firewall/mangle/print where comment~"MSS"
Flags: X - disabled, I - invalid, D - dynamic
# CHAIN ACTION PROTOCOL TCP-FLAGS NEW-MSS COMMENT
0 forward change-mss tcp syn 1360 clamp-mss-for-vpn
Significado: existe clamp MSS. Si no tienes esto y ejecutas túneles sobre PPPoE o MTUs mixtos, puedes tener “VPN arriba, aplicación abajo.”
Decisión: si descargas grandes se estancan o un SaaS específico falla solo sobre VPN, prueba PMTUD y considera MSS clamp en el camino correcto.
Guion de diagnóstico rápido
Cuando el VPN “no hace failover” (o hace failover contra un muro), necesitas un orden de triage repetible.
Esto está optimizado para velocidad y señal, no para elegancia.
Primero: determina si tienes un problema de enlace, de enrutamiento o de estado
- Enlace: interfaz abajo, flapping, problemas de negociación, pérdida de paquetes.
- Enrutamiento: ruta equivocada activa, tabla/regla de enrutamiento equivocada, objetivo recursivo aún alcanzable por el WAN incorrecto.
- Estado: conntrack fijando, handshake IPsec/WireGuard obsoleto, mapeo NAT atascado.
Segundo: mide los WAN por separado, no “Internet” en general
- Pinga un objetivo público a través de la tabla de enrutamiento de WAN1.
- Pinga un objetivo público a través de la tabla de enrutamiento de WAN2.
- Escucha tráfico hacia el peer VPN para confirmar la interfaz de egreso real.
Tercero: verifica el plano de control del túnel antes que el plano de datos
Para IPsec, revisa peers activos, SAs y logs por fallos de rekey. Para WireGuard, revisa last handshake.
Si el túnel no está establecido, depurar rutas a subredes es movimiento inútil.
Cuarto: confirma el orden de NAT y firewall
El orden NAT equivocado es un clásico: “permito no-NAT al VPN” pero masquerade coincide primero.
Lee siempre las reglas de arriba a abajo con la misma sospecha cínica que reservas para notas de lanzamiento del proveedor.
Quinto: borra solo el estado que bloquea la convergencia
Elimina entradas conntrack para el peer. Rebota el túnel si es necesario. Evita reiniciar el router a menos que ya te hayas quedado sin ideas y credibilidad.
Errores comunes: síntomas → causa raíz → solución
1) Síntoma: el VPN queda “arriba” pero el tráfico se cae tras el failover
Causa raíz: enrutamiento asimétrico o conntrack obsoleto. Los paquetes de control del túnel pueden seguir funcionando, pero los flujos de datos quedan fijados a un egress muerto.
Solución: aplica enrutamiento por políticas para el tráfico del peer; limpia conntrack del peer tras el failover; asegura que las reglas NAT coincidan con la interfaz de salida correcta.
2) Síntoma: el VPN se reestablece, pero solo funcionan algunas subredes
Causa raíz: rutas solapadas, política IPsec demasiado amplia o rutas faltantes en el sitio remoto tras cambios de camino.
Solución: ajusta selectores/políticas; verifica rutas en ambos extremos; evita políticas 0/0 salvo que realmente quieras túnel completo.
3) Síntoma: el failover nunca se dispara durante la “caída del ISP”
Causa raíz: estás haciendo ping al gateway del ISP, que sigue respondiendo mientras el upstream está muerto.
Solución: usa rutas por defecto recursivas vía objetivos públicos, o comprobaciones con scripts que prueben más allá del gateway.
4) Síntoma: el failover se dispara constantemente (flapping)
Causa raíz: comprobación de salud demasiado sensible; objetivo poco fiable; WAN con pérdida intermitente; o picos de CPU que retrasan respuestas.
Solución: añade histéresis (múltiples fallos/éxitos), elige objetivos estables, arregla el enlace físico y vigila la CPU durante churn.
5) Síntoma: tras el retorno a WAN1, el VPN no vuelve sin intervención manual
Causa raíz: el lado remoto aún espera la IP de origen antigua; mapeos NAT atascados; peer IPsec limitado a una dirección; timers DPD muy lentos.
Solución: configura peers duales o identidad dinámica cuando sea posible; reduce tiempos DPD con cuidado; limpia estado en ambos extremos durante pruebas.
6) Síntoma: Internet funciona, pero la negociación del VPN falla solo en WAN2
Causa raíz: WAN2 está detrás de CGNAT o bloquea UDP/500/4500; o la MTU difiere suficientemente para romper fragmentación.
Solución: prueba alcanzabilidad de puertos UDP; prefiere WireGuard sobre IPsec en entornos NAT problemáticos; aplica MSS clamp; considera cambiar de proveedor si bloquean VPN.
7) Síntoma: los usuarios se quejan “Teams se corta justo cuando ocurre el failover”
Causa raíz: eso es normal. Los flujos en tiempo real no sobreviven al cambio de camino sin resiliencia a nivel de sesión.
Solución: acepta que el failover rompe sesiones en vivo; enfócate en tiempo de recuperación y estabilidad; comunica el comportamiento esperado.
8) Síntoma: conexiones salientes aleatorias fallan cuando ambas rutas WAN están activas
Causa raíz: ECMP accidental sin retorno simétrico; desajuste NAT/conntrack.
Solución: mantiene una ruta por defecto activa a menos que implementes PCC/load balancing con NAT coincidente; no “multi-patheés” por accidente.
Tres microhistorias corporativas desde el campo
Microhistoria 1: El incidente causado por una suposición equivocada
Una firma mediana añadió un segundo circuito de fibra tras un corte memorable donde alguien intentó compartir un VPN de oficina vía hotspot de móvil.
La directiva fue simple: “failover automático”. El administrador de red puso dos rutas por defecto con distintas distancias y activó comprobaciones de gateway ping.
Parecía limpio. También se basaba en una suposición equivocada: “Si el gateway hace ping, Internet está bien.”
Un mes después, ISP A tuvo un problema de enrutamiento upstream. El gateway siguió siendo accesible, ARP estaba bien y los pings al gateway eran perfectos.
Mientras tanto, cualquier cosa más allá del borde del ISP fue blackholed de forma intermitente. El MikroTik se negó a conmutar porque su objetivo de comprobación seguía en verde.
Los usuarios vivieron un desastre en cámara lenta: timeouts de DNS, inicios de sesión SaaS fallando, túneles VPN “arriba” pero inutilizables.
El administrador intentó “forzar” el failover desactivando la ruta manualmente. El tráfico se movió a ISP B y se estabilizó de inmediato.
Luego, en cuanto reactivaron la ruta WAN1, el router la prefirió otra vez (distance=1) y el dolor regresó. Entraron tickets con síntomas contradictorios.
La solución no fue heroica. Pasaron a rutas por defecto recursivas con comprobaciones de alcanzabilidad pública y añadieron histéresis para que el failback no ocurriera tras un ping bueno.
La lección no fue técnica. Fue operativa: tu objetivo de monitorización define tu realidad, incluso cuando la realidad discrepa.
Microhistoria 2: La optimización que salió mal
Otra empresa quería “cero downtime” entre ISPs. Alguien leyó sobre balanceo de carga y decidió ser listo:
activaron balanceo por conexión entre ambos WANs mientras también corrían IPsec site-to-site hacia un datacenter.
La meta era usar ambos uplinks y “obtener más ancho de banda gratis”.
Lo que obtuvieron fue una tarjeta de bingo de helpdesk. Transferencias de archivos empezaban rápidas y luego se estancaban.
Algunas aplicaciones web funcionaban, otras fallaban aleatoriamente en autenticación. El VPN renegociaba múltiples veces por hora.
Los gráficos de monitorización parecían vivos, que es lo más cruel que puede hacer un gráfico.
El problema no era que el load balancing sea malvado. Era que no diseñaron para caminos simétricos.
Parte del tráfico hacia el peer VPN salía por WAN1, los paquetes de retorno llegaban por WAN2, conntrack los rechazaba y el plano de datos del túnel se volvió una moneda al aire.
El NAT lo empeoró: flujos saliendo por WAN2 a veces se masqueradeaban como WAN1 porque las reglas eran muy genéricas y estaban mal ordenadas.
El rollback fue básicamente una confesión: volvieron a una ruta por defecto activa, fijaron el tráfico VPN a una tabla dedicada y dejaron de intentar ser más listos que el networking stateful.
La empresa quedó satisfecha con estabilidad y algo más lenta.
Microhistoria 3: La práctica aburrida pero correcta que salvó el día
Una organización financiera tenía dos ISPs y un VPN site-to-site clave hacia una plataforma contable hospedada.
Tenían un proceso de cambios agresivamente poco glamuroso: cualquier cambio de red exigía un paso de rollback escrito, una ventana de mantenimiento programada
y una simulación de failover al menos una vez por trimestre. Nadie lo amaba. Nadie lo ponía en su currículum.
Entonces una cuadrilla de construcción cortó una tolva. WAN1 cayó de forma contundente. WAN2 se mantuvo.
El MikroTik falló a WAN2 en un par de intervalos de comprobación, el VPN se reestableció y los usuarios vieron una desconexión breve y luego operaciones normales.
El helpdesk tuvo quizás un puñado de llamadas, mayormente gente preguntando si “Internet está raro”.
Lo que lo hizo funcionar no fue un diseño elegante. Fue la disciplina aburrida:
tablas de enrutamiento separadas para tráfico de control VPN, reglas NAT fijadas por interfaz de salida y un procedimiento probado que incluía limpiar conntrack del peer si hacía falta.
También enviaban logs fuera del router, para poder demostrar la línea de tiempo cuando los proveedores empezaron la danza usual de echarse la culpa.
Más tarde, en la revisión post-incidente, alguien preguntó por qué había ido tan bien.
La respuesta del admin fue básicamente: “Practicamos lo que decimos tener.” No es poesía, pero es cómo la producción sigue siendo aburrida.
Listas de verificación / plan paso a paso
Paso a paso: construir failover VPN dual-WAN en MikroTik (estable, no elegante)
-
Inventaria la realidad. Confirma si cada ISP te da una IP pública real, si alguno usa CGNAT y si bloquean UDP/500/4500.
Si WAN2 es CGNAT, planifica iniciación solo saliente o WireGuard con keepalives. - Nombra las interfaces y documenta. “ether1” no es documentación. Usa comentarios, listas de interfaces y nombres consistentes.
- Elige tu señal de failover. Prefiere rutas por defecto recursivas vía objetivos públicos, o comprobaciones con scripts que prueben alcance real.
-
Mantén simple la lógica de ruta por defecto. Una ruta por defecto activa, una en espera con mayor distancia.
Si quieres usar ambos enlaces, eso es un proyecto aparte con modos de fallo distintos. - Aísla el enrutamiento de peers VPN. Crea una tabla de enrutamiento para tráfico hacia peers VPN (y opcionalmente una por WAN) y añade reglas para las IPs destino de los peers.
- Haz el NAT determinista. Pon reglas no-NAT/accept para destinos VPN arriba de masquerade. Usa match por out-interface en reglas de masquerade.
- Valida el establecimiento del túnel en cada WAN de forma independiente. Desactiva temporalmente la ruta WAN1 y confirma que el túnel puede activarse en WAN2, y viceversa.
- Añade histéresis. Evita failback rápido. Requiere éxito sostenido antes de volver a WAN1.
- Define un procedimiento de reset de estado. Sabe qué entradas conntrack limpiar, cómo reiniciar el túnel y qué logs revisar.
- Prueba con una falla controlada. No arranques cables al azar. Deshabilita una ruta o interfaz en un momento planificado y observa logs/capturas.
- Observa problemas de MTU. Si las apps se comportan raro en VPN en un ISP, prueba MSS clamp y el comportamiento de PMTUD.
- Escríbelo. La configuración no se explica sola y no recordarás la intención dentro de seis meses.
Checklist operativo: antes de aplicar cambios en producción
- Tener un plan de acceso fuera de banda (consola LTE, manos remotas o al menos una persona local con laptop).
- Exportar la configuración actual y guardarla en un lugar seguro.
- Conocer los comandos de rollback y el orden para aplicarlos.
- Elegir una prueba que coincida con el negocio: consulta DNS, login ERP, transferencia de archivos, llamada VoIP—lo que falle primero.
- Decidir el tiempo de inactividad aceptable por evento de failover y comunicarlo.
Preguntas frecuentes
1) ¿Puede MikroTik hacer un failover de VPN “perfecto” sin perder sesiones?
Normalmente no. La mayoría de sesiones de aplicaciones se romperán cuando cambie la IP pública de egreso.
Puedes reducir el tiempo de inactividad y acelerar la reconexión, pero lo perfecto requiere resiliencia a nivel de aplicación o diseños más complejos (a menudo con el lado remoto involucrado).
2) ¿Debería usar “check-gateway=ping” en la ruta por defecto?
Solo si aceptas que detecta “mi gateway está vivo”, no “Internet funciona”.
Para oficinas, las rutas recursivas vía un objetivo público estable suelen ser un mejor disparador de failover.
3) ¿Es WireGuard más fácil que IPsec para failover?
Operativamente, sí. El modelo de handshake y el minimalismo de WireGuard tienden a hacer el comportamiento más sencillo de razonar.
Pero aún debes resolver determinismo de enrutamiento y NAT; WireGuard no te salva de un enrutamiento por políticas descuidado.
4) ¿Por qué el VPN aparece establecido pero los usuarios no alcanzan subredes remotas?
Porque el éxito del plano de control no garantiza el éxito del plano de datos. Culpables comunes: orden NAT equivocado, rutas faltantes, camino asimétrico o problemas de MTU.
La captura de paquetes hacia el peer y una búsqueda de ruta suelen revelar la verdad.
5) ¿Necesito dos túneles VPN (uno por ISP)?
Si la VPN es crítica para el negocio y puedes coordinar ambos extremos, dos túneles es el enfoque más robusto.
Para una oficina típica con tolerancia a reconexiones breves, un solo túnel que pueda reestablecerse por cualquier WAN suele ser suficiente.
6) ¿Qué pasa con balanceo de carga entre ambos WAN y failover de VPN?
Es factible, pero no tropieces con ello por accidente. Necesitas clasificación consistente por conexión, reglas NAT coincidentes y un plan para retorno simétrico.
Si no estás listo para probar durante días, mantén un WAN primario.
7) ¿Cómo evito el flapping entre ISPs?
Usa histéresis: múltiples fallos antes de cambiar y failback retrasado hasta probar estabilidad.
También elige objetivos de salud estables y arregla la pérdida de paquetes subyacente. Ningún script puede ganarle a una fibra mal empalmada.
8) ¿Cómo pruebo el failover de forma segura durante horario laboral?
No desconectes cables. Deshabilita brevemente la ruta por defecto primaria o baja su prioridad y observa logs y estado del túnel.
Limita el tiempo de la prueba, comunica la breve ventana de interrupción y ten un rollback listo.
9) ¿Por qué WAN2 falla aunque la navegación general funcione?
Los protocolos VPN son más exigentes que el tráfico web. WAN2 puede bloquear UDP/500/4500, estar detrás de CGNAT o tener una MTU menor que rompe encapsulación.
Prueba alcanzabilidad de protocolos y considera WireGuard si IPsec sufre en el camino del ISP.
Próximos pasos (lo aburrido que evita tickets)
Construye la arquitectura más simple que cumpla el requisito del negocio y luego hazla determinista:
enrutamiento explícito para peers VPN, reglas NAT que coincidan con el egreso elegido y comprobaciones de salud que midan la capa correcta.
Mantén el failover estable, no nervioso. Si quieres convergencia más rápida, invierte en detección mejor —no en más aleatoriedad.
Pasos prácticos que puedes hacer esta semana:
- Reemplaza pings a gateways por comprobaciones recursivas de alcanzabilidad hacia objetivos públicos.
- Aísla el enrutamiento de peers VPN en una tabla dedicada y verifica con captura de paquetes.
- Audit a el orden de reglas NAT y añade excepciones no-NAT para subredes VPN arriba.
- Realiza una prueba de failover controlada y registra: tiempo a detección, tiempo a reestablecer túnel y la aplicación rara que siempre se queja primero.
- Escribe un runbook de una página: qué revisar, qué limpiar y cómo revertir. Tu yo futuro te lo agradecerá con menos alertas.