IPsec IKEv2 entre oficinas en MikroTik: cómo estabilizarlo (y por qué fluctúa)

Qué es realmente el “flapping” (y qué no es)

Cuando la gente dice que un túnel IPsec “flapea”, suele referirse a una de tres cosas distintas:

• Agitación del SA IKE: el plano de control IKEv2 se vuelve a establecer continuamente. Verás negociaciones repetidas de “initiator” / “responder”, eliminaciones frecuentes o timeouts de DPD.
• Agitación del Child SA: IKE sigue arriba, pero los SAs ESP (datos) se rekeyan, eliminan o reemplazan con demasiada frecuencia, interrumpiendo flujos de larga duración.
• Agujeros negros de tráfico: el túnel está establecido, pero el tráfico no coincide con la política de forma intermitente, las rutas cambian, aparecen hits de NAT o el MTU rompe solo ciertas aplicaciones.

No los trates como el mismo problema. Tienen firmas diferentes, causas raíz distintas y arreglos distintos.
“El túnel está arriba” no es una métrica de éxito. “El tráfico de la empresa se comporta de forma aburrida” sí lo es.

Además: si tu enlace WAN cae, tu VPN cae. Eso no es “flapping”, es física. El truco es evitar que la VPN invente caídas sobre una WAN sana.

Datos e historia interesantes que puedes usar a las 2 a.m.

1. IKEv2 se diseñó para reducir la complejidad frente a IKEv1, especialmente en rekey y NAT traversal, pero las implementaciones aún difieren en comportamiento de borde.
2. NAT traversal es más antiguo que la carrera de muchos ingenieros: la encapsulación UDP para ESP (NAT‑T) se hizo común a principios de los 2000 porque los dispositivos NAT estropeaban IPsec.
3. DPD existe porque “inactivo” no significa “saludable”. Los middleboxes eliminan el estado silenciosamente; DPD es una forma controlada de descubrirlo antes que los usuarios.
4. PFS no es gratis: añade CPU durante el rekey. En routers pequeños, lifetimes agresivos pueden convertirse en cortes autoinfligidos.
5. UDP 500/4500 no es inherentemente poco fiable; es solo el protocolo más propenso a ser “optimizados” por firewalls stateful, CGNAT y equipos ISP.
6. Descubrimiento de Path MTU ha estado “casi funcionando” siempre. El filtrado de ICMP sigue rompiéndolo, y la encapsulación VPN amplía el radio de impacto.
7. RouterOS ha evolucionado IPsec significativamente a través de versiones principales; el comportamiento respecto a propuestas, identidades y offload hardware difiere por plataforma y release.
8. Las colisiones de rekey son clásicas: dos pares rekeyean simultáneamente, ambos creen que “ganaron” y el tráfico cae hasta que uno limpia. Los stacks modernos lo manejan mejor, pero no a la perfección.

Arquitectura de referencia estable para IKEv2 entre oficinas en MikroTik

Elige un modelo: basado en política o basado en ruta. No corras un híbrido por accidente.

MikroTik soporta IPsec basado en políticas (selectores en las políticas) y puede hacer diseños basados en rutas usando enfoques tipo VTI según la versión de RouterOS y las características.
Las historias de flapping que he visto suelen venir de “casi basado en políticas, pero añadimos una ruta aquí, y ahora la mitad de las subredes funcionan los martes.”

Para dos oficinas, basado en políticas puede ser suficiente si tienes subredes estables y pocos selectores. Se vuelve frágil cuando:
añades más subredes, haces hairpin traffic, tienes rangos solapados o introduces WANs múltiples.
En ese punto, prefiere un diseño basado en rutas cuando sea posible y mantén el enrutamiento explícito.

Identidad y direccionamiento: evita diseños de “lo que el ISP nos dé”

Si al menos un lado tiene IP pública dinámica, todavía puedes ser estable, pero debes ser deliberado:
usa identidades FQDN, emparejamiento estricto de pares y una configuración de responder limpia. Si puedes comprar IPs estáticas, hazlo. Es más barato que tu tiempo de inactividad.

Cripto y lifetimes: lo aburrido gana

La base estable que uso salvo que una política requiera otra cosa:

• IKE (Fase 1): AES-256, SHA-256, grupo DH 14+ (o grupos ECP si ambos lados los manejan bien)
• ESP (Fase 2): AES-256-GCM si se soporta de extremo a extremo; si no, AES-256 + SHA-256
• Tiempo de vida: no “lo más corto posible”. Apunta a valores sensatos (horas, no minutos), alineados en ambos extremos.
• PFS: actívalo si puedes permitir la CPU; si no, desactívalo y compensa con lifetimes IKE más largos y cripto IKE fuerte.

Tu túnel no debería rekeyear tan a menudo que el router pase el día negociando en vez de reenviar paquetes.

NAT y reglas de firewall: haz el plano de control aburrido

Permite UDP 500 y UDP 4500 entrantes, y permite ESP si no usas NAT‑T (la mayoría usa NAT‑T). Asegúrate de que tus reglas de NAT no traduzcan tráfico que debería estar protegido.
Un túnel estable suele morir porque una regla de NAT está “amablemente” haciendo masquerade de la subred de la oficina en el camino hacia el túnel.

MTU/MSS: trátalo como una dependencia de primera clase

La sobrecarga de encapsulación significa que tu MTU efectivo es menor. Si no lo planificas, obtienes fallos selectivos: la web funciona, las copias de archivos se arrastran, RDP tartamudea,
y alguien culpa “al ISP”. Casi siempre es MTU más ICMP bloqueado.

Por qué IKEv2 en MikroTik fluctúa: los modos reales de fallo

1) Timeouts de estado NAT y cambios de puerto (especialmente detrás de CGNAT)

IKEv2 sobre NAT‑T corre sobre UDP 4500. Muchos dispositivos NAT cierran el estado UDP agresivamente, especialmente cuando está “inactivo”.
Cuando el mapeo cambia, el par envía paquetes a un puerto muerto y obtienes fallos de DPD o SAs atascados.
Si estás detrás de CGNAT, esto empeora: el NAT no es tuyo ni lo puedes configurar.

Solución: asegura que los keepalives NAT estén habilitados y que DPD sea sensato. No pongas DPD en “modo martillo” a menos que disfrutes tormentas de renegociación autoinducidas.

2) Colisiones de rekey y lifetimes desalineados

Si ambos extremos rekeyean al mismo tiempo (o si los lifetimes no se alinean bien), puedes acabar con Child SAs siendo reemplazados de forma que interrumpen flujos.
El síntoma es “cada X minutos, las conexiones se reinician”, a menudo con una regularidad sospechosa.

Solución: alinea lifetimes, considera márgenes de rekey y evita lifetimes extremadamente cortos. Mide también la CPU durante el rekey: en MikroTiks pequeños importa.

3) Desajuste de propuestas que solo aparece en rekey

La negociación inicial puede tener éxito con un subconjunto compartido de algoritmos, pero el rekey puede seleccionar una orden diferente o golpear un caso límite. Entonces falla y retrocede,
o borra y renegocia. Esto parece inestabilidad aleatoria porque está basada en el tiempo.

Solución: establece explícitamente las propuestas en ambos extremos. No confíes en el “default”. Los valores por defecto cambian entre versiones de RouterOS y familias de hardware.

4) Problemas de MTU/fragmentación (mensajes IKE y plano de datos)

Los mensajes IKEv2 pueden ser grandes, especialmente con certificados, múltiples propuestas o vendor IDs.
Si la fragmentación UDP está bloqueada en algún punto, el handshake puede fallar de forma intermitente.
Luego el plano de datos tiene el clásico problema de “los paquetes grandes mueren” si PMTUD está roto.

Solución: mantén la configuración crypto ligera, permite fragmentación donde sea necesario y ajusta MSS en flujos TCP para evitar depender de PMTUD.

5) Deriva de rutas o selectores de política

Los túneles basados en políticas dependen de selectores. ¿Añades una subred nueva en un sitio y te olvidas de agregarla en el otro? El túnel aún se establece, pero el tráfico a esa subred falla.
Peor: si tienes políticas solapadas, el tráfico puede coincidir con la incorrecta y activar instalaciones de SA “inesperadas”.

Solución: mantiene los selectores simétricos, ordena las políticas intencionalmente y registra los drops en la cadena forward para ver qué se está bloqueando realmente.

6) Reglas de firewall que están casi correctas

“Permitimos UDP 500 y 4500.” Genial. ¿Permites established/related? ¿Permites tráfico de política IPsec en la cadena forward?
¿Pusiste una regla fasttrack delante de las excepciones IPsec?

RouterOS puede fasttrackear tráfico de formas que omiten el procesamiento de IPsec si no se exime. Eso puede crear agujeros negros que parecen flapping del túnel.

7) Capacidad/performance: el túnel es estable, el router no

Bajo presión de CPU, los keepalives y las sondas DPD se retrasan. Entonces los pares se declaran muertos y renegocian.
En papel el ancho de banda está bien; en realidad el router está ocupado cifrando, encolando y haciendo firewall/NAT sin offload.

Solución: mide CPU en picos, verifica soporte de aceleración hardware, simplifica reglas y deja de rekeyear cada pocos minutos.

Broma #1: IPsec no es inestable; simplemente es muy honesto sobre cada pequeña mentira que le cuenta tu red.

Guion de diagnóstico rápido (primero/segundo/tercero)

Cuando un túnel “flapea”, no empieces cambiando cripto. Empieza demostrando qué capa es inestable.
Aquí está el triage rápido que ahorra tiempo y evita supersticiones.

Primero: demuestra que la WAN es suficientemente estable para UDP 4500

• Revisa errores/descartes de interfaz, eventos link up/down.
• Comprueba si la IP pública cambia (IP dinámica, reconexiones PPPoE, conmutación LTE).
• Verifica pérdida de paquetes y jitter hacia la IP pública del par a lo largo del tiempo.

Segundo: demuestra la salud del plano de control IKE

• Observa la edad de IKE SA, eventos de rekey, timeouts de DPD.
• Busca repetidos “no proposal chosen”, “auth failed”, “peer not responding”.
• Confirma detección de NAT‑T y puertos consistentes.

Tercero: demuestra la corrección del plano de datos

• Verifica que las políticas/selectores coincidan con el tráfico real.
• Confirma que el enrutamiento envía las subredes correctas hacia IPsec.
• Valida MTU/MSS con pruebas de carga real (no confíes en pings por defecto).
• Busca interferencia de fasttrack/NAT.

Cuarto: solo entonces ajusta cripto y lifetimes

Si la WAN y las políticas están limpias, entonces afina propuestas, PFS, lifetimes y márgenes de rekey.
Hacer esto antes es la forma en que la gente acaba con configuraciones que “funcionan a veces”.

Tareas prácticas: comandos, salidas y decisiones (12+)

Estas tareas están escritas como un runbook de on-call: ejecuta un comando, interpreta la salida y toma una decisión.
Los comandos se muestran como si se ejecutaran desde un jump host Linux que puede SSH a ambos MikroTiks. Adapta los nombres de host.

Tarea 1: Confirma versión de RouterOS y plataforma (el comportamiento varía)

cr0x@server:~$ ssh admin@mtk-office-a '/system/resource/print'
                   uptime: 2w1d3h
                  version: 7.15.3 (stable)
               build-time: 2025-08-01 10:12:45
              free-memory: 312.4MiB
             total-memory: 512.0MiB
                      cpu: ARM
                cpu-count: 4
            cpu-frequency: 1400MHz
                 cpu-load: 18%

Qué significa: la versión mayor/menor de RouterOS afecta detalles del stack IPsec y los valores por defecto. CPU y memoria indican si estás operando al límite.

Decisión: Si las versiones difieren mucho entre sitios, alinéalas. Si la carga de CPU sube durante las caídas, tienes un problema de capacidad, no de cripto.

Tarea 2: Comprueba estabilidad del enlace y cambios de IP WAN

cr0x@server:~$ ssh admin@mtk-office-a '/ip/address/print where interface~"wan"'
 #   ADDRESS            NETWORK         INTERFACE
 0   203.0.113.10/24    203.0.113.0     wan1

cr0x@server:~$ ssh admin@mtk-office-a '/log/print where message~"link down|link up|pppoe"'
 0 time=2025-12-27 10:12:01 topics=interface,info message=wan1 link down
 1 time=2025-12-27 10:12:05 topics=interface,info message=wan1 link up (speed 1G, full duplex)

Qué significa: si la interfaz WAN está rebotando, IPsec es daño colateral. El túnel no “flapea”; el ISP lo hace.

Decisión: Arregla el enlace físico/ISP primero. Si la IP cambia con frecuencia, prefiere identidad FQDN o un flujo DDNS y verifica el emparejamiento de peers.

Tarea 3: Revisa peers de IPsec y si se usa NAT‑T

cr0x@server:~$ ssh admin@mtk-office-a '/ip/ipsec/peer/print detail'
 0 name="office-b" address=198.51.100.20/32 local-address=203.0.113.10
   exchange-mode=ike2 send-initial-contact=yes nat-traversal=yes
   dpd-interval=10s dpd-maximum-failures=3 profile=ike2-prof

Qué significa: NAT traversal habilitado suele ser correcto. El intervalo DPD y el número de fallos definen la rapidez con la que declaras al peer muerto.

Decisión: Si ves nat-traversal=no mientras un lado está detrás de NAT, arréglalo. Si DPD es demasiado agresivo para tu WAN, relájalo.

Tarea 4: Inspecciona SAs activas y busca tiempos de agitación

cr0x@server:~$ ssh admin@mtk-office-a '/ip/ipsec/active-peers/print detail'
 0 ike2=yes name="office-b" state=established
   local-address=203.0.113.10 remote-address=198.51.100.20
   side=initiator nat-traversal=yes
   uptime=00:43:12 last-dpd=00:00:07

cr0x@server:~$ ssh admin@mtk-office-a '/ip/ipsec/installed-sa/print detail'
 0 spi=0xC1A2B3C4 src-address=203.0.113.10 dst-address=198.51.100.20
   state=mature auth-algorithm=sha256 enc-algorithm=aes-256-gcm
   lifetime=00:58:21 expires-in=00:01:39

Qué significa: si los SAs expiran y se reinstalan constantemente, probablemente tienes lifetimes demasiado cortos o inestabilidad en rekey.

Decisión: Si los rekeys ocurren con más frecuencia que cada hora para un túnel oficina‑a‑oficina básico, revisa lifetimes y PFS.

Tarea 5: Habilita logging IPsec focalizado brevemente (luego apágalo)

cr0x@server:~$ ssh admin@mtk-office-a '/system/logging/add topics=ipsec,debug action=memory'
cr0x@server:~$ ssh admin@mtk-office-a '/log/print where topics~"ipsec"'
 0 time=2025-12-28 09:14:02 topics=ipsec,debug message=initiating IKE_SA to 198.51.100.20
 1 time=2025-12-28 09:14:02 topics=ipsec,debug message=IKE_SA established
 2 time=2025-12-28 09:15:33 topics=ipsec,debug message=DPD timeout, peer not responding
 3 time=2025-12-28 09:15:33 topics=ipsec,debug message=deleting IKE_SA

Qué significa: el log muestra causa en el plano de control: aquí son timeouts de DPD, no propuestas.

Decisión: Si hay timeouts de DPD mientras la WAN está estable, sospecha expiración de estado NAT, filtrado upstream o retraso por CPU.

Tarea 6: Valida que el firewall permita IKEv2 y NAT‑T hacia el router

cr0x@server:~$ ssh admin@mtk-office-a '/ip/firewall/filter/print where chain="input"'
 0 chain=input action=accept connection-state=established,related
 1 chain=input action=accept protocol=udp dst-port=500,4500
 2 chain=input action=drop in-interface=wan1

Qué significa: UDP 500/4500 permitidos antes del drop. Bien. Si esas reglas están después de un drop, has construido un pisapapeles con forma de VPN.

Decisión: Asegura que las reglas accept estén por encima de los drops. Si usas address‑lists, restringe a IPs de peers por higiene.

Tarea 7: Detecta si fasttrack interfiere con IPsec

cr0x@server:~$ ssh admin@mtk-office-a '/ip/firewall/filter/print where action~"fasttrack"'
 0 chain=forward action=fasttrack-connection connection-state=established,related

Qué significa: una regla genérica de fasttrack puede omitir el procesamiento de IPsec a menos que eximas los flujos IPsec.

Decisión: Añade una excepción para tráfico ipsec-policy=in,ipsec y ipsec-policy=out,ipsec antes de fasttrack, o desactiva fasttrack si puedes permitírtelo.

Tarea 8: Confirma que las reglas NAT no traducen subredes protegidas

cr0x@server:~$ ssh admin@mtk-office-a '/ip/firewall/nat/print'
 0 chain=srcnat action=masquerade out-interface=wan1
 1 chain=srcnat action=accept ipsec-policy=out,ipsec
 2 chain=srcnat action=masquerade src-address=10.10.0.0/16 out-interface=wan1

Qué significa: la regla 1 es la crítica “no NATear IPsec” excepción. Sin ella, parte del tráfico puede ser NATeado y dejar de coincidir con los selectores.

Decisión: Asegura que la regla accept exista y esté por encima de las masquerade. Si ves masquerade afectando tráfico VPN, corrige el orden.

Tarea 9: Verifica que los selectores de política coincidan en ambas direcciones

cr0x@server:~$ ssh admin@mtk-office-a '/ip/ipsec/policy/print detail'
 0 src-address=10.10.10.0/24 dst-address=10.20.10.0/24 action=encrypt
   tunnel=yes peer=office-b proposal=esp-prof

cr0x@server:~$ ssh admin@mtk-office-b '/ip/ipsec/policy/print detail'
 0 src-address=10.20.10.0/24 dst-address=10.10.10.0/24 action=encrypt
   tunnel=yes peer=office-a proposal=esp-prof

Qué significa: la simetría importa. Si Office B tiene 10.10.0.0/16 mientras Office A usa 10.10.10.0/24, tendrás accesibilidad parcial y instalaciones de SA confusas.

Decisión: Normaliza selectores. Si necesitas muchas subredes, considera consolidar selectores cuidadosamente o pasa a un enfoque basado en rutas para reducir la proliferación de políticas.

Tarea 10: Observa drops y coincidencias de política usando contadores

cr0x@server:~$ ssh admin@mtk-office-a '/ip/firewall/filter/print stats where chain="forward"'
 0 chain=forward action=accept ipsec-policy=in,ipsec packet-count=124992 byte-count=98311234
 1 chain=forward action=accept ipsec-policy=out,ipsec packet-count=121887 byte-count=96733122
 2 chain=forward action=drop in-interface=wan1 packet-count=22 byte-count=1452

Qué significa: el tráfico de política IPsec se acepta y cuenta. Si los contadores se quedan en cero mientras los usuarios se quejan, el tráfico no está coincidiendo con la política (enrutamiento, NAT o selectores).

Decisión: Si los contadores accept de IPsec no incrementan, deja de tocar IPsec y arregla enrutamiento/NAT/direcciones.

Tarea 11: Comprobación de MTU con un ping “no fragmentar”

cr0x@server:~$ ping -M do -s 1472 10.20.10.10 -c 3
PING 10.20.10.10 (10.20.10.10) 1472(1500) bytes of data.
ping: local error: message too long, mtu=1460
ping: local error: message too long, mtu=1460
ping: local error: message too long, mtu=1460

--- 10.20.10.10 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss

Qué significa: el Path MTU es menor de lo esperado. Sobre VPN eso es normal, pero debes acomodarlo para TCP.

Decisión: Limita TCP MSS en el MikroTik para tráfico que entra al túnel, o ajusta MTUs de interfaz si controlas el camino.

Tarea 12: Revisa fragmentación IKE o problemas de handshakes grandes (conducido por síntomas)

cr0x@server:~$ ssh admin@mtk-office-a '/log/print where message~"fragment|too large|invalid"'
 0 time=2025-12-28 08:01:19 topics=ipsec,debug message=received packet too large, dropping
 1 time=2025-12-28 08:01:19 topics=ipsec,debug message=peer not responding

Qué significa: algunas redes descartan UDP fragmentado. Los mensajes IKE grandes pueden morir en tránsito, causando fallos intermitentes de negociación.

Decisión: Reduce la lista de propuestas, considera usar PSK frente a cadenas de certificados cuando sea apropiado y asegúrate de que dispositivos upstream no bloqueen fragmentos.

Tarea 13: Mide CPU y presión de interrupciones durante renegociación

cr0x@server:~$ ssh admin@mtk-office-a '/tool/profile'
name                    cpu        memory
firewall                22%        0 B
ipsec                   31%        0 B
ethernet                6%         0 B
management              2%         0 B

Qué significa: que IPsec consuma un tercio de la CPU no es automáticamente malo, pero si sube al 90% en picos, DPD y temporizadores de rekey se vuelven imprecisos.

Decisión: Si IPsec es un gran consumidor de CPU y ves flapping, aumenta lifetimes, reduce el coste de PFS, activa offload hardware si está soportado o mejora el hardware.

Tarea 14: Verifica enrutamiento hacia subredes remotas (no asumas)

cr0x@server:~$ ssh admin@mtk-office-a '/ip/route/print where dst-address=10.20.10.0/24'
 0 dst-address=10.20.10.0/24 gateway=ipsec policy distance=1 scope=30 target-scope=10

Qué significa: dependiendo del diseño, puedes ver enrutamiento impulsado por políticas sin rutas explícitas, o puedes depender de rutas. Lo que no puedes es fiarte de las sensaciones.

Decisión: Si las rutas apuntan a otra parte (ruta por defecto, gateway equivocado, VRF incorrecto), el túnel puede estar “arriba” mientras el tráfico sale a Internet y muere.

Tarea 15: Captura paquetes para demostrar si pierdes IKE o ESP

cr0x@server:~$ ssh admin@mtk-office-a '/tool/sniffer/quick interface=wan1 ip-protocol=udp port=500,4500'
 0  2025-12-28 09:21:11 203.0.113.10:4500 -> 198.51.100.20:4500 UDP  92
 1  2025-12-28 09:21:21 203.0.113.10:4500 -> 198.51.100.20:4500 UDP  92
 2  2025-12-28 09:21:31 203.0.113.10:4500 -> 198.51.100.20:4500 UDP  92

Qué significa: ves paquetes keepalive/DPD salientes, pero ¿ves respuestas? Si no, es filtrado upstream, estado NAT o el extremo remoto está muerto.

Decisión: Si salen pero no entran, deja de reconfigurar el router local. Demuestra el camino o que el remoto está dropeando.

Tres microhistorias corporativas desde el campo

Microhistoria 1: El incidente causado por una suposición equivocada

Una empresa mediana tenía dos oficinas y un túnel IKEv2 “sencillo”. Funcionó durante meses, luego empezó a caerse todas las tardes. El helpdesk culpó al ISP,
el equipo de red culpó a IPsec y el equipo de seguridad culpó a “alguien que cambió cripto”.

La suposición equivocada fue sutil: asumieron que “sin tráfico” significa “sin problemas”. En realidad, el túnel estaba mayormente inactivo hasta que el personal empezó a usar una nueva SaaS
que provocaba ráfagas periódicas más ventanas largas de inactividad. El NAT del ISP tenía un timeout UDP agresivo. El mapeo NAT para UDP 4500 expiraba durante inactividad,
luego el siguiente paquete salía con un nuevo puerto de origen. El otro extremo seguía enviando al mapeo antiguo hasta que DPD declaró al peer muerto.

Los logs lo decían en repetición: DPD timeout, delete IKE SA, renegotiate. Pero todos lo miraban solo cuando ya “estaba arriba” otra vez, veían SAs establecidas
y seguían adelante.

La solución fue aburrida: habilitar keepalives NAT regulares (y dejar de deshabilitarlos “para reducir ruido”), aflojar DPD para tolerar jitter breve y fijar lifetimes para que el rekey no
ocurriera justo cuando la oficina hacía su backup diario. El túnel volvió a ser invisible, que es el mejor tipo de VPN.

Microhistoria 2: La optimización que salió mal

Otra empresa tenía un firewall RouterOS con fasttrack habilitado. Estaban orgullosos. El throughput era excelente, la CPU baja, los gráficos bonitos.
Luego migraron de IKEv1 a IKEv2 y de repente tuvieron tráfico unidireccional intermitente. El túnel nunca “caía”, pero las transferencias de archivos colgaban y VoIP sonaba robótico 10–30 segundos al azar.

La “optimización” era fasttrack en conexiones established/related sin excepción para IPsec. Algunos flujos eran fasttrackeados de formas que omitían las comprobaciones de política
necesarias para cifrado/descifrado. En efecto, algún tráfico tomó la vía rápida hasta chocar contra un muro.

Intentaron arreglarlo cambiando cripto. Luego cambiando lifetimes. Luego cambiando hardware. Clásico. Nada de eso ayuda si el firewall está saltándose la parte donde decide que
el tráfico pertenece a IPsec.

La solución fue quirúrgica: insertar una regla accept para ipsec-policy=in,ipsec y ipsec-policy=out,ipsec por delante de fasttrack, y asegurar que las reglas NAT tuvieran
una “accept if ipsec-policy=out,ipsec” en lo alto. El throughput bajó ligeramente. La estabilidad mejoró drásticamente. Todos fingieron que así fue el plan desde el principio.

Microhistoria 3: La práctica aburrida pero correcta que salvó el día

Una compañía distribuida tenía tres oficinas pequeñas y un sitio “hub”. Cada oficina usaba un ISP distinto, y una oficina estaba en LTE como respaldo.
Problemas de VPN eran esperados; nadie esperaba que fueran rápidamente diagnosticables.

La práctica aburrida: tenían un runbook estandarizado y nombres consistentes. Los peers se nombraban por sitio, las propuestas eran idénticas en routers, los lifetimes alineados,
y registraban eventos IPsec en un syslog central con suficiente debug útil sin ser un cañón de fuego.

Un día, una oficina empezó a fluctuar tras un mantenimiento del ISP. El ingeniero on‑call no adivinó. Revisó logs WAN, no encontró cambios de enlace. Revisó logs IPsec,
vio timeouts DPD con un patrón nuevo. Hizo un sniffer y confirmó UDP 4500 saliendo sin respuestas entrantes. La conclusión fue inmediata: problema en el camino upstream, no en la configuración MikroTik.

Escalaron con evidencia: timestamps, resúmenes de captura de paquetes y claro “enviamos, no recibimos”. El ISP arregló una regla stateful rota en su borde. La VPN se estabilizó.
Nadie tuvo que revertir firmware a medianoche. Nadie tuvo que “simplemente reiniciarlo”. Lo aburrido ganó.

Errores comunes: síntoma → causa raíz → solución

1) El túnel renegocia cada pocos minutos como un reloj

• Síntoma: caídas predecibles cada 5–30 minutos; logs muestran ciclos de rekey/delete.
• Causa raíz: lifetimes muy cortos, colisiones de rekey o picos de CPU durante rekey.
• Solución: aumenta IKE/ESP lifetimes, alínea ambos lados, reduce coste de PFS si es necesario y asegura que los conjuntos de propuestas sean explícitos e idénticos.

2) “Peer not responding” pero la WAN parece bien

• Síntoma: timeouts DPD; túnel se restablece rápido; usuarios ven cortes breves.
• Causa raíz: expiración de mapeo NAT o upstream que dropea UDP 4500 intermitentemente.
• Solución: habilita keepalives, ajusta DPD a la realidad de la WAN, evita doble-NAT cuando sea posible y demuestra pérdida de paquetes con sniffer.

3) El túnel está arriba, pero algunas subredes funcionan y otras no

• Síntoma: una VLAN llega a la oficina remota; otra no; existen SAs.
• Causa raíz: desajuste de selectores, políticas faltantes o NAT que traduce una subred.
• Solución: haz selectores simétricos; añade políticas faltantes; añade la regla ipsec-policy=out,ipsec en NAT por encima de masquerade.

4) La web funciona, las transferencias grandes fallan, RDP es inestable

• Síntoma: paquetes pequeños pasan; paquetes grandes se quedan; timeouts intermitentes.
• Causa raíz: fallo MTU/PMTUD por sobrecarga de encapsulación y ICMP fragmentation-needed bloqueado.
• Solución: limita TCP MSS en tráfico VPN; permite tipos ICMP necesarios; prueba con pings DF y tamaños reales de carga.

5) Funciona hasta que activas fasttrack, luego falla “al azar”

• Síntoma: el túnel permanece establecido, pero el plano de datos se vuelve intermitente, a menudo unidireccional.
• Causa raíz: fasttrack omite el procesamiento necesario para tráfico de política IPsec.
• Solución: añade reglas accept explícitas para tráfico de política IPsec antes de fasttrack o desactiva fasttrack.

6) La negociación falla solo después de una actualización de firmware

• Síntoma: “no proposal chosen”, “auth failed” o nuevo comportamiento respecto a lifetimes.
• Causa raíz: cambiaron defaults, el orden de algoritmos cambió o se eliminaron cifrados obsoletos.
• Solución: fija propuestas y perfiles explícitamente; mantiene versiones alineadas; prueba comportamiento de rekey antes de desplegar en producción.

7) Solo pasa tráfico en una dirección

• Síntoma: Office A alcanza B; B no alcanza A, o viceversa.
• Causa raíz: selectores asimétricos, asimetría de enrutamiento o reglas forward faltantes que acepten políticas IPsec.
• Solución: asegúrate que ambas direcciones tengan políticas coincidentes; verifica rutas; añade reglas forward accept para ipsec-policy in/out.

Broma #2: La forma más rápida de “arreglar” una VPN es declararla “funciona según diseño” e ir a almorzar—hasta que el CFO intente imprimir.

Listas de verificación / plan paso a paso para estabilidad

Paso 1: Estandariza y documenta el contrato del túnel

• Lista subredes locales/remotas, incluyendo crecimiento futuro.
• Elige basado en políticas o basado en rutas intencionalmente.
• Elige suite cripto y lifetimes; escríbelos.
• Nombra objetos de forma consistente: peers, identidades, propuestas, políticas.

Paso 2: Haz resistente el plano de control

• Permite UDP 500 y 4500 al router desde el peer.
• Activa NAT‑T salvo que puedas garantizar sin NAT en el camino.
• Configura DPD para detectar fallos reales sin entrar en pánico por jitter.
• Alinea lifetimes IKE y ESP; evita lifetimes “mínimos”.

Paso 3: Haz explícito el plano de datos

• Añade reglas en la cadena forward para aceptar ipsec-policy=in,ipsec y ipsec-policy=out,ipsec.
• Añade exención NAT: chain=srcnat action=accept ipsec-policy=out,ipsec encima de cualquier masquerade.
• Verifica que los selectores de política coincidan exactamente en ambos lados.
• Prefiere rangos RFC1918 no solapados entre sitios.

Paso 4: Arregla MTU/MSS antes de que los usuarios lo descubran por sí mismos

• Prueba PMTU con pings DF.
• Limita TCP MSS para tráfico que entra al túnel (valor común: 1360–1400; mide, no adivines).
• Permite ICMP fragmentation‑needed si tu postura de seguridad lo permite.

Paso 5: Monitoriza lo que importa

• Registra eventos IPsec (no full debug para siempre) y guarda timestamps.
• Grafica CPU, descartes/errores de interfaz y conteo de SAs IPsec a lo largo del tiempo.
• Alerta por re‑establecimientos frecuentes, no solo por “túnel abajo”.

Paso 6: Disciplina operativa para cambios

• Actualiza RouterOS en ventana controlada; mantén ambos extremos compatibles.
• Cambia una variable a la vez: DPD, lifetimes, propuestas, reglas NAT.
• Después de cualquier cambio, fuerza un rekey y valida tráfico para todas las subredes.

Un principio de fiabilidad que vale la pena robar

Requisito para cita (idea parafraseada): John Ousterhout argumentó que la complejidad es enemiga de la fiabilidad; los sistemas más simples fallan de formas menos sorprendentes.

Preguntas frecuentes

1) ¿Debo usar IKEv2 o IKEv1 en MikroTik para site-to-site?

Usa IKEv2 salvo que tengas un peer legacy que force IKEv1. IKEv2 en general se comporta mejor con NAT traversal y lógica de rekey.
La estabilidad depende más de tu camino de red y disciplina de configuración que de la versión en sí.

2) ¿Qué ajustes DPD debo usar para evitar flapping?

Empieza conservador: intervalo DPD alrededor de 10–30 segundos y fallos máximos alrededor de 3–5, luego ajusta según comportamiento de la WAN.
Si lo pones muy agresivo en un enlace con jitter, le estás pidiendo al router que rompa la relación por demoras menores.

3) Mi túnel está establecido pero el tráfico no pasa. ¿Dónde miro primero?

Revisa exenciones NAT y reglas forward del firewall para tráfico de política IPsec. Luego revisa que los selectores/políticas coincidan en ambos lados.
Después de eso, verifica enrutamiento y subredes solapadas.

4) ¿Necesito permitir ESP (protocolo 50) en el firewall?

Si usas NAT‑T (UDP 4500), ESP se encapsula en UDP y normalmente solo necesitas UDP 500/4500.
Si NAT‑T está deshabilitado y no hay NAT en el camino, entonces sí, ESP debe permitirse.

5) ¿Cómo sé si MTU es mi problema?

Si los pings pequeños funcionan pero las transferencias grandes se detienen, sospecha MTU. Demúestralo con pings DF y ajusta TCP MSS.
También comprueba si ICMP fragmentation‑needed está bloqueado en algún punto entre sitios.

6) ¿Debo habilitar PFS?

Si tienes holgura de CPU y requisitos de cumplimiento/seguridad, actívalo. Si tu MikroTik es pequeño y ya está ocupado,
PFS más lifetimes cortos puede causar tormentas de rekey. La seguridad es una propiedad del sistema; la estabilidad también importa.

7) ¿Por qué fluctúa más durante horas pico?

Las horas pico correlacionan con carga de CPU, presión de colas y congestión WAN. Si los temporizadores IPsec (DPD, rekey) se retrasan, los pares declaran fallo.
Comprueba /tool/profile, descartes de interfaz y si tu router está haciendo demasiado (NAT, firewall, colas) junto con cifrado.

8) ¿Puede fasttrack quedar habilitado con IPsec?

A veces, pero debes añadir excepciones para que el tráfico de política IPsec no sea fasttrackeado de forma que omita el procesamiento.
Si no puedes razonar sobre el orden de reglas bajo estrés, desactiva fasttrack y recupera rendimiento con mejor hardware.

9) ¿Es “send-initial-contact=yes” bueno o malo?

Usualmente es bueno para limpiar SAs obsoletos en el responder cuando el iniciador se reconecta (especialmente tras cambio de IP).
En escenarios multi‑peer o HA puede borrar SAs que no querías tocar. Úsalo cuando entiendas quién puede conectarse con esa identidad.

10) ¿Cuál es la forma más simple de reducir caídas relacionadas con rekey?

Alinea lifetimes, mantiene el conjunto de propuestas pequeño y explícito y no rekeyees con demasiada frecuencia. Luego confirma holgura de CPU durante rekey.
El rekey debe ser un no‑evento, no un simulacro de caída.

Conclusión: siguientes pasos que realmente reducen las fluctuaciones

IKEv2 estable entre oficinas no es magia. Es una cadena de verdades aburridas:
la WAN debe ser lo suficientemente estable, el NAT debe mantener estado, las reglas de firewall/NAT deben respetar IPsec, los selectores deben coincidir y el MTU debe gestionarse proactivamente.
Si aciertas eso, el cripto pasa a ser una elección de política en lugar de una ruleta de troubleshooting.

Pasos prácticos:

1. Ejecuta el guion de diagnóstico rápido y clasifica el problema: WAN, plano de control o plano de datos.
2. Fija propuestas y lifetimes explícitamente en ambos extremos; deja de depender de valores por defecto.
3. Añade y verifica reglas de exención NAT y aceptaciones forward de IPsec; comprueba contadores.
4. Prueba MTU con pings DF y limita MSS para que las aplicaciones dejen de descubrir MTU a la manera dura.
5. Mide CPU en pico y durante rekey; si estás al límite, ajusta lifetimes o mejora hardware.
6. Guarda logs el tiempo suficiente para capturar flaps, y usa nombres consistentes para que tu yo futuro pueda analizar la situación rápido.

Tu objetivo no es un túnel que pueda conectarse. Tu objetivo es un túnel que nadie recuerde. Esa es la definición de producción‑grado de “estable”.