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

Hay un router MikroTik que mira a Internet a través de WAN1. Mientras el gateway sea uno — todo funciona. Cuando aparece un segundo WAN, un túnel VPN con rutas BGP o simplemente prefijos /32 específicos en la tabla main — empieza la clásica situación: la petición llegó por WAN1 pero la respuesta sale por WAN2 o por la VPN. El cliente ve RST o espera al timeout.

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

Esto es enrutamiento asimétrico. Se manifiesta en dos escenarios distintos, y cada uno requiere su propio enfoque.

Por qué RouterOS hace esto

Cuando necesita enviar un paquete, RouterOS mira la tabla de enrutamiento main y elige la mejor ruta al destino. Si en main hay varias rutas por defecto o BGP ha inyectado sus prefijos — el router legítimamente elegirá otra interfaz. No está obligado a “recordar” por dónde llegó la petición original. Este es el comportamiento normal de un router L3, que en este caso resulta problemático.

Dos escenarios

Escenario 1 — port forwarding (dstnat). La petición que entra por WAN1 se reenvía a un servidor interno mediante dstnat. La respuesta del servidor sale de nuevo por el router, y el router elige la interfaz según la tabla main. Si allí hay una ruta específica hacia la dirección origen — la respuesta no irá por donde llegó la petición.

Escenario 2 — conexiones directas al router. SSH, ICMP, API, Winbox — todo lo dirigido al propio router. La petición llegó por WAN1, el router genera la respuesta y vuelve a mirar en main. Si existe una ruta BGP hacia la dirección origen — la respuesta saldrá por la VPN o por WAN2.

Ambos escenarios se solucionan mediante una tabla de enrutamiento aislada, pero las reglas mangle para cada uno son distintas.

Preparación: tabla de enrutamiento separada

Creamos una tabla aislada con una única ruta — la ruta por defecto a través de WAN1:

/routing table add name=via-wan1 fib

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

Listo. No hace falta añadir nada más a esa tabla.

Reglas mangle

Se necesitan cuatro reglas. El orden es importante — deben ir exactamente en esta secuencia.

Regla 1 — marcar conexiones dstnat

Se dispara en entrada por WAN1 solo para paquetes que pasaron por dstnat. Pone una marca en 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"

Regla 2 — routing-mark para conexiones dstnat

Captura todos los paquetes de la conexión dstnat marcada, incluidos los de respuesta desde 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="Encaminar respuestas dstnat por WAN1"

Regla 3 — marcar conexiones directas al router

Mismas condiciones que la regla 1, pero para tráfico no-dstnat — SSH, ICMP y todo lo que vaya directamente al router:

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

Regla 4 — routing-mark para respuestas del router

Y aquí un detalle crítico: la cadena output, no prerouting.

/ip firewall mangle add \
    chain=output \
    connection-mark=from-wan1 \
    action=mark-routing \
    new-routing-mark=via-wan1 \
    passthrough=no \
    comment="Encaminar respuestas del router a conexiones desde WAN1 vía WAN1"

Por qué la regla 4 va en output y no en prerouting

Esta es la trampa principal. El primer instinto es poner mark-routing en prerouting por analogía con la regla 2. Parece lógico, pero rompe el router.

mark-routing en prerouting afecta la decisión de enrutamiento para el paquete actual. Para paquetes encaminados (forwarded) a través del router esto funciona correctamente. Pero para paquetes dirigidos al propio router, RouterOS también aplica ese routing-mark. El router busca su propia dirección (94.102.124.79) en la tabla via-wan1, encuentra solo la ruta por defecto 0.0.0.0/0 → <WAN1_GATEWAY> e intenta reenviar el paquete hacia el gateway en lugar de aceptarlo localmente. SSH cae instantáneamente, el router queda inaccesible.

# Cómo se ve el error:
# Paquete SSH entrante → mark-connection from-wan1 → mark-routing via-wan1 →
# RouterOS busca 94.102.124.79 en via-wan1 →
# encuentra solo 0.0.0.0/0 → gateway →
# lo reenvía al proveedor en lugar de procesarlo localmente →
# la conexión cae

La cadena output procesa únicamente los paquetes que el propio router genera en respuesta. Es ahí donde hay que poner el routing-mark — cuando el router ya ha aceptado el paquete y está formando la respuesta.

Cómo funciona internamente

Conexión dstnat (port forwarding):

1. El paquete entra por WAN1
2. Connection tracking ve que la conexión pasó por dstnat
3. Regla 1: connection-mark=from-wan1-dstnat
4. Regla 2: routing-mark=via-wan1
5. dstnat cambia la dst a 192.168.1.10
6. El servidor recibe la petición y forma la respuesta
7. La respuesta entra por la interfaz LAN → prerouting
8. Regla 2 se vuelve a disparar por la marca de la conexión → routing-mark=via-wan1
9. La respuesta sale por WAN1

Conexión directa al router (SSH, ping):

1. El paquete entra por WAN1
2. Regla 3: connection-mark=from-wan1
3. El router acepta el paquete (input chain)
4. El router genera la respuesta (output chain)
5. Regla 4: routing-mark=via-wan1
6. La respuesta sale por WAN1, evitando rutas específicas en main

Aspectos a tener en cuenta

Fasttrack. Si está configurado fasttrack (connection-state=established,related), éste elude mangle para conexiones establecidas. En configuraciones típicas fasttrack viene activado por defecto. La regla con passthrough=no debe ir antes de fasttrack, de lo contrario las conexiones tras el handshake pasarán de largo.

BGP. En entornos BGP el problema se nota aún más — BGP puede inyectar miles de prefijos específicos, y para cualquiera de ellos la tabla main elegirá la interfaz equivocada. La tabla aislada via-wan1 no reacciona a eso — ahí solo hay la ruta por defecto.

Varios WAN. El esquema es escalable: para WAN2 creas la tabla via-wan2, la ruta por defecto vía el segundo gateway, y cuatro reglas análogas. Las tablas no se interfieren entre sí.

Comprobación

Contadores de reglas en mangle — se puede ver que las reglas realmente se disparan:

/ip firewall mangle print stats

Conexiones activas con las marcas necesarias:

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

Ruta en la tabla aislada:

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

Resumen

La tabla de enrutamiento es la misma para ambos escenarios. Las reglas para dstnat y las conexiones directas funcionan de forma independiente, sin interferir entre sí ni afectar al resto del tráfico.