MikroTik VPN: Conjunto de reglas limpio y auditable para túneles divididos

Principios: cómo fallan los túneles divididos en la práctica

El túnel dividido no es “parte del tráfico va por la VPN y el resto sale directo”. Esa es la versión del folleto. La versión real es: estás construyendo dos dominios de enrutamiento superpuestos en el mismo cliente y luego esperas que DNS, MTU, NAT y el estado del firewall coincidan en qué significa “dentro”.

En MikroTik, tu éxito depende de si puedes responder estas preguntas rápidamente, con evidencia:

• ¿Qué paquetes deben entrar en el túnel?
• ¿Dónde decides eso (tabla de enrutamiento, mangle, política IPsec, AllowedIPs de WireGuard)?
• ¿Los paquetes de retorno toman la misma ruta de vuelta (simetría) y lo reconoce conntrack?
• ¿Estás aplicando NAT solo a lo que debe NATearse y no más?
• ¿Puedes probar lo anterior a partir de diffs de configuración y contadores?

Qué significa “limpio” en RouterOS

Limpio no significa “pocas reglas”. Limpio es predecible y auditable. Quiero un conjunto de reglas donde:

• Cada regla tiene un comentario, y el comentario explica la intención (no “vpn rule 3”).
• Marks y tablas usan nombres consistentes: rt-vpn, rm-vpn, addr-vpn-dsts.
• Todas las decisiones de túnel dividido ocurren en un lugar obvio.
• El NAT es explícito y con alcance. Si debes ocultar direcciones, lo haces para un conjunto definido de flujos.
• El deny por defecto sigue siendo deny por defecto.

Las dos formas en que el túnel dividido se vuelve “accidentalmente túnel completo”

Deriva de rutas es la principal: alguien añade una ruta amplia (como 0.0.0.0/0) en la tabla equivocada o empuja AllowedIPs demasiado amplios, y ahora todo se enruta hacia la sede. Los usuarios se quejan de latencia; la dirección dice “la VPN está lenta”; tú lo llamas “un bug de política de enrutamiento con un problema de control de cambios”.

Deriva de DNS es la otra: separas el enrutamiento pero no separas correctamente la resolución de nombres. El cliente resuelve nombres internos por DNS público (falla), o resuelve nombres públicos por DNS interno (funciona pero filtra políticas internas hacia la ruta de Internet). Ambos llevan a “funciona en mi portátil” porque tu portátil tiene respuestas en caché de la semana pasada.

Una verdad confiable: es más fácil mantener correcto el túnel dividido cuando el túnel es estrecho. Enruta solo los prefijos privados que realmente necesitas. Si un proveedor dice “envía 0/0”, eso no es un requisito técnico; es una estrategia de soporte.

Broma #1: El túnel dividido es como dejar que tu gato elija qué puertas están abiertas. Elegirá la que te haga arrepentirte.

Hechos y contexto interesantes (para que dejes de repetir la historia)

1. El enrutamiento por políticas precede la marca “SD-WAN” por décadas. Los routers empresariales tempranos usaban route maps y múltiples tablas mucho antes de que fuera un producto por suscripción.
2. El túnel dividido de VPN fue ampliamente desaconsejado a principios de los 2000 porque clientes comprometidos podían interconectar redes corporativas con internet; los controles modernos en endpoints lo hicieron menos tabú.
3. El modelo “basado en políticas” de IPsec moldeó los hábitos de muchos administradores: “los selectores de tráfico deciden qué se encripta.” WireGuard cambió el modelo mental con AllowedIPs actuando como ruta y ACL a la vez.
4. NAT e IPsec históricamente no se llevaron bien; NAT-T (encapsulado UDP) se volvió común para sobrevivir al NAT generalizado en internet.
5. El connection tracking se convirtió en el gobernador silencioso del comportamiento del firewall cuando el filtrado stateful reemplazó a las ACLs sin estado en equipos SMB. Cuando conntrack miente, todo miente.
6. El split-horizon DNS es más antiguo que la mayoría de las plataformas en la nube. No es un truco nuevo; simplemente seguimos olvidando diseñarlo.
7. Los problemas de MTU son tan antiguos como el tunneling: la encapsulación roba bytes de la carga útil, y “funciona con ping” no prueba nada sobre tráfico real.
8. MikroTik popularizó “funciones de grado carrier a precios de hobby”, lo que significa que tu entorno “pequeño” puede tener complejidad de nivel ISP—sin control de cambios de nivel ISP.

Conclusión: tu diseño de túnel dividido debería asumir que la gente lo cambiará después bajo presión. Optimiza para la supervivencia, no para la sofisticación.

Una arquitectura de referencia limpia (modelo mental de RouterOS)

Nos centraremos en un escenario simple pero realista para producción:

• Router MikroTik en una sucursal o en una oficina doméstica.
• LAN: 192.168.88.0/24 en bridge.
• WAN: ether1 con acceso a Internet.
• VPN: interfaz WireGuard wg0 hacia un hub (sede o nube).
• Redes remotas protegidas: 10.10.0.0/16 y 10.20.30.0/24.
• Objetivo de túnel dividido: solo esas redes remotas deben ir por la VPN; todo lo demás sale localmente.

Puntos de decisión: dónde se desvía el tráfico

En RouterOS, tienes múltiples “palancas”. No las muevas todas a la vez a menos que disfrutes de postmortems.

• Selección de tabla de enrutamiento (policy routing de RouterOS v7 con routing rules y tablas múltiples).
• Marks con mangle (routing-mark) que alimentan búsqueda en tablas alternas.
• WireGuard AllowedIPs (controla lo que el peer aceptará y qué rutas puedes instalar).
• Políticas IPsec (los selectores determinan qué se encripta).
• Reglas NAT (pueden “arreglar” cosas ocultando errores; no confíes en eso).

Mi preferencia para túnel dividido auditable en MikroTik RouterOS v7:

• Usar una tabla de enrutamiento dedicada (p. ej., rt-vpn).
• Usar una regla mangle (o routing rule) para seleccionar esa tabla para un conjunto claramente definido de destinos.
• Mantener WireGuard AllowedIPs alineados con esos destinos, pero no usarlo como único control de política.
• Minimizar el NAT; preferir prefijos privados enrutados de extremo a extremo cuando puedas.

Qué debes registrar y contar

Auditar no es una casilla de cumplimiento; es una característica de velocidad. Quieres contadores y logs que respondan:

• ¿Estamos coincidiendo con la lista de “destinos VPN”?
• ¿Estamos descartando entradas inesperadas desde el túnel?
• ¿El NAT se activa cuando no debería?
• ¿Se está usando la ruta por defecto para el tráfico de Internet como se pretende?

Eso significa: listas de direcciones, comentarios en reglas y logging temporal ocasional que elimines tras la validación. “Registrar todo” permanentemente es cómo te haces tu propio ataque de denegación de servicio.

El conjunto de reglas limpio y auditable (WireGuard + enrutamiento por políticas)

Este es un patrón de referencia. Ajusta nombres de interfaces y subredes. El punto es la estructura: separar responsabilidades, etiquetar la intención y mantener la decisión de túnel dividido en un solo lugar.

1) Define listas de direcciones: tu contrato de túnel dividido

Comienza con una lista de direcciones que enumere lo que debe ir por la VPN. Esto se convierte en tu contrato con el negocio: “estas redes son internas”. Todo lo demás es externo.

Usa un pequeño número de listas:

• addr-vpn-dsts: prefijos de destino que deben enrutar vía VPN.
• addr-lan: prefijos LAN locales (opcional, pero útil).
• addr-mgmt: fuentes de gestión permitidas para acceder a servicios del router.

2) Crea una tabla de enrutamiento dedicada y rutas

RouterOS v7 introdujo tablas de enrutamiento de primera clase. Úsalas. Mantiene la configuración legible y reduce “marcas mágicas” flotando.

En rt-vpn, añade rutas para las redes protegidas con gateway apuntando a la interfaz WireGuard (o al endpoint del peer si haces algo más sofisticado). No añadas una ruta por defecto a menos que estés intencionalmente haciendo túnel completo.

3) Enrutamiento por políticas: desvía solo lo que deba desviarse

Puedes hacerlo con mangle mark-routing o con /routing rule. Ambos son legítimos. Me gustan las /routing rule por legibilidad cuando es posible, pero mangle sigue siendo la herramienta universal cuando necesitas coincidir más atributos.

Elección clave de diseño: hacer la coincidencia por lista de direcciones de destino. Esto dificulta expandir el alcance accidentalmente mediante una coincidencia basada en puertos más adelante.

4) NAT: solo si es necesario y solo para los flujos relevantes

Si el lado remoto puede enrutar de vuelta a tu LAN, no hagas NAT. El enrutamiento es más limpio, depurable y conserva significados de logs en el extremo remoto.

Si debes NATEAR porque el remoto no puede añadir rutas o hay subredes solapadas, entonces NAT solo LAN→VPN-dsts. No hagas masquerade de todo el tráfico saliendo por wg0 a menos que quieras que el extremo remoto vea a cada usuario como “el router”.

5) Firewall: lista de permitidos explícita para el túnel

En la cadena input, trata el router como un servidor: permite solo los servicios que necesitas desde las fuentes que confías. En forward, permite established/related, descarta invalid, luego permite LAN→VPN destinations, LAN→internet y permite VPN→LAN solo si es necesario (a menudo no lo es).

Separa reglas para “tráfico de túnel” y “tráfico de internet”. Cuando depures, le agradecerás al tú del pasado.

6) DNS: el túnel dividido es medio enrutamiento, medio nombres

Decide dónde resuelven nombres internos. Opciones:

• Los clientes usan servidores DNS internos accesibles por la VPN para zonas específicas (lo mejor).
• El router hace reenvío condicional (funciona, pero añade una pieza móvil).
• Los clientes usan DNS público y aceptas que los nombres internos no se resuelvan (normalmente inaceptable).

Sea lo que sea, documentalo como parte del contrato de túnel dividido. De lo contrario tu “incidente de red” es en realidad “desajuste de expectativas de DNS”.

Un esqueleto de configuración concreto (conceptual, no pegado)

No voy a pegar mil líneas de export porque los entornos de producción no son demos para copiar y pegar. La meta es el patrón:

• La lista de direcciones define destinos protegidos.
• La tabla de enrutamiento contiene solo esas rutas.
• Una regla de enrutamiento o marca mangle selecciona esa tabla solo para esos destinos.
• El NAT está acotado a LAN→destinos protegidos si es necesario.
• El firewall es explícito sobre flujos permitidos y registra solo lo inesperado.

Broma #2: NAT es como cinta adhesiva—imprescindible cuando la necesitas, alarmante cuando se convierte en arquitectura.

Notas para túneles divididos con IPsec/IKEv2

WireGuard es lo bastante simple como para que la mayoría de los errores de túnel dividido sean autoinfligidos. IPsec añade más partes móviles: lifetimes de fase 1/2, selectores, propuestas, NAT-T y el clásico “está arriba pero no pasa nada”.

IPsec basado en políticas vs basado en rutas en MikroTik

En IPsec basado en políticas, los selectores de política (subredes src/dst) deciden qué se encripta. Si tu túnel dividido requiere solo unos pocos destinos, eso puede ser limpio—hasta que alguien añade una política más amplia “temporalmente” y se olvida de quitarla.

IPsec basado en rutas (vía VTI) suele alinearse mejor con el diseño de “tabla de enrutamiento dedicada” porque puedes enrutar prefijos hacia la interfaz VTI como cualquier otra interfaz, y luego aplicar enrutamiento por políticas de forma similar.

El truco de auditoría con IPsec

Haz que los selectores coincidan con tu contrato de lista de direcciones. Si tu lista dice 10.10.0.0/16 y 10.20.30.0/24, tus políticas IPsec deberían reflejar eso. Si no lo hacen, no estás haciendo túnel dividido; estás haciendo “lo que tocó el último ingeniero”.

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

Estas tareas asumen que tienes acceso CLI al MikroTik (vía SSH) y una máquina Linux en la LAN para tráfico de prueba. Los comandos son realistas; las salidas son representativas. La idea es: ejecuta un comando, interprétalo, toma una decisión.

Task 1: Confirmar que la interfaz WireGuard está activa y tiene la dirección esperada

cr0x@server:~$ ssh admin@192.168.88.1 /interface/wireguard/print
Flags: X - disabled, R - running 
 0  R name="wg0" mtu=1420 listen-port=13231 private-key="<hidden>" public-key="<hidden>"

Qué significa: R indica que la interfaz está en ejecución. El MTU importa; 1420 es un valor seguro común para WireGuard sobre WAN típicas.

Decisión: Si no está en ejecución, arregla eso antes de perseguir el enrutamiento. Si el MTU es 1500 y los usuarios reportan “algunos sitios funcionan, descargas grandes fallan”, marca el MTU como sospechoso.

Task 2: Verificar el handshake del peer y los contadores de bytes

cr0x@server:~$ ssh admin@192.168.88.1 /interface/wireguard/peers/print detail
 0 interface=wg0 public-key="<hubkey>" endpoint-address=203.0.113.10 endpoint-port=51820 
   allowed-address=10.10.0.0/16,10.20.30.0/24 persistent-keepalive=25s
   last-handshake=1m12s rx=128.4MiB tx=64.2MiB

Qué significa: Un handshake reciente más rx/tx crecientes indica que el túnel está vivo.

Decisión: Si el handshake está vacío o antiguo, arregla la alcanzabilidad (WAN, NAT, firewall en ambos lados) antes de tocar reglas de división.

Task 3: Listar listas de direcciones y confirmar el contrato de túnel dividido

cr0x@server:~$ ssh admin@192.168.88.1 /ip/firewall/address-list/print where list="addr-vpn-dsts"
Flags: X - disabled, D - dynamic 
 0   list=addr-vpn-dsts address=10.10.0.0/16 comment="HQ private networks"
 1   list=addr-vpn-dsts address=10.20.30.0/24 comment="Finance app subnet"

Qué significa: El router tiene un conjunto explícito de destinos para la ruta VPN.

Decisión: Si esta lista falta, está desactualizada o contiene 0.0.0.0/0, detente. No tienes túnel dividido; tienes sensaciones.

Task 4: Confirmar que existe la tabla de enrutamiento dedicada

cr0x@server:~$ ssh admin@192.168.88.1 /routing/table/print
Flags: D - dynamic, X - disabled 
 0 name="main" fib
 1 name="rt-vpn" fib

Qué significa: rt-vpn es una tabla FIB real.

Decisión: Si no la ves, créala. Si ves cinco tablas con nombres parecidos, tienes problemas de gobernanza, no un problema técnico.

Task 5: Revisar rutas dentro de la tabla de enrutamiento VPN

cr0x@server:~$ ssh admin@192.168.88.1 /ip/route/print where routing-table="rt-vpn"
Flags: D - dynamic, X - disabled, A - active, c - connect, s - static 
 0 A s dst-address=10.10.0.0/16 gateway=wg0 distance=1 scope=30 target-scope=10 comment="via WG to HQ"
 1 A s dst-address=10.20.30.0/24 gateway=wg0 distance=1 scope=30 target-scope=10 comment="via WG to finance"

Qué significa: La tabla VPN enruta solo las redes privadas esperadas y están activas.

Decisión: Si hay una ruta por defecto en rt-vpn, estás a una regla de enrutamiento de túnel completo. Elíminala salvo que lo quieras.

Task 6: Confirmar que existe la decisión de enrutamiento por políticas (routing rule)

cr0x@server:~$ ssh admin@192.168.88.1 /routing/rule/print detail
 0 action=lookup-only-in-table dst-address=10.10.0.0/16 table=rt-vpn comment="Split tunnel: HQ"
 1 action=lookup-only-in-table dst-address=10.20.30.0/24 table=rt-vpn comment="Split tunnel: Finance"

Qué significa: Solo esos prefijos de destino consultan rt-vpn. lookup-only-in-table evita la sustitución por main, lo que hace que las fallas sean ruidosas (bueno) en vez de raras (malo).

Decisión: Si las reglas usan lookup en lugar de lookup-only-in-table, podrías filtrar tráfico accidentalmente hacia WAN cuando la VPN esté caída. Elige deliberadamente.

Task 7: Inspeccionar reglas NAT y asegurar que tengan alcance

cr0x@server:~$ ssh admin@192.168.88.1 /ip/firewall/nat/print
Flags: X - disabled, I - invalid, D - dynamic 
 0   chain=srcnat action=masquerade out-interface=ether1 comment="WAN internet NAT"
 1   chain=srcnat action=masquerade out-interface=wg0 src-address=192.168.88.0/24 dst-address-list=addr-vpn-dsts comment="NAT only LAN to VPN dsts"

Qué significa: Hay un masquerade normal para WAN y un masquerade para VPN que solo se activa para LAN → destinos protegidos.

Decisión: Si ves un out-interface=wg0 masquerade genérico sin restricción de dst, probablemente estás ocultando errores de diseño y rompiendo pistas de auditoría en el extremo remoto.

Task 8: Revisar contadores en la cadena forward para flujos VPN

cr0x@server:~$ ssh admin@192.168.88.1 /ip/firewall/filter/print stats where chain="forward"
Flags: X - disabled, I - invalid, D - dynamic 
 0   chain=forward action=accept connection-state=established,related comment="Allow established/related" packets=784221 bytes=812.5MiB
 1   chain=forward action=drop connection-state=invalid comment="Drop invalid" packets=23 bytes=1904
 2   chain=forward action=accept in-interface=bridge dst-address-list=addr-vpn-dsts out-interface=wg0 comment="LAN to VPN destinations" packets=18214 bytes=21.6MiB
 3   chain=forward action=accept in-interface=bridge out-interface=ether1 comment="LAN to internet" packets=512001 bytes=601.2MiB
 4   chain=forward action=drop comment="Drop the rest" packets=411 bytes=32244

Qué significa: La regla de split para VPN está coincidiendo y pasando tráfico. Que “Drop the rest” sea pequeño es sano.

Decisión: Si el contador de la regla VPN se queda en cero mientras los usuarios se quejan, tu decisión de enrutamiento no está seleccionando la ruta esperada (o el DNS apunta a otro lado).

Task 9: Usar Torch para ver si el tráfico hacia una subred protegida sale por wg0

cr0x@server:~$ ssh admin@192.168.88.1 /tool/torch interface=wg0 src-address=192.168.88.50 dst-address=10.10.20.15
#   SRC-ADDRESS         DST-ADDRESS         PROTOCOL  PORT  TX      RX
0   192.168.88.50       10.10.20.15         tcp       443   1.2Mbps  3.8Mbps

Qué significa: Tienes tráfico en vivo que coincide con la expectativa de túnel dividido.

Decisión: Si el tráfico aparece en ether1 en su lugar, tus reglas/marks de enrutamiento están mal o el destino no está en tu lista de direcciones.

Task 10: Ejecutar una prueba de búsqueda de ruta para un destino (¿a dónde iría esto?)

cr0x@server:~$ ssh admin@192.168.88.1 /ip/route/check dst-address=10.10.20.15
 0 interface=wg0 gateway=wg0 distance=1 routing-table=rt-vpn

Qué significa: El router enviaría ese destino vía wg0 usando rt-vpn.

Decisión: Si reporta routing-table=main o interfaz ether1, la política de túnel dividido no se aplica para ese destino.

Task 11: Confirmar que conntrack no esté anclando flujos a la ruta equivocada

cr0x@server:~$ ssh admin@192.168.88.1 /ip/firewall/connection/print where dst-address~"10.10."
Flags: S - seen-reply, A - assured, C - confirmed 
 0 SAC protocol=tcp src-address=192.168.88.50:50122 dst-address=10.10.20.15:443 timeout=23h59m
     reply-src-address=10.10.20.15:443 reply-dst-address=192.168.88.50:50122

Qué significa: Existe una conexión activa. Conntrack es stateful; una vez establecido un flujo, cambiar la política de enrutamiento puede no moverlo.

Decisión: Si cambiaste la política de enrutamiento y el comportamiento no cambió, borra conexiones específicas o espera a que expiren. No reinicies como primera herramienta.

Task 12: Validar MTU con tamaño de carga real (desde un host Linux)

cr0x@server:~$ ping -M do -s 1372 10.10.20.15 -c 3
PING 10.10.20.15 (10.10.20.15) 1372(1400) bytes of data.
1380 bytes from 10.10.20.15: icmp_seq=1 ttl=61 time=42.1 ms
1380 bytes from 10.10.20.15: icmp_seq=2 ttl=61 time=41.7 ms
1380 bytes from 10.10.20.15: icmp_seq=3 ttl=61 time=41.9 ms

--- 10.10.20.15 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms

Qué significa: El Path MTU soporta al menos esta carga sin fragmentación. Para túneles, pruebas con DF porque la fragmentación puede ocultar problemas reales.

Decisión: Si esto falla pero pings pequeños funcionan, baja el MTU de WireGuard y/o investiga MTU del camino WAN y filtrado ICMP.

Task 13: Revisar saturación de CPU durante carga VPN (lado del router)

cr0x@server:~$ ssh admin@192.168.88.1 /system/resource/print
                   uptime: 12d3h2m
                  version: 7.13.5 (stable)
               free-memory: 412.3MiB
              total-memory: 512.0MiB
                       cpu: ARM
                 cpu-count: 4
             cpu-frequency: 1400MHz
                  cpu-load: 86%

Qué significa: CPU al 86% sugiere que puedes estar al límite, especialmente si los picos llegan al 100% y se forman colas.

Decisión: Si la CPU está alta durante las quejas, mide el throughput y considera límites de offload de hardware, interacciones con FastTrack o una actualización de hardware.

Task 14: Verificar que FastTrack no esté evitando decisiones de mangle/enrutamiento

cr0x@server:~$ ssh admin@192.168.88.1 /ip/firewall/filter/print where action~"fasttrack"
Flags: X - disabled, I - invalid, D - dynamic 
 5   chain=forward action=fasttrack-connection connection-state=established,related comment="FastTrack (may bypass policy routing)"

Qué significa: FastTrack puede saltarse partes del camino de firewall/mangle. Dependiendo de tu diseño, puede causar inconsistencias en el túnel dividido.

Decisión: Si dependes de marcas mangle para enrutamiento, a menudo necesitas deshabilitar FastTrack o crear excepciones para que el tráfico marcado para VPN no sea fasttracked.

Guion de diagnóstico rápido

No obtienes puntos extra por debug profundo cuando la caída es obvia. Aquí está el orden que encuentra el cuello de botella rápidamente.

Primero: demuestra si el túnel está vivo

• Revisa el timestamp del handshake de WireGuard y los contadores de bytes.
• Si falta el handshake: es alcanzabilidad del underlay, NAT o firewall. Detente allí.
• Si el handshake está bien: pasa a enrutamiento/política.

Segundo: demuestra la selección de enrutamiento para un destino que falla

• Elige una IP interna que sepas que es “interna”.
• Ejecuta route check / lookup y confirma que selecciona wg0 y rt-vpn.
• Si selecciona WAN: tu contrato de túnel dividido (lista de direcciones/reglas) está mal.

Tercero: demuestra que el firewall lo permite (y que el NAT no está haciendo algo inteligente)

• Mira los contadores en forward para la regla LAN→VPN.
• Mira los contadores NAT para la regla de masquerade VPN (si existe).
• Usa Torch en wg0 para confirmar que el tráfico realmente sale.

Cuarto: si enrutamiento/firewall parecen bien, prueba MTU y DNS

• MTU: ping con DF y carga realista; reduce MTU si hace falta.
• DNS: confirma que el cliente resuelve el nombre interno a la IP interna, no a una puerta pública.

Quinto: solo entonces persigue rendimiento (CPU, colas, pérdida)

• Revisa carga de CPU del router durante la ventana del incidente.
• Busca pérdida de paquetes en WAN o síntomas de bufferbloat.
• Confirma que no te fasttrackeaste a ti mismo fuera de la política de enrutamiento.

Nota operativa: Si el túnel está arriba pero “algunas apps” fallan, MTU y DNS ganan sobre “reglas de firewall místicas” nueve de cada diez veces.

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

1) Síntoma: La VPN está arriba, pero las subredes internas son inaccesibles

Causa raíz: Las rutas existen en la tabla main pero el enrutamiento por políticas envía tráfico a una tabla sin esas rutas (o viceversa).

Solución: Pon las rutas de subred protegidas en rt-vpn y asegura que las reglas de enrutamiento seleccionen rt-vpn para esos destinos. Valida con /ip/route/check.

2) Síntoma: Todo pasa por la VPN (túnel completo accidental)

Causa raíz: Ruta por defecto (0.0.0.0/0) presente en la tabla VPN, o AllowedIPs de WireGuard incluye 0.0.0.0/0 y instalaste una ruta amplia.

Solución: Elimina la ruta por defecto de rt-vpn. Reduce AllowedIPs a los prefijos protegidos. Audita tablas de rutas regularmente.

3) Síntoma: Algunas conexiones funcionan, otras cuelgan (especialmente transferencias grandes)

Causa raíz: Problemas de MTU/PMTUD; ICMP bloqueado; sobrecarga de encapsulación no tenida en cuenta.

Solución: Reduce MTU del túnel (p. ej., 1420 o menos) y prueba con pings DF. No adivines; mide.

4) Síntoma: Los nombres internos no se resuelven, pero hacer ping a las IPs internas funciona

Causa raíz: DNS no dividido; los clientes siguen usando DNS público para zonas internas.

Solución: Proporciona DNS interno accesible por la VPN o implementa reenvío condicional. Documenta las zonas y los resolvers esperados.

5) Síntoma: Tras un cambio, el comportamiento no coincide con las nuevas reglas por horas

Causa raíz: El connection tracking ancla flujos establecidos; los cambios aplican solo a conexiones nuevas.

Solución: Borra entradas conntrack específicas para los flujos afectados o espera. Evita “reiniciar para aplicar el enrutamiento”.

6) Síntoma: El tráfico VPN se filtra a internet cuando el túnel está caído

Causa raíz: El enrutamiento por políticas usa lookup con fallback a main; cuando falta la ruta VPN, cae a WAN.

Solución: Usa lookup-only-in-table para los destinos protegidos y opcionalmente añade drops en forward para LAN→destinos protegidos cuando la VPN esté caída, para fallar cerrado.

7) Síntoma: El enrutamiento por políticas funciona hasta que FastTrack se habilita

Causa raíz: FastTrack evita partes del procesamiento de firewall/mangle.

Solución: Deshabilita FastTrack, o exime conexiones relacionadas con la VPN de FastTrack (diseña con cuidado y valida contadores).

8) Síntoma: El extremo remoto ve a todos los clientes como la IP WG del MikroTik

Causa raíz: Mascarade demasiado amplio en wg0.

Solución: Elimina el NAT global; si el NAT es necesario, delimítalo a fuentes LAN y a la lista de destinos protegidos únicamente.

Tres mini-historias corporativas desde las trincheras

Incidente causado por una suposición errónea: “AllowedIPs es la política de enrutamiento”

Una empresa mediana desplegó WireGuard para soportar una nueva herramienta de analítica interna. Tenían un hub en un centro de datos y docenas de sitios pequeños con MikroTik. El objetivo era túnel dividido: solo 10.60.0.0/16 debía ir al centro de datos; todo lo demás debía salir directo.

El ingeniero que configuró las sucursales supuso que la lista allowed-address de WireGuard “forzaría” esas rutas y mantendría todo lo demás fuera. En algunos routers, además, había una ruta estática residuo hacia la antigua gateway IPsec del centro, que estaba silenciosamente en main. No era obvio porque el túnel seguía arriba y el router tenía múltiples formas de alcanzar los mismos prefijos.

Luego un soporte “servicial” del proveedor recomendó añadir 0.0.0.0/0 a AllowedIPs “por fiabilidad”. De la noche a la mañana, el tráfico de navegación de varias sucursales empezó a hacer hairpin hacia el centro de datos, saturando un enlace que se dimensionó para uso de apps internas, no para streaming y actualizaciones del SO.

La causa raíz no fue WireGuard; fue gobernanza y una suposición: que AllowedIPs es un sistema de políticas completo. No lo es. Es una pieza del rompecabezas y no reemplaza tablas de enrutamiento explícitas, intención de firewall y chequeos de auditoría.

La solución fue poco glamorosa: eliminar 0/0, definir una lista de direcciones como contrato, crear rt-vpn y añadir reglas de enrutamiento solo para los prefijos protegidos. También añadieron un ítem en la lista previa al cambio: “grep por rutas por defecto en tablas no-main”. Nadie celebró, pero los gráficos dejaron de gritar.

Optimización que salió mal: FastTrack por “rendimiento gratis”

Otra organización tenía un diseño sensato de túnel dividido pero empezó a alcanzar límites de CPU en routers ARM pequeños. Alguien notó que FastTrack podía reducir CPU al evitar partes del firewall para conexiones establecidas. Lo activaron globalmente en la cadena forward y vieron una mejora inmediata en pruebas de velocidad a Internet.

Dos semanas después llegaron tickets: el CRM accesible por VPN funcionaba unos minutos, luego las sesiones caían o se conectaban aleatoriamente desde una IP de origen equivocada. Los usuarios decían “la VPN es inestable”. Esa etiqueta es contagiosa; una vez existe, cualquier problema se convierte en culpa de la VPN.

El SRE de guardia comparó contadores y notó algo raro: la regla “LAN to VPN destinations” apenas aumentaba, pero Torch mostraba ráfagas ocasionales de tráfico del CRM por WAN. FastTrack había cortocircuitado efectivamente el camino de procesamiento que aplicaba la decisión de enrutamiento para algunas conexiones establecidas.

Lo arreglaron deshabilitando FastTrack para el tráfico que podría estar sujeto a policy routing. No globalmente, no de forma heroica—solo lo suficiente para preservar la corrección. La CPU subió, pero los routers dejaron de mentir. Más adelante resolvieron el problema de rendimiento correctamente con mejor elección de hardware y ajuste de colas en lugar de depender de la magia de evitar firewall.

Práctica aburrida pero correcta que salvó el día: verificación de cambios basada en contadores

En una firma de servicios financieros (esas con ventanas de cambio y gente que disfruta las hojas de cálculo), un equipo estandarizó sus configuraciones MikroTik. Cada regla de túnel dividido tenía un comentario y cada regla importante tenía contadores revisados durante la validación. También mantenían una simple instantánea “antes/después”: tablas de rutas, reglas de enrutamiento, reglas NAT y estadísticas de filtros.

Un viernes añadieron una nueva subred en la sede para un servicio de facturación: 10.77.40.0/24. Un ingeniero de red añadió la ruta en el hub y actualizó AllowedIPs de WireGuard. Se olvidó de actualizar la lista de direcciones de contrato y las reglas de enrutamiento en las sucursales.

El síntoma del lunes por la mañana fue limpio y estrecho: solo fallaba la app de facturación; todo lo demás funcionaba. Porque el equipo tenía la práctica de revisar contadores, el diagnóstico tomó minutos: los contadores de “LAN to VPN destinations” no incrementaban cuando los usuarios accedían a las IPs de facturación. Eso señaló inmediatamente “destino no en el contrato”, no “túnel caído”.

La solución fue una línea: añadir a la lista de direcciones y una ruta en rt-vpn. Sin tiempo de inactividad, sin reinicios de emergencia, sin señalar con el dedo. Su práctica “aburrida”—tratar contadores como señal de primera clase—convirtió un incidente en un cambio rutinario. Así se ve la madurez: menos eventos de adrenalina, más arreglos controlados.

Listas de verificación / plan paso a paso

Plan de construcción (greenfield o limpieza)

1. Define el contrato de túnel dividido: lista los prefijos remotos que deben ser accesibles por VPN, y solo esos.
2. Crea la lista de direcciones addr-vpn-dsts con esos prefijos y comentarios de propiedad/contexto.
3. Crea una tabla de enrutamiento dedicada rt-vpn.
4. Añade rutas en rt-vpn para cada prefijo protegido vía wg0 (o VTI para IPsec).
5. Añade reglas de enrutamiento para cada prefijo protegido: acción lookup-only-in-table → rt-vpn.
6. Cadena forward del firewall: accept established/related; drop invalid; allow explícito LAN→VPN-dsts; allow LAN→WAN; drop por defecto.
7. NAT: solo añade masquerade LAN→VPN-dsts si el extremo remoto no puede enrutar de vuelta limpiamente.
8. Decisión de DNS: asegura zonas internas resueltas por DNS interno accesible por VPN; documenta.
9. Deshabilita o delimita FastTrack si interfiere con policy routing.
10. Validación: prueba una IP por prefijo protegido; revisa contadores; confirma que no existen rutas por defecto no intencionadas.

Plan de cambio (añadir una nueva subred protegida)

1. Añade el prefijo a addr-vpn-dsts con un comentario que nombre al dueño de la app/servicio.
2. Añade una ruta en rt-vpn para ese prefijo.
3. Añade una regla de enrutamiento para ese prefijo apuntando a rt-vpn.
4. Confirma que WireGuard AllowedIPs incluye ese prefijo (y no es más amplio de lo necesario).
5. Prueba alcanzabilidad y luego observa contadores forward/NAT buscando incrementos esperados.
6. Si DNS está implicado (nuevo hostname interno), verifica el comportamiento del resolver desde un cliente.

Plan de rollback (porque eres adulto)

1. Deshabilita la(s) nueva(s) regla(s) de enrutamiento primero (revierte el direccionamiento rápidamente).
2. Elimina/deshabilita la(s) nueva(s) ruta(s) en rt-vpn.
3. Elimina la entrada de la lista de direcciones.
4. Borra entradas conntrack específicas si los clientes quedan atascados en rutas antiguas.
5. Captura el estado: tablas de rutas, estadísticas de reglas y info de handshake de peers para el postmortem.

Una idea para tener presente: “Todo falla, todo el tiempo; construye sistemas que lo esperen.” — Werner Vogels (idea parafraseada)

Preguntas frecuentes

1) ¿Debo implementar túnel dividido con marcas mangle o con routing rules?

Si las routing rules de RouterOS v7 cubren tus necesidades de coincidencia, úsalas: son más legibles y fáciles de auditar. Usa mangle cuando necesites coincidir atributos más complejos (puertos, DSCP, subredes de usuario), pero mantenlo mínimo.

2) ¿Dónde debería residir la “verdad” de los destinos del túnel dividido?

En un solo lugar: una lista de direcciones como contrato (o una lista de prefijos gestionada estrictamente). Luego las reglas de enrutamiento y AllowedIPs deberían alinearse con ella. Si duplicas la lógica en cinco sitios, eventualmente divergerás.

3) ¿Necesito NAT sobre la VPN?

No si puedes enrutar correctamente de extremo a extremo. NAT es para cuando no puedes: subredes solapadas, el extremo remoto no puede añadir rutas o restricciones del proveedor. Si debes NATear, delimítalo a LAN→destinos protegidos únicamente.

4) ¿Por qué funciona para IPs pero no para nombres?

Porque DNS no es parte del enrutamiento. Tu túnel puede ser perfecto y la resolución de nombres puede seguir estando mal. Resuelve zonas internas con DNS interno accesible por VPN o reenvío condicional.

5) ¿Por qué al activar FastTrack se rompió el túnel dividido?

FastTrack puede saltarse partes del procesamiento de firewall/mangle. Si tu decisión de enrutamiento depende de esos pasos, FastTrack puede hacer que los flujos se salten la ruta de política. O desactívalo o exime el tráfico afectado por la VPN.

6) ¿Cómo evito la “fuga a WAN” cuando la VPN está caída?

Usa lookup-only-in-table para destinos protegidos para que no haya fallback. Opcionalmente añade un drop en forward para LAN→destinos protegidos cuando la tabla VPN no tenga rutas activas, para fallar cerrado.

7) ¿Cómo depuro “algunos usuarios afectados, no todos”?

Revisa si los usuarios afectados están en una subred/VLAN distinta, usan resolvers DNS distintos o tienen DNS en caché. Luego revisa conntrack: sesiones existentes no seguirán nuevas decisiones de enrutamiento.

8) ¿Debería incluir 0.0.0.0/0 en AllowedIPs en sucursales?

Sólo si estás intencionalmente haciendo túnel completo y has diseñado para ello (capacidad, monitorización, política de seguridad). Si tu objetivo es túnel dividido, 0/0 es una trampa peligrosa con contrato de soporte.

9) ¿Cuál es la forma más limpia de auditar cambios a lo largo del tiempo?

Usa comentarios consistentes en las reglas, mantén el contrato de túnel dividido en listas de direcciones y revisa periódicamente: tablas de rutas, routing rules, reglas NAT y contadores de filtros. Las auditorías deben ser lo suficientemente rápidas como para que realmente las hagas.

Conclusión: pasos prácticos siguientes

Si tu configuración de túnel dividido en MikroTik se siente frágil, suele ser porque la política está dispersa: un poco en AllowedIPs, un poco en mangle, un poco en NAT “temporal” y un poco en la memoria de alguien. Devuélvelo a un contrato y una tabla.

Haz esto a continuación, en orden:

1. Crea (o limpia) addr-vpn-dsts para que contenga solo lo que debe ir por VPN.
2. Asegura que rt-vpn contenga solo rutas para esos prefijos—sin ruta por defecto salvo que la quieras.
3. Usa routing rules (lookup-only-in-table) para desviar solo esos destinos hacia rt-vpn.
4. Audita el NAT en wg0; elimina el masquerade global a menos que puedas justificárselo a tu yo futuro.
5. Ejecútalo el guion de diagnóstico rápido una vez mientras todo está sano y registra salidas y contadores esperados.

El túnel dividido puede ser limpio. Pero no lo será por accidente. Haz la política explícita, mantenla estrecha y deja que tus contadores te digan la verdad.