VPN conectada pero el cortafuegos sigue bloqueando: cómo saber cuál

El cliente dice conectado, el recurso sigue rechazando, y el siguiente paso habitual es desactivar algo. Los dos controles de esa frase hacen trabajos distintos: la VPN construye una ruta para el tráfico cubierto, y un cortafuegos decide por conexión si el tráfico puede pasar. Un túnel que funciona con una política que rechaza se ve exactamente como un túnel roto desde la silla del usuario, así que la tarea es averiguar qué capa responde. Este es el orden que sigo, con la lectura que te dice que pares.

Separa la ruta de la política

Empieza por la forma del fallo, porque es información gratis. Una caída de paquete produce un tiempo de espera: el cliente reintenta, no vuelve nada y el comando se cuelga hasta rendirse. Un rechazo produce una negativa o un reinicio: algo respondió y dijo que no. Un servicio que no escucha rechaza en el propio host, sin ningún cortafuegos de por medio.

Esos tres resultados apuntan a capas distintas. El tiempo de espera significa que alguna política en algún lugar descarta en silencio, o que la ruta nunca sale de la máquina. Rechazado significa que llegaste al host y su pila o su cortafuegos local dijo que no. Silencio total, con la interfaz del túnel activa y sin ruta al destino, significa que la ruta está mal y ninguna regla de cortafuegos lo arreglará.

Lee la ruta de una pasada

Confirma que el túnel cubre el destino antes de mirar una sola regla. Un túnel dividido que solo lleva la subred de la oficina no encaminará una petición a otro rango, y entonces el fallo parece un bloqueo del cortafuegos que no lo es:

ip route get 10.20.4.15
ip -brief address show
wg show
sudo ipsec statusall

La salida de la ruta nombra la interfaz por la que saldrá el paquete y la dirección de origen que llevará. Si esa interfaz es tu tarjeta de red física y no el túnel, el problema es de encaminamiento o de los rangos permitidos del túnel, y pertenece a la configuración de la VPN y no al cortafuegos.

Una trampa específica de la VPN merece su propia comprobación. En WireGuard, AllowedIPs de un par es a la vez una ruta y un filtro criptográfico: un paquete cuya dirección de origen no coincide con el conjunto permitido del par se descarta antes de consultar ninguna regla de cortafuegos. Así, un cortafuegos local perfectamente correcto puede estar detrás de un descarte silencioso que parece una política, y el arreglo es una línea de configuración de la clave y no una regla.

Lee la política en la capa que responde

Cuando la ruta es correcta, recorre la política desde el host hacia fuera y observa la única capa cuyos contadores se mueven:

ss -ltn | grep ':443'
sudo nft list ruleset
sudo iptables -S INPUT
sudo ufw status verbose

El socket que escucha responde una pregunta distinta de la de las reglas. Si nada escucha en el puerto, el núcleo rechaza la conexión y ninguna regla de entrada es relevante. Si el socket existe y la conexión desde un cliente remoto expira, se está produciendo un descarte en algún punto de la ruta, y los contadores de las reglas te dicen si ocurre aquí.

Activa el registro del perfil o la cadena que sospechas en lugar de adivinar desde fuera. Un solo descarte registrado que nombre el origen, el destino y el puerto identifica la capa y la regla, y además demuestra que el paquete llegó, algo que ninguna prueba del lado del cliente puede establecer.

Lee la decisión de la pasarela cuando el túnel termina allí

En una pasarela sitio a sitio o de acceso remoto, la VPN autentica a un usuario y la política autoriza un recurso, y esas son concesiones separadas. Un usuario admitido en el túnel no está admitido automáticamente en cada host interno, y el rechazo suele venir de una regla de reenvío mientras el túnel mismo está sano. La misma separación aparece en IPsec, donde la política de seguridad que selecciona el tráfico es distinta del filtro que lo admite, y por eso ambos se documentan como mecanismos diferentes en RFC 4301.

Comprueba la ruta de vuelta con el mismo cuidado que la de ida. El filtrado con estado necesita ver la respuesta, así que el encaminamiento asimétrico por el túnel en una dirección y alrededor de él en la otra produce descartes que parecen aleatorios y solo se reproducen desde algunos clientes. Si el tráfico llega a la pasarela y se detiene, lee la regla de reenvío y la ruta de vuelta juntas antes de ampliar nada.

La pasarela es también donde una regla de NAT o de enmascaramiento puede ocultar el origen real. Si los hosts internos ven la dirección de la pasarela en lugar del cliente, sus reglas de cortafuegos local que deben coincidir con el grupo de clientes nunca coincidirán, y el arreglo pertenece a la pasarela y no a cada servidor.

Cambia la capa más estrecha y luego verifica

Resiste la reparación amplia. Desactivar el cortafuegos local, añadir una regla que lo permita todo o forzar cada interfaz a un perfil de confianza elimina en cada caso el control que hacía su trabajo, y el cambio sobrevive al incidente. Una regla limitada al rango de origen y al puerto en cuestión es más fácil de revisar, más fácil de quitar y deja el resto de la política de la máquina intacta.

Verifica con la misma prueba que falló, desde el mismo cliente, y luego una vez más tras reconectar, porque una regla que coincide antes de que el túnel renegocie puede dejar de coincidir después:

nc -vz 10.20.4.15 443
curl -v --max-time 5 https://10.20.4.15/

Antes de cerrarlo:

• La ruta al destino sale por la interfaz del túnel, y la dirección de origen coincide con lo que espera la política.
• Algo escucha en el puerto, y la negativa o el tiempo de espera se atribuye a una regla nombrada en lugar de suponerse.
• La pasarela reenvía en ambos sentidos, y el destino ve el origen para el que se escribieron tus reglas.
• Ningún control se desactivó para que la prueba pasara, y el cambio que hiciste nombra un solo rango de origen y un solo puerto.