Port forwarding MikroTik: NAT sin abrir tu perímetro

Tarde o temprano toda red de misión crítica necesita exponer un servicio interno hacia afuera: el concentrador VPN de la sucursal, un servidor web en la DMZ, una API de facturación, las cámaras de un cliente ISP o el broker MQTT de una red IoT. El problema es que ese servicio vive con una IP privada detrás de tu router de borde, y el mundo solo ve tu IP pública. Ahí entra el port forwarding MikroTik: la técnica de NAT que traduce las conexiones que llegan a un puerto de tu IP pública y las redirige hacia un host interno. Suena trivial, pero en RouterOS mal aplicado deja puertos abiertos sin filtrar, rompe el acceso interno o simplemente no funciona porque tu ISP te entrega CGNAT. En este artículo desarmamos el flujo real de NAT en RouterOS, con los comandos exactos de /ip/firewall/nat y los criterios para hacerlo sin abrir un boquete en tu perímetro.

Qué es realmente el port forwarding en MikroTik

En RouterOS el port forwarding no es una función aparte: es una regla de destination NAT (DNAT) dentro del sistema de firewall. Toda la traducción de direcciones vive en /ip/firewall/nat y se organiza en dos cadenas (chains):

• dstnat: procesa los paquetes antes del ruteo. Es la cadena donde reescribes la dirección o el puerto de destino. Aquí vive el port forwarding.
• srcnat: procesa los paquetes después del ruteo, justo antes de salir. Es donde reescribes la dirección de origen (el clásico masquerade hacia la WAN).

Cuando una conexión entra por tu interfaz WAN dirigida a tu-ip-publica:443, la regla action=dst-nat en la cadena dstnat intercepta ese paquete y cambia su destino por la IP privada del servidor interno y, si corresponde, por otro puerto. El connection tracking de RouterOS recuerda esa traducción y se encarga de que las respuestas vuelvan correctamente al cliente, sin que tengas que crear una regla inversa.

NAT en RouterOS: dst-nat, masquerade, redirect y netmap

Antes de escribir la primera regla conviene tener claro qué hace cada action, porque elegir mal es la causa número uno de reglas que "no pegan". Estas son las acciones de NAT que realmente usarás:

action	Cadena	Qué hace	Uso típico
dst-nat	dstnat	Reemplaza dirección y/o puerto de destino por to-addresses / to-ports	Port forwarding hacia un host interno
redirect	dstnat	Redirige el destino al propio router en el puerto to-ports	Forzar DNS/proxy transparente al router
masquerade	srcnat	Reemplaza el origen por la IP que determine el ruteo hacia la salida	Salida a Internet por WAN dinámica
src-nat	srcnat	Reemplaza el origen por una IP fija (to-addresses)	Salida con IP pública fija
netmap	dstnat / srcnat	Mapeo estático 1:1 de un bloque de direcciones	Publicar rangos completos (NAT 1:1)

La distinción clave: masquerade es un caso especial de src-nat pensado para WAN con IP dinámica —toma automáticamente la IP de salida— mientras que dst-nat es lo que necesitas para el port forwarding propiamente tal. Si confundes las cadenas y pones tu regla de forwarding en srcnat, nunca se va a evaluar para el tráfico entrante.

Configurar port forwarding MikroTik paso a paso

Veamos el caso concreto: publicar hacia Internet un servidor web interno (192.168.88.10) que escucha HTTPS en el puerto 443, con la WAN agrupada en una interface-list llamada WAN. La regla mínima y correcta es:

/ip/firewall/nat
add chain=dstnat action=dst-nat \
    protocol=tcp dst-port=443 \
    in-interface-list=WAN \
    to-addresses=192.168.88.10 to-ports=443 \
    comment="DNAT HTTPS servidor web"

Desglosemos las propiedades, todas reales de RouterOS:

• protocol=tcp + dst-port=443: acotan la regla al tráfico exacto que quieres redirigir. Nunca dejes port forwarding sin protocol definido.
• in-interface-list=WAN: limita la regla a paquetes que entran por tu borde, no por la LAN. Es más robusto que dst-address=tu-ip-pública cuando la WAN es dinámica.
• to-addresses y to-ports: el destino real. Si el servidor escucha en el mismo puerto, repite el número; si escucha en otro (por ejemplo 8443 interno), ahí traduces el puerto.

Una recomendación de la propia documentación de MikroTik: arma y prueba todo con IPs locales primero y confirma que el servicio responde dentro de la red antes de exponerlo por la IP pública. Así aíslas si el problema es la regla de NAT o el servidor de destino.

Para verificar que la traducción está ocurriendo, revisa los contadores de la regla y el connection tracking: una conexión que pasó por port forwarding queda marcada con el flag dstnat=yes en /ip/firewall/connection. Si el contador de la regla no sube, el paquete ni siquiera está llegando a ella (típicamente por CGNAT o por una regla previa que lo captura).

Casos reales de ISP y empresa: múltiples servicios y NAT 1:1

En redes de producción rara vez publicas un solo servicio. Un patrón habitual es exponer varios servidores internos multiplexando por puerto sobre una única IP pública:

/ip/firewall/nat
add chain=dstnat action=dst-nat protocol=tcp dst-port=81 \
    in-interface-list=WAN to-addresses=192.168.88.10 to-ports=80 \
    comment="Web servidor A"
add chain=dstnat action=dst-nat protocol=tcp dst-port=82 \
    in-interface-list=WAN to-addresses=192.168.88.20 to-ports=80 \
    comment="Web servidor B"

Aquí el puerto público 81 llega al servidor A y el 82 al servidor B, ambos escuchando internamente en 80. Cuando en cambio dispones de un bloque de IPs públicas y necesitas un mapeo determinista completo —típico en hosting o en clientes corporativos de un ISP— la acción correcta es netmap, que crea un NAT estático 1:1 entre rangos en lugar de traducir puerto por puerto.

Y no olvides el otro sentido del NAT: para que esos hosts internos salgan a Internet necesitas la regla de origen. En una WAN dinámica es el clásico:

/ip/firewall/nat
add chain=srcnat action=masquerade out-interface-list=WAN \
    comment="Salida NAT hacia Internet"

Seguridad: por qué el port forwarding MikroTik no reemplaza al firewall

Este es el error que más caro se paga. Publicar un puerto con dst-nat no filtra nada: solo redirige. Toda la responsabilidad de decidir quién puede alcanzar ese servicio recae en tu firewall, en la cadena forward de /ip/firewall/filter. Una regla de NAT sin su contraparte de filtrado deja el servicio interno expuesto a todo Internet.

Buenas prácticas que aplicamos en toda red que operamos:

• Restringe el origen. Si el servicio solo lo consumen sucursales o proveedores conocidos, usa src-address-list con una lista de IPs de confianza tanto en la regla de NAT como en el filtro. Un panel de administración jamás debería estar abierto al 0.0.0.0/0.
• Ordena las reglas del filtro. El firewall se evalúa de arriba hacia abajo: la regla que permite el tráfico DNAT debe ir antes de tu drop final en la cadena forward.
• Evalúa una VPN en vez de un puerto abierto. Para acceso administrativo o entre sedes, muchas veces exponer un puerto es la peor opción: un túnel WireGuard o IPsec site-to-site elimina la superficie pública por completo.

En concreto, la contraparte de filtrado para el ejemplo HTTPS anterior, permitiendo solo una lista de orígenes de confianza, se ve así:

/ip/firewall/filter
add chain=forward action=accept connection-state=new \
    connection-nat-state=dstnat protocol=tcp dst-port=443 \
    src-address-list=clientes-confianza \
    comment="Permite DNAT HTTPS solo a confianza"

El match connection-nat-state=dstnat es la forma correcta de identificar en el filtro exactamente el tráfico que tu regla de DNAT ya redirigió, sin depender de escribir a mano la IP interna de destino. Junto con connection-state=established,related action=accept arriba de la cadena, mantienes el forward cerrado por defecto y solo abres el servicio publicado al origen autorizado.

Si estás endureciendo el borde, revisa nuestra guía de firewall en RouterOS para el diseño de cadenas y listas de direcciones, y evalúa el enfoque de VPN site-to-site antes de publicar cualquier servicio de gestión hacia Internet.

Troubleshooting: CGNAT, hairpin NAT y connection tracking

Cuando el port forwarding "no funciona", casi siempre es una de estas tres causas:

• CGNAT del ISP. Si tu proveedor te entrega una dirección detrás de Carrier-Grade NAT (rango 100.64.0.0/10), no tienes una IP pública real y ningún port forwarding funcionará desde afuera. La verificación es simple: compara la IP de tu interfaz WAN con la que ves en un servicio "cuál es mi IP". Si no coinciden, hay NAT del operador de por medio y necesitas solicitar IP pública o resolver por VPN/túnel.
• Acceso desde la propia LAN (hairpin NAT). Un host interno que intenta llegar al servicio usando la IP pública suele fallar, porque la respuesta vuelve directo sin pasar de nuevo por el router. Se resuelve agregando una regla srcnat con action=masquerade para ese tráfico interno-hacia-interno, de modo que el retorno vuelva por el router.
• Reglas mal ordenadas o connection tracking. Revisa que ninguna regla previa en dstnat capture el paquete antes, y confirma con el flag dstnat=yes en la tabla de conexiones que la traducción se está aplicando.

En la práctica el hairpin NAT necesita dos reglas: el mismo dst-nat que publica el servicio y un masquerade que reescriba el origen del tráfico interno para forzar el retorno por el router. Para el servidor HTTPS del ejemplo, con la LAN en 192.168.88.0/24:

/ip/firewall/nat
add chain=dstnat action=dst-nat protocol=tcp dst-port=443 \
    dst-address=<ip-publica> src-address=192.168.88.0/24 \
    to-addresses=192.168.88.10 to-ports=443 \
    comment="Hairpin DNAT desde LAN"
add chain=srcnat action=masquerade protocol=tcp dst-port=443 \
    src-address=192.168.88.0/24 dst-address=192.168.88.10 \
    comment="Hairpin masquerade retorno LAN"

Sin ese masquerade, el servidor respondería directo al cliente de la LAN con su IP privada y el cliente descartaría la respuesta, porque no coincide con la IP pública que consultó. Con las dos reglas, el router queda en medio de ida y vuelta y la sesión se completa.

Si estás depurando un caso puntual en producción, nuestro equipo de soporte MikroTik puede revisar contigo los contadores de NAT, el connection tracking y el orden del firewall sobre tu configuración real.

El port forwarding en MikroTik es simple de escribir y fácil de dejar inseguro: dos líneas publican un servicio, pero sin filtrado, sin origen restringido y sin considerar CGNAT o hairpin, terminas con un puerto abierto y un dolor de cabeza. En MikroTik Chile diseñamos el borde completo —NAT, firewall, listas de direcciones y VPN— para que expongas exactamente lo que necesitas y nada más, con reglas documentadas y verificadas en producción. Si estás publicando servicios o segmentando el acceso de tus clientes o sucursales, conversemos tu caso con un ingeniero.