Qué puertos de VPN abrir en un cortafuegos: protocolo por protocolo

Dos reglas separadas deciden si un túnel VPN sobrevive a un cortafuegos: el puerto al que marca el cliente y el protocolo que transporta la carga. Abre solo la primera y el túnel se autenticará, pero después no moverá ningún dato. El mínimo es un puerto TCP más GRE para PPTP, dos puertos UDP más ESP para L2TP/IPsec e IKEv2, y un solo puerto para SSTP, OpenVPN y WireGuard. La dirección, el seguimiento de estado y el NAT deciden el resto.

Empieza por el puerto al que marca el cliente

Cada familia tiene un punto de entrada al que el cliente contacta primero, y ese punto de entrada es el que tu regla de permiso debe nombrar. Los clientes PPTP se conectan a TCP 1723. L2TP/IPsec inicia IKE en UDP 500 y pasa a UDP 4500 cuando se usa la travesía de NAT, con la propia trama L2TP en UDP 1701 dentro del túnel. SSTP envuelve la sesión en TLS sobre TCP 443, IKEv2 negocia en UDP 500 y 4500, OpenVPN usa UDP 1194 por defecto pero a menudo se mueve a TCP 443, y WireGuard escucha en UDP 51820.

Trata esos números como valores por defecto y no como propiedades fijas. Una interfaz WireGuard usa el puerto de escucha que declare su configuración, y un servidor OpenVPN puede estar en cualquier puerto que haya elegido el administrador. Lee la configuración del servidor antes de escribir la regla, porque un cortafuegos abierto para 1194 no hace nada por un servidor que se movió a 443.

La tercera columna es donde fallan la mayoría de los tiques de cambio. La regla existe, pero apunta al destino equivocado, a la dirección equivocada o al transporte equivocado.

GRE y ESP son números de protocolo, no puertos

GRE y ESP no tienen ningún puerto, así que un formulario de cortafuegos que solo acepta números de puerto no puede expresarlos. GRE es el protocolo IP 47 y ESP es el protocolo IP 50, ambos se emparejan mediante el campo de protocolo de la cabecera IP. Una regla escrita como puerto TCP 47 no coincide con nada, y así una política PPTP parece correcta y aun así descarta cada paquete después del apretón de manos.

Los routers domésticos esconden esto tras una casilla de paso que instala la regla de protocolo y, para GRE, el ayudante de NAT necesario para mapear el flujo. En un cortafuegos real añades el protocolo tú mismo: permite el protocolo IP 47 hacia el servidor PPTP, permite el protocolo IP 50 hacia la puerta de enlace IPsec. Donde la plataforma no ofrece campo de protocolo, la encapsulación es la salida, por eso IKEv2 puede recaer en UDP 4500 y por eso OpenVPN y WireGuard nunca tropiezan con el problema.

Comprueba con qué coincide realmente la regla antes de culpar al cliente. Un contador de paquetes que se queda en cero en la puerta de enlace dice que la regla nunca se activó, y ninguna cantidad de reinstalación en el lado del cliente lo cambia.

La dirección, el estado y el NAT cambian la respuesta

Un cliente que marca hacia fuera y una puerta de enlace que escucha hacia dentro son requisitos distintos, y la misma lista de puertos puede ser correcta en una dirección e incorrecta en la otra. Un cortafuegos con estado sigue el flujo UDP en 500 y 4500 y deja volver las respuestas sin una segunda regla. ESP y GRE no llevan puertos, así que un dispositivo NAT no tiene de qué agarrarse y necesita un ayudante o una encapsulación para seguir la sesión.

La travesía de NAT es la parte que se pasa por alto. IKEv2 empieza en UDP 500, detecta un dispositivo NAT y continúa en UDP 4500, así que una política que solo permite 500 da un túnel que se establece y luego calla. L2TP/IPsec hace el mismo movimiento. Si tu captura muestra el primer intercambio pero no tráfico sostenido, busca una regla que se detenga en 500.

Anota la dirección con cada regla. «Permitir UDP 4500» no significa nada hasta que digas de dónde a dónde, y una regla correcta para un cliente itinerante suele ser incorrecta para un par sitio a sitio.

Comprueba cada ruta con una captura

Ejecuta la captura en la puerta de enlace, no en el cliente: un cliente solo registra lo que llegó. Estos filtros cubren las familias anteriores y muestran qué etapa falta:

sudo tcpdump -ni any tcp port 1723
sudo tcpdump -ni any udp port 500 or udp port 4500
sudo tcpdump -ni any proto gre
sudo tcpdump -ni any proto 50

Lee la salida como una secuencia. Cuando aparece la negociación pero no el protocolo de carga, el descarte ocurre en algún punto entre el cliente y la puerta de enlace. Cuando aparecen ambos y la página sigue fallando, el cortafuegos ya no es el sospechoso; mira el enrutamiento, el DNS o el grupo de direcciones entregado al cliente.

En una máquina sin tcpdump, la misma evidencia viene de los contadores de interfaz y de reglas. Bytes que entran pero no salen en la interfaz del túnel apuntan al camino de vuelta y no a la regla de permiso inicial.

Deja un conjunto de reglas que puedas defender

SSTP sobre TCP 443 es indistinguible de un HTTPS corriente para cualquier filtro basado en puertos, y ese es el punto cuando una red solo permite tráfico web. También es la razón de que la regla del 443 deba nombrar la puerta de enlace como destino en lugar de todo internet. Borra las reglas temporales de cualquiera-a-cualquiera en cuanto el túnel funcione. Anota qué regla coincidió, el número de protocolo donde lo haya y la dirección, para que la siguiente persona empiece con evidencia.

Las puertas de enlace en la nube de punto a sitio hacen visible la elección: el perfil descargado usa o SSTP en 443 o IKEv2 en 500 y 4500, y deberías abrir solo el que el perfil elija de verdad. PPTP no merece la excepción de GRE en una red moderna, ya que las operadoras móviles suelen descartar el protocolo 47 independientemente de tu cortafuegos. Antes de cerrar el tique, confirma que la regla coincide con el puerto de la configuración del servidor, que el campo de protocolo está puesto donde la familia lo necesita y que el destino es la puerta de enlace y no cualquier dirección.