Entre Stateful y Stateless: Dominando el Firewall de MikroTik

Q: ¿MikroTik utiliza un firewall Stateful?

Sí. RouterOS incorpora connection tracking , lo que permite utilizar un enfoque Stateful y trabajar con estados de conexión como new , established , related e invalid .

Q: ¿Cuál es la diferencia entre RAW y Filter?

filter se utiliza para aplicar políticas de filtrado y puede aprovechar connection tracking. raw permite actuar en una etapa anterior del procesamiento, antes de connection tracking en determinados escenarios.

Ingrid Espinoza
noviembre 12, 2026
7:40 am
No hay comentarios

Cuando empecé a trabajar con el firewall de MikroTik, una de las cosas que más ayuda a entender su funcionamiento es dejar de pensar únicamente en términos de “permitir o bloquear paquetes”. En realidad, RouterOS puede trabajar teniendo en cuenta el estado de las conexiones, y ahí es donde aparece el concepto de firewall Stateful.

En mi caso, todo el trabajo práctico que he realizado ha sido con el firewall de MikroTik. Por eso, más que quedarme en una comparación teórica entre Stateful y Stateless, quiero llevar la explicación directamente a lo que ocurre en RouterOS: qué es connection tracking, qué significan new, established, related e invalid, qué papel desempeñan filter y raw y por qué todo esto importa cuando diseñamos nuestras reglas.

La primera aclaración es importante: MikroTik permite realizar tanto filtrado Stateful como Stateless. Sin embargo, cuando utilizamos connection tracking y las condiciones connection-state, estamos aprovechando las capacidades Stateful de RouterOS.

Al final del artículo encontrarás un pequeño test que te permitirá evaluar los conocimientos adquiridos en esta lectura

Ir al Test

¿Qué significa que un firewall sea Stateful o Stateless?

Antes de entrar de lleno en MikroTik, conviene entender la diferencia.

Un firewall Stateless analiza cada paquete de forma independiente. Para decidir si debe permitirlo o bloquearlo, utiliza información contenida en ese paquete, como:

Dirección IP de origen.
Dirección IP de destino.
Protocolo.
Puerto de origen.
Puerto de destino.
Interfaz.
Otras características del paquete.

El firewall no necesita mantener información sobre lo que ocurrió con los paquetes anteriores.

Un firewall Stateful, en cambio, mantiene información sobre las conexiones o flujos que está observando. Esto le permite saber, por ejemplo, que un determinado paquete pertenece a una conexión que ya había sido aceptada.

La diferencia puede parecer pequeña, pero cambia bastante la forma de construir las reglas.

Firewall Stateless: cada paquete se analiza por separado

Imaginemos una regla que permite tráfico TCP desde una dirección determinada hacia un servidor:

Origen: 192.168.1.0/24
Destino: 10.0.0.10
Protocolo: TCP
Puerto: 443
Acción: aceptar

Desde una perspectiva Stateless, cada paquete que coincida con esos criterios puede ser aceptado.

El firewall no necesita preguntarse si ese paquete pertenece a una conexión que comenzó hace unos segundos. Simplemente compara sus características con las reglas.

Esto puede ser perfectamente válido para determinadas situaciones y también puede resultar útil cuando queremos evitar el coste asociado a mantener información sobre las conexiones.

El problema aparece cuando queremos construir políticas más inteligentes.

Firewall Stateful: el firewall conoce el contexto

En un firewall Stateful, el sistema mantiene información sobre las conexiones.

Supongamos que un equipo de nuestra LAN inicia una conexión HTTPS hacia Internet.

El primer tráfico puede ser identificado como una conexión nueva:

connection-state=new

Una vez que la conexión ha sido aceptada y establecida, los paquetes posteriores pueden identificarse como:

connection-state=established

De esta forma podemos crear una política que permita explícitamente las conexiones nuevas que nos interesan y, después, permita el tráfico correspondiente a conexiones que ya conocemos.

Esto hace que las reglas sean mucho más expresivas.

¿MikroTik es Stateful o Stateless?

Aquí es donde conviene evitar una simplificación habitual.

El firewall de MikroTik puede trabajar tanto con filtrado Stateful como Stateless.

RouterOS dispone de connection tracking, que permite mantener información sobre las conexiones y utilizarla posteriormente en las reglas del firewall. La documentación oficial de MikroTik también distingue entre funcionalidades que utilizan connection tracking y aquellas en las que puede evitarse.

Por tanto, si configuramos una regla como:

/ip firewall filter
add chain=forward connection-state=established,related action=accept

estamos utilizando información proporcionada por el seguimiento de conexiones.

En cambio, una regla que simplemente comprueba una dirección IP, protocolo o puerto puede tomar una decisión basándose en las características del paquete sin necesitar necesariamente conocer el estado de una conexión.

Esta distinción es importante porque evita una conclusión incorrecta:

MikroTik no es simplemente “un firewall Stateful”.

Lo correcto es decir que RouterOS incorpora capacidades Stateful mediante connection tracking y también permite realizar filtrado que no depende de ese seguimiento.

Connection Tracking: el componente que cambia las reglas del juego

Si queremos entender el firewall Stateful de MikroTik, tenemos que entender Connection Tracking.

Connection Tracking es el mecanismo que permite a RouterOS mantener información sobre las conexiones que atraviesan el dispositivo.

Esto hace posible que una regla de firewall no tenga que tratar todos los paquetes como acontecimientos completamente independientes.

Por ejemplo, cuando un cliente interno inicia una conexión, RouterOS puede registrar información relacionada con ella. Los siguientes paquetes pueden entonces asociarse con esa conexión.

Esto permite utilizar estados como:

new
established
related
invalid

Y aquí está una de las grandes ventajas prácticas del enfoque Stateful: nuestras reglas pueden tomar decisiones teniendo en cuenta qué está ocurriendo con la conexión, no solamente qué contiene el paquete actual.

Los estados `new`, `established`, `related` e `invalid`

Estos estados aparecen constantemente cuando configuramos un firewall de MikroTik.

new identifica tráfico asociado a una conexión que está iniciándose.

established identifica tráfico perteneciente a una conexión que ya está establecida.

related se utiliza para conexiones relacionadas con otra conexión ya existente.

invalid identifica paquetes que no pueden asociarse correctamente con una conexión válida según el seguimiento de conexiones.

Por ejemplo, una configuración habitual puede incluir:

/ip firewall filter
add chain=forward connection-state=established,related action=accept

La idea es sencilla: si el tráfico pertenece a conexiones que ya conocemos y que han sido consideradas válidas, podemos aceptarlo mediante una regla específica.

También es frecuente encontrar:

/ip firewall filter
add chain=forward connection-state=invalid action=drop

Aquí estamos descartando tráfico que RouterOS identifica como inválido desde la perspectiva de connection tracking.

Lo importante no es memorizar estos comandos, sino entender por qué existen.

Cliente → MikroTik

Ese tráfico corresponde a input.

La cadena `forward`

forward se utiliza cuando el router está procesando tráfico que atraviesa el dispositivo para llegar a otro destino.

Por ejemplo:

Cliente LAN → MikroTik → Internet

El paquete no tiene como destino final el propio MikroTik. El router está encaminándolo.

Por eso las reglas que protegen el tráfico que atraviesa el router suelen encontrarse en forward.

La cadena `output`

output controla tráfico generado por el propio router.

Conceptualmente:

MikroTik → Internet

Esto permite establecer políticas para las conexiones originadas directamente desde el dispositivo.

Comprender estas tres cadenas es fundamental porque una regla técnicamente correcta colocada en la cadena equivocada puede no producir el resultado esperado.

Stateful vs. Stateless: diferencias prácticas

La comparación entre ambos enfoques se entiende mejor cuando dejamos la teoría y pensamos en una red real.

Característica	Stateful	Stateless
Analiza cada paquete	Sí	Sí
Mantiene información de conexiones	Sí	No
Puede utilizar estados de conexión	Sí	No
Permite decisiones basadas en contexto	Sí	No
Requiere recursos para mantener estados	Sí	Menos
Configuración de conexiones complejas	Más sencilla	Puede ser más laboriosa
Ejemplo en MikroTik	`connection-state`	Reglas basadas en atributos del paquete

Seguridad

Un firewall Stateful puede construir políticas más completas porque sabe si un paquete forma parte de una conexión que ya ha sido aceptada.

Esto resulta especialmente útil cuando queremos distinguir entre:

conexiones nuevas;
conexiones existentes;
conexiones relacionadas;
tráfico que no encaja correctamente con el seguimiento.

En lugar de crear reglas independientes para cada dirección y cada etapa de una comunicación, podemos aprovechar el estado de la conexión.

Rendimiento y consumo de recursos

Aquí aparece uno de los principales costes del enfoque Stateful.

Mantener información sobre conexiones requiere recursos.

Connection Tracking tiene que mantener y consultar información sobre los flujos que está siguiendo. En un router con mucho tráfico o con recursos limitados, esto puede ser relevante.

Por eso no siempre debemos asumir que “más inspección” significa automáticamente “mejor”.

La arquitectura debe responder a las necesidades reales de la red.

Complejidad de las reglas

Paradójicamente, aunque Stateful requiere más procesamiento, puede simplificar considerablemente la configuración.

Una regla como:

connection-state=established,related

puede cubrir una gran cantidad de tráfico que, de otra forma, tendríamos que tratar mediante condiciones adicionales.

En mi experiencia trabajando con el firewall de MikroTik, esta forma de pensar resulta mucho más práctica que intentar construir todas las reglas mirando únicamente IP, puerto y protocolo.

¿Qué relación existe entre RAW y el firewall Stateful?

Aquí entramos en una de las partes más interesantes de RouterOS.

No todo el tráfico necesita necesariamente pasar por connection tracking.

El menú:

/ip firewall raw

permite trabajar con paquetes antes de que sean procesados por connection tracking en determinados escenarios del flujo de paquetes.

Esto significa que RAW puede utilizarse, entre otras cosas, para tomar decisiones tempranas sobre determinados paquetes que no queremos que sean seguidos por connection tracking.

RAW vs. Filter en MikroTik

Una simplificación útil sería:

Filter:

/ip firewall filter

se utiliza para aplicar políticas de filtrado y puede aprovechar información de connection tracking.

RAW:

/ip firewall raw

permite actuar sobre el tráfico antes de connection tracking en determinados puntos del procesamiento.

Esto abre una posibilidad importante: no todo filtrado en MikroTik tiene que depender del estado de una conexión.

Por ejemplo, si tenemos claro que determinado tráfico debe descartarse y no necesitamos conocer su estado, hacerlo lo antes posible puede evitar trabajo adicional.

La documentación de RouterOS explica precisamente esta relación entre RAW, connection tracking y el procesamiento de paquetes.

Ejemplo práctico de un firewall Stateful en MikroTik

Vamos a llevar todo esto a una estructura habitual.

Supongamos que tenemos:

Internet
   |
[MikroTik]
   |
  LAN

Queremos permitir las conexiones válidas y descartar las conexiones inválidas.

Una configuración conceptual podría empezar así:

/ip firewall filter
add chain=forward connection-state=established,related action=accept
add chain=forward connection-state=invalid action=drop

La primera regla permite tráfico perteneciente a conexiones ya establecidas o relacionadas.

La segunda elimina tráfico que connection tracking considera inválido.

Después podemos establecer reglas para las nuevas conexiones que realmente queremos permitir.

Por ejemplo, si queremos controlar el tráfico que sale desde nuestra LAN hacia Internet, podemos crear una política específica para esas conexiones nuevas.

La clave está en el orden y en la lógica de las reglas.

Permitir conexiones `established` y `related`

Una regla de este tipo aparece con mucha frecuencia en configuraciones Stateful:

connection-state=established,related

¿Por qué?

Porque no queremos tener que describir cada paquete de una comunicación una y otra vez.

Una vez que una conexión ha sido aceptada, podemos utilizar su estado para permitir el tráfico posterior.

Bloquear conexiones inválidas

Otra práctica habitual es descartar:

connection-state=invalid

Esto ayuda a mantener una política más limpia y evita aceptar tráfico que no puede relacionarse correctamente con el estado esperado de las conexiones.

Permitir nuevas conexiones de forma controlada

La parte realmente importante está en las conexiones new.

Aquí debemos definir qué queremos permitir.

No tiene mucho sentido tener un firewall lleno de reglas que permiten indiscriminadamente cualquier conexión nueva.

Una política Stateful bien diseñada debería responder preguntas como:

¿Desde dónde puede iniciar una conexión?
¿Hacia dónde?
¿Qué protocolos?
¿Qué puertos?
¿Qué servicios deben estar expuestos?
¿Qué tráfico debe bloquearse?

El objetivo no es tener muchas reglas, sino tener reglas coherentes con la política de seguridad.

Errores frecuentes al configurar el firewall de MikroTik

Confundir `connection-state` con el protocolo

Este es un error conceptual bastante común.

established, related o new no son protocolos.

Son estados relacionados con connection tracking.

TCP, UDP e ICMP son protocolos.

Por ejemplo:

protocol=tcp

connection-state=established

describen cosas diferentes.

Una condición puede indicar qué protocolo estamos examinando y otra puede indicar qué estado tiene la conexión.

Crear reglas sin entender el flujo de paquetes

Otro error consiste en copiar reglas de Internet sin saber si estamos protegiendo:

input

forward

No es lo mismo proteger el router que proteger los dispositivos que están detrás de él.

Antes de crear una regla conviene preguntarse:

¿Quién origina el tráfico y cuál es su destino final?

Esa pregunta sencilla ayuda a determinar qué cadena debemos utilizar.

Utilizar connection tracking cuando no es necesario

Stateful es extremadamente útil, pero no significa que absolutamente todo el tráfico deba depender de él.

En determinados escenarios podemos querer descartar tráfico de manera temprana mediante RAW y evitar que ese tráfico sea procesado innecesariamente por connection tracking.

Por eso es importante conocer ambos enfoques.

Stateful vs. Stateless: ¿cuál debería utilizar en MikroTik?

La respuesta no debería ser simplemente “Stateful siempre”.

En una configuración normal de MikroTik, connection tracking y las capacidades Stateful son fundamentales para construir políticas de firewall prácticas y fáciles de mantener.

Pero RouterOS también ofrece mecanismos para trabajar sin depender del seguimiento de conexiones.

La elección depende de lo que queramos conseguir.

Stateful tiene sentido cuando necesitamos contexto

Por ejemplo:

distinguir conexiones nuevas de existentes;
aceptar tráfico relacionado;
bloquear estados inválidos;
crear políticas de seguridad basadas en conexiones;
simplificar reglas para tráfico que pertenece a conexiones ya autorizadas.

Stateless puede ser interesante cuando buscamos decisiones simples

Si solamente necesitamos decidir:

“Todo paquete que cumpla estas características debe descartarse”.

no necesariamente necesitamos mantener información sobre una conexión.

Y ahí es donde mecanismos como RAW pueden resultar interesantes dependiendo del escenario.

La conclusión práctica es que Stateful y Stateless no deberían entenderse como dos mundos completamente separados.

En MikroTik podemos utilizar las capacidades de ambos enfoques para construir una política de firewall eficiente.

Conclusión

Entender la diferencia entre Stateful y Stateless cambia la manera en que configuramos un firewall de MikroTik.

Un firewall Stateless analiza los paquetes individualmente. Un firewall Stateful añade contexto mediante el seguimiento de las conexiones.

En RouterOS, ese contexto lo proporciona Connection Tracking, que permite trabajar con estados como new, established, related e invalid.

En mi caso, todo el trabajo práctico que he realizado ha sido con MikroTik, y precisamente por eso considero que entender estos conceptos resulta mucho más útil que limitarse a memorizar comandos. Cuando sabes qué está haciendo RouterOS con cada conexión, las reglas dejan de parecer una colección de comandos aislados y empiezan a tener sentido.

Y también hay una idea importante que conviene llevarse:

MikroTik no tiene que ser entendido exclusivamente como Stateful o exclusivamente como Stateless. RouterOS ofrece ambos enfoques y permite decidir cuándo necesitamos connection tracking y cuándo podemos trabajar directamente sobre las características del paquete.

Dominar esa diferencia es lo que realmente permite construir un firewall de MikroTik más claro, eficiente y fácil de mantener.

Preguntas Frecuentes

¿MikroTik utiliza un firewall Stateful?

Sí. RouterOS incorpora connection tracking, lo que permite utilizar un enfoque Stateful y trabajar con estados de conexión como new, established, related e invalid.

¿Qué es Connection Tracking en MikroTik?

Es el mecanismo mediante el cual RouterOS mantiene información sobre las conexiones que atraviesan el dispositivo. Esa información puede utilizarse posteriormente en las reglas del firewall.

¿Qué significa established en RouterOS?

Indica que el tráfico pertenece a una conexión que ya ha sido establecida según el seguimiento de conexiones.

¿Cuál es la diferencia entre RAW y Filter?

filter se utiliza para aplicar políticas de filtrado y puede aprovechar connection tracking. raw permite actuar en una etapa anterior del procesamiento, antes de connection tracking en determinados escenarios.

¿Un firewall Stateless es más rápido que uno Stateful?

No debe asumirse automáticamente. Stateful implica mantener información de conexiones y, por tanto, tiene un coste adicional, pero puede simplificar las políticas y reducir la necesidad de reglas más complejas. El rendimiento real depende del tráfico, configuración y hardware.