Las reglas de cortafuegos solo NEW no cierran todas las rutas WAN

Rechazar las conexiones salientes nuevas en la WAN parece una política de fallo cerrado, pero es una promesa más estrecha de lo que aparenta. Los paquetes que pertenecen a flujos que ya existen no coinciden con ella, y muchas respuestas tampoco. Ese hueco es fácil de pasar por alto porque la regla se lee como si cubriera la interfaz y no un estado de conexión sobre ella. Y leer la coincidencia de estado como un veredicto es lo que produce una falsa sensación de cierre.

El estado es una condición de coincidencia, no un veredicto

El seguimiento de conexiones clasifica los paquetes por lo que el cortafuegos ya ha visto, no por lo que cree la aplicación. Un flujo observado en ambos sentidos está establecido, y sus paquetes posteriores siguen establecidos incluso cuando la ruta debajo cambia de un túnel al enlace ascendente ordinario. Una respuesta a una conexión entrante también puede ser tráfico establecido. Esos paquetes nunca vuelven a ser nuevos.

Por eso una regla limitada a las conexiones nuevas no puede demostrar que todos los paquetes protegidos estén bloqueados. Deja los demás estados a lo que el resto del conjunto de reglas haga con ellos, que puede ser una aceptación colocada antes en la cadena.

Lee la regla en su entorno

Una aceptación amplia para el tráfico establecido y relacionado colocada antes del bloque deja pasar un paquete antes de que el bloque se evalúe. Quitar la condición de estado de una regla posterior no lo cambiará, porque la evaluación nunca llega a ella. El orden decide el resultado, y la coincidencia de estado decide qué paquetes llegan a ese orden.

Inspecciona el conjunto de reglas efectivo y no el archivo que editaste, incluidos los saltos a otras cadenas y todo lo que genera la plataforma. En un router gestionado con iptables, listar la cadena muestra las definiciones de las reglas, y también hay que seguir las cadenas a las que hace referencia. Un sistema nativo con nftables necesita revisar su propio conjunto de reglas y las prioridades de los hooks, porque el firmware rara vez genera cadenas idénticas.

Los contadores dicen qué regla coincidió realmente, y suelen ser más informativos que una captura de paquetes tomada después de la decisión. Una regla con el contador a cero no se ha alcanzado, diga lo que diga su posición.

Expresa la prohibición con independencia del estado

Si un grupo de clientes nunca debe llegar a internet fuera del túnel, dilo directamente en lugar de aproximarlo con un solo estado. La regla tiene que seleccionar por origen, salida y destino sin depender del estado de la conexión, y tiene que estar donde ninguna aceptación anterior pueda eludirla. Así el acceso de gestión y las excepciones de la red local reciben sus propias reglas explícitas, y la intención queda visible en la política.

Elegir reject en lugar de drop cambia cómo falla el tráfico coincidente, y no amplía el conjunto de paquetes que la regla selecciona. Una conexión rechazada y un tiempo de espera silencioso son síntomas distintos que apuntan a la misma selección.

Una política que permite deliberadamente respuestas a un acceso iniciado remotamente por la WAN es defendible. Solo hay que describirla así en lugar de presentarla como un aislamiento total únicamente por el túnel.

Comprueba quién está realmente dentro del grupo

El ejemplo cubre el tráfico IPv4 reenviado de un prefijo por una interfaz. No dice nada sobre IPv6, un segundo enlace ascendente ni el tráfico que origina el propio router. Un router que actúa como resolución DNS envía sus propias consultas ascendentes, y esas no pasan nunca por la cadena forward.

Confirma que los clientes protegidos siguen teniendo direcciones dentro del prefijo elegido, porque un dispositivo que se ha movido fuera de él es directo por accidente y no por política. Ampliar el bloque a toda la LAN sin revisar el diseño de las excepciones también suele eliminar tu propia ruta administrativa.

iptables -S FORWARD
iptables -L FORWARD -v -n
cat /proc/net/nf_conntrack | grep -c ESTABLISHED

Después prueba un flujo viejo junto a uno nuevo. Un intento de conexión nuevo y una transferencia bidireccional ya activa se comportan de forma distinta bajo esta regla, y solo probar ambos muestra qué política tienes en realidad.