Firewall perimetral para empresas con MikroTik

Si operas la red de una empresa o de un ISP, el borde es donde se juega casi todo: es el punto por el que entra el tráfico de Internet, donde viven las reglas de NAT, donde llegan los escaneos automatizados y desde donde se filtra hacia la LAN. Un firewall perimetral con MikroTik bien diseñado no es una lista larga de reglas copiadas de un foro: es una política de tráfico explícita, con estado, documentada y auditable. En este artículo revisamos cómo construir un firewall perimetral MikroTik sobre RouterOS que resista tráfico real de producción, sin caer en configuraciones frágiles que se rompen en la primera hora peak.

Qué protege realmente un firewall perimetral MikroTik

Antes de escribir una sola regla conviene separar dos planos que RouterOS trata por cadenas distintas. El firewall de filtrado vive en /ip/firewall/filter y trabaja sobre tres cadenas relevantes en el borde:

• input: tráfico dirigido al router mismo (Winbox, SSH, API, BGP, IPsec). Aquí proteges el plano de gestión y control.
• forward: tráfico que atraviesa el router entre interfaces (Internet ↔ LAN, LAN ↔ DMZ). Aquí proteges a tus servidores y usuarios.
• output: tráfico originado por el propio router. Rara vez se filtra, pero existe.

La distinción importa porque un error frecuente es endurecer forward y dejar input abierto: el resultado es una LAN protegida detrás de un router expuesto. En un firewall perimetral MikroTik serio, ambas cadenas tienen su propia política y ambas terminan con un drop explícito.

Cadena	Qué tráfico matchea	Rol en el borde
prerouting	Todo paquete antes de la decisión de ruteo	RAW, marcado, DSCP
input	Destinado al router	Proteger gestión y control
forward	Cruza el router entre interfaces	Proteger LAN, DMZ y servidores
output	Originado por el router	Control de tráfico saliente propio
postrouting	Después de rutear, antes de salir	NAT de origen (masquerade)

Firewall con estado: la base que no se negocia

RouterOS es un firewall stateful: mantiene una tabla de connection tracking donde cada paquete se clasifica según su connection-state. Aprovechar ese estado es lo que separa un firewall perimetral MikroTik ordenado de una lista de reglas que revisa cada paquete a mano.

Los cuatro estados que usarás a diario son:

• new: el paquete inicia una conexión nueva. Es el único que debes evaluar contra tu política de acceso.
• established: pertenece a una conexión ya aceptada. Se acepta de inmediato.
• related: asociado a una conexión existente (errores ICMP, canal de datos FTP). Se acepta.
• invalid: sin estado determinado en connection tracking (paquetes fuera de orden, secuencia/ACK erróneos, o el router sin recursos). La documentación de MikroTik es explícita: debes dropear todo connection-state=invalid en las cadenas forward e input.

La estructura correcta es la misma en input y en forward: aceptar lo establecido y relacionado primero, dropear lo inválido, evaluar lo nuevo según tu política y cerrar con un drop. Este es el esqueleto de una configuración de borde con dos interfaces agrupadas en una interface list WAN:

/interface/list
add name=WAN
add name=LAN
/interface/list/member
add interface=ether1 list=WAN
add interface=ether2 list=LAN

/ip/firewall/filter
# --- cadena INPUT: proteger el router ---
add action=accept chain=input connection-state=established,related \
    comment="input: aceptar established/related"
add action=drop chain=input connection-state=invalid \
    comment="input: drop invalid"
add action=accept chain=input protocol=icmp \
    comment="input: permitir ICMP controlado"
add action=accept chain=input in-interface-list=LAN \
    comment="input: gestion solo desde LAN"
add action=drop chain=input in-interface-list=WAN \
    comment="input: drop todo lo demas desde WAN"

# --- cadena FORWARD: proteger la LAN/DMZ ---
add action=fasttrack-connection chain=forward hw-offload=yes \
    connection-state=established,related \
    comment="forward: fasttrack para descargar la CPU"
add action=accept chain=forward connection-state=established,related
add action=drop chain=forward connection-state=invalid \
    comment="forward: drop invalid"
add action=accept chain=forward connection-state=new \
    in-interface-list=LAN out-interface-list=WAN \
    comment="forward: LAN sale a Internet"
add action=drop chain=forward connection-state=new \
    in-interface-list=WAN comment="forward: bloquear entrada no solicitada"

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

El orden es la política: RouterOS evalúa de arriba hacia abajo y ejecuta la primera regla que matchea. Por eso el established,related va primero (es el grueso del tráfico y no tiene sentido re-evaluarlo) y los drop finales cierran todo lo que no fue explícitamente permitido.

fasttrack y RAW: un firewall perimetral que aguanta la hora peak

En un borde de ISP con miles de sesiones concurrentes, cada paquete que pasa por connection tracking cuesta CPU. La regla action=fasttrack-connection sobre established,related permite que las conexiones ya aceptadas salten gran parte del pipeline de firewall, reduciendo drásticamente la carga del procesador. Es la diferencia entre un CCR que va cómodo en hora peak y uno que se satura y empieza a dropear tráfico legítimo.

Cuando necesitas frenar tráfico antes de que entre a connection tracking —por ejemplo, descartar rangos hostiles o mitigar un flood sin gastar entradas en la tabla de conexiones— entra la tabla RAW en /ip/firewall/raw. Un paquete tratado allí con action=notrack queda en estado untracked y nunca consume recursos de conntrack. Combinar RAW para el bloqueo masivo temprano con el firewall filter para la política con estado es una de las técnicas que más rendimiento libera en bordes cargados.

Address-lists: bloqueo dinámico y superficie de gestión mínima

Las address-list convierten al firewall perimetral MikroTik en algo dinámico. En lugar de escribir una regla por cada IP, agrupas direcciones en listas y las referencias desde una sola regla. Dos usos que aparecen en casi todo borde bien operado:

• Blacklist dinámica: detectar escaneos o intentos de fuerza bruta y agregar automáticamente el origen a una lista que se dropea en RAW o en input, con tiempo de expiración.
• Gestión restringida: exponer Winbox, SSH y API únicamente a una lista mgmt de IPs de confianza, en vez de a todo Internet.

Para los intentos de fuerza bruta, el matcher connection-limit es útil, pero la documentación advierte que es intensivo en recursos y debe usarse siempre junto a connection-state=new o tcp-flags=syn para no evaluar cada paquete. Esa disciplina —reservar las reglas caras solo para conexiones nuevas— es transversal a todo el diseño.

La regla práctica de oro para el plano de gestión: nunca expongas Winbox ni la API a la WAN. Si necesitas administrar el borde de forma remota, hazlo dentro de un túnel cifrado en lugar de abrir puertos al mundo. Un acceso vía VPN (WireGuard o IPsec site-to-site) filtrado en la cadena input es infinitamente más seguro que un puerto de gestión publicado. Si quieres profundizar en el diseño de las reglas de filtrado en sí, revisa nuestra página de firewall RouterOS.

Errores frecuentes en el borde que vemos en producción

Cuando nos toca auditar un firewall perimetral MikroTik existente, los mismos problemas se repiten:

• Sin drop final. Una cadena sin regla de cierre acepta por defecto todo lo que no matcheó antes. La política tiene que ser explícita: lo que no está permitido, se dropea.
• No dropear invalid. Dejar pasar connection-state=invalid abre la puerta a paquetes malformados que ni siquiera participan de NAT y conservan su IP de origen original al ser ruteados.
• Orden invertido. Poner el accept established,related al final obliga al router a evaluar reglas caras sobre cada paquete de conexiones ya aprobadas. Va primero, siempre.
• Gestión abierta a la WAN. Winbox o API accesibles desde Internet, confiando solo en una contraseña fuerte. El puerto no debería existir hacia afuera.
• ICMP totalmente bloqueado. Matar todo ICMP rompe Path MTU Discovery y genera problemas de fragmentación difíciles de diagnosticar. Se controla, no se elimina.

Ninguno de estos errores es exótico: son el resultado de configuraciones que crecieron por acumulación, regla sobre regla, sin una política de fondo. Un borde estable se diseña una vez, se documenta y se versiona.

De la teoría a tu borde en producción

Un firewall perimetral MikroTik sólido no requiere reglas exóticas: requiere criterio sobre las cadenas correctas, uso disciplinado del estado de conexión, fasttrack para el rendimiento, RAW para el bloqueo temprano y address-lists para lo dinámico. La parte difícil no es la sintaxis de RouterOS, sino traducir la política de seguridad real de tu empresa o ISP a un conjunto de reglas ordenado, con estado y auditable, que siga funcionando cuando el tráfico se multiplique.

En MikroTik Chile diseñamos, implementamos y operamos firewalls perimetrales sobre RouterOS para empresas e ISP con infraestructura de misión crítica, integrados con VPN site-to-site, monitoreo y alta disponibilidad. Si quieres auditar tu borde actual o levantar uno nuevo bien hecho, revisa nuestro soporte de red y hablemos: cuéntanos tu topología y el tráfico que manejas en nuestra página de consultoría. Conversemos de ingeniero a ingeniero sobre cómo dejar tu perímetro estable y documentado.