MikroTik: devolver el tráfico por la misma puerta de enlace por la que llegó

Hay un router MikroTik, en él está configurado port forwarding — redirigimos algún puerto a un servidor interno. Todo funciona mientras el router usa un único gateway para salir a Internet. Pero en cuanto aparece un segundo — WAN de reserva, túnel VPN con rutas BGP, da igual — y comienza lo clásico: la conexión se establece por WAN1, la solicitud llega al servidor y la respuesta sale por WAN2. El cliente ve un RST o simplemente espera hasta el timeout, porque el paquete llegó desde una IP distinta.

Cliente → [WAN1] → MikroTik --dstnat--> 192.168.1.10
                                              ↓
Cliente ← [WAN2] ← MikroTik <-----------  respuesta

Esto es enrutamiento asimétrico. Se puede arreglar de forma limpia — sin tocar la tabla main y sin romper el resto del tráfico.

Por qué RouterOS hace esto

Cuando el servidor envía un paquete de respuesta, RouterOS mira la tabla de enrutamiento main y elige la mejor ruta hacia la dirección de destino. Si en main hay varias rutas por defecto o BGP ha introducido sus prefijos allí — el router legítimamente enviará el paquete por otra interfaz. No está obligado a «recordar» por dónde llegó la solicitud original. Este es el comportamiento normal de un router L3, que en este caso nos perjudica.

Solución: tabla de enrutamiento separada para el tráfico dstnat

La idea es simple: marcamos solo aquellas conexiones que entraron por WAN1 y pasaron por dstnat, y para ellas forzamos el uso de una tabla separada con una única ruta — de vuelta por WAN1. Todo lo demás sigue igual.

Paso 1 — crear una tabla de enrutamiento separada

/routing table add name=via-wan1 fib

Paso 2 — añadir en ella la ruta por defecto a través de WAN1

/ip route add \
    dst-address=0.0.0.0/0 \
    gateway=<WAN1_GATEWAY> \
    routing-table=via-wan1

Paso 3 — marcar las conexiones necesarias con mangle

Aquí hay dos reglas, y es importante entender por qué ambas.

La primera regla se dispara en la entrada por WAN1 y solo en paquetes que ya pasaron por dstnat. Marca toda la conexión:

/ip firewall mangle add \
    chain=prerouting \
    in-interface=<WAN1_INTERFACE> \
    connection-nat-state=dstnat \
    action=mark-connection \
    new-connection-mark=from-wan1-dstnat \
    passthrough=yes \
    comment="Marcar conexiones dstnat desde WAN1"

La segunda regla funciona ya sin atarse a la interfaz — captura todos los paquetes de la conexión marcada, incluidas las respuestas que vienen por LAN, y les pone routing-mark:

/ip firewall mangle add \
    chain=prerouting \
    connection-mark=from-wan1-dstnat \
    action=mark-routing \
    new-routing-mark=via-wan1 \
    passthrough=no \
    comment="Enrutar respuestas dstnat de vuelta vía WAN1"

Paso 4 — vincular routing-mark con la tabla

/routing rule add \
    routing-mark=via-wan1 \
    action=lookup \
    table=via-wan1 \
    comment="respuestas dstnat vía WAN1"

Qué ocurre internamente

Entrada del paquete: el paquete entrante sigue la ruta habitual: WAN1 → prerouting → dstnat cambia la dst-address a 192.168.1.10 → mangle #1 pone connection-mark=from-wan1-dstnat → mangle #2 pone routing-mark=via-wan1 → el paquete va al servidor.

Paquete de respuesta: la respuesta vuelve desde el servidor por el interfaz LAN. En prerouting el connection tracking ve que la conexión está marcada como from-wan1-dstnat, mangle #2 se dispara de nuevo y pone routing-mark=via-wan1. Después la routing rule dirige el paquete a la tabla via-wan1, donde la única ruta es a través de WAN1. En postrouting, srcnat/masquerade sustituye la IP pública de WAN1. El cliente recibe la respuesta desde la misma IP con la que estableció la conexión.

Un matiz que a menudo se pasa por alto: connection-nat-state=dstnat se verifica ya después de aplicar las reglas NAT. Para cuando esa coincidencia se evalúa, RouterOS ya sabe que la conexión pasó por dstnat. Por eso la primera regla mangle filtra inmediatamente por esos dos parámetros — interfaz y nat-state.

A tener en cuenta

Fasttrack. Si tienes fasttrack configurado (connection-state=established,related), puede saltarse mangle. No es un problema teórico — en configuraciones típicas fasttrack está activado por defecto. Asegúrate de que la regla mark-routing con passthrough=no esté en la cola antes de fasttrack, de lo contrario las conexiones establecidas pasarán de largo.

Varios interfaces externos. El esquema escala bien: para WAN2 creas la tabla via-wan2, la ruta por defecto por el segundo gateway y un par análogo de reglas mangle. Cada interfaz vive en su propia tabla y no interfieren entre sí.

BGP. Justo en entornos BGP este problema se nota más — BGP puede sobreescribir las rutas por defecto y la tabla main se vuelve impredecible respecto a la selección de interfaz. La tabla aislada via-wan1 no se ve afectada por eso.

Comprobación

Vemos que las conexiones realmente reciben la marca adecuada:

/ip firewall connection print where connection-mark=from-wan1-dstnat

Comprobamos las routing rules:

/routing rule print

Comprobamos la ruta en la tabla aislada:

/ip route print where routing-table=via-wan1

Si las respuestas siguen saliendo por el lugar equivocado — lo primero que hay que mirar es el orden de las reglas en mangle (/ip firewall mangle print). Lo más probable es que fasttrack esté antes de la regla necesaria.

Resumen

Cuatro comandos, sin cambios en main, el resto del tráfico no se ve afectado.