Un puerto en el campo de dirección de la VPN de Windows solo funciona con SSTP

Un servidor VPN responde en TCP 10443, el cliente integrado de Windows tiene las credenciales correctas y la conexión sigue cayendo tras una pausa que parece un tiempo de espera de DNS. La causa suele ser el campo de dirección: escribir vpn.example.com:10443 en Nombre del servidor o dirección hace que Windows lea toda la cadena como un nombre de host, porque esa casilla no es una entrada general host:port. Que se pueda expresar ahí un puerto depende del tipo de túnel que use el perfil, y solo uno de los cuatro tipos trata el valor como algo que puede analizar.

Por qué el campo de dirección no es una casilla host:port

La propiedad del perfil que hay detrás de ese campo es ServerAddress, y cada tipo de túnel decide qué hace con la cadena. Tres de ellos no tienen ningún parámetro de puerto que rellenar, así que los dos puntos y un número son simplemente caracteres de un nombre que nunca se resolverá. El cuarto funciona sobre HTTPS, donde un puerto forma parte de la URL, así que el valor debe escribirse en una forma que se analice como tal.

Por eso el fallo parece una resolución de nombres y no una conexión rechazada. No hay ningún puerto malo que reportar, solo un nombre de host que no existe, y el error llega después de que el resolutor se rinda. Antes de tocar el servidor, compruebe qué tipo de túnel dice usar el perfil.

Los tres tipos con puerto fijo

PPTP se conecta a TCP 1723 y luego transporta el túnel en GRE, protocolo IP 47. L2TP/IPsec usa UDP 1701 para el túnel y UDP 500 más 4500 para IPsec, con 4500 como puerto de travesía NAT. IKEv2 también usa UDP 500 y 4500. Ninguno de esos perfiles expone un campo de puerto en ningún lugar de la interfaz, y ninguno negociará uno no estándar.

Un servidor que escucha en un puerto personalizado es, por tanto, inalcanzable para esos perfiles, sin importar cómo se escriba la dirección. Las respuestas prácticas son estrechas: publique el puerto estándar en el servidor o traduzca el puerto estándar al personalizado en el router que tiene delante. Ambas mantienen intacto el perfil del cliente, algo que vale mucho cuando el perfil se despliega por directiva y no se escribe a mano.

SSTP necesita una URL, no un nombre

SSTP es la excepción porque funciona dentro de una sesión TLS. El campo debe analizarse como una URL: primero el esquema https://, luego el host, luego dos puntos y el puerto. Sin el esquema, Windows sigue tratando el valor como un nombre simple y la conexión falla antes de que se produzca cualquier intercambio TLS.

La razón por la que esto sorprende es que el puerto predeterminado acepta el nombre de host desnudo. Un perfil que nunca necesitó un puerto personalizado nunca enseña la regla, y la primera persona que añade uno lo descubre fallando. Después de guardar, vuelva a leer el valor almacenado en lugar de fiarse del diálogo:

Get-VpnConnection -Name "Corporate SSTP" | Select-Object Name, ServerAddress, TunnelType

ServerAddress muestra exactamente lo que se guardó. Si se lee como un nombre de host desnudo con dos puntos, el perfil nunca recibió una URL y ninguna cantidad de reintentos lo arreglará.

Sintaxis de proveedor que se pega en la misma casilla

Algunas pasarelas documentan convenciones adicionales para ese campo, como un reino añadido después del puerto o parámetros de consulta que cambian el tratamiento de los certificados. Las entiende el servidor de ese proveedor y, en algunas compilaciones, su propio cliente. No forman parte del formato de perfil de Windows, y pegarlas en un perfil integrado suele producir el mismo fallo silencioso de nombre.

Trate un parámetro que desactive la validación de certificados como una advertencia y no como una solución. Si un perfil solo se conecta con ese parámetro, el certificado no coincide con el nombre que se usa, y la reparación correcta está en la pasarela, no en el cliente. Un reino después del puerto tiene la misma propiedad: hace algo solo si el servidor del otro lado lo espera.

Demuestre el puerto y luego lea la etapa que falla

Confirme que algo acepta TCP en ese puerto desde la red del cliente antes de culpar al perfil:

Test-NetConnection vpn.example.com -Port 10443

El éxito demuestra un oyente, no SSTP. Un servidor web, un proxy inverso o un balanceador de carga pueden completar el apretón de manos TCP y aun así no hablar SSTP, así que una prueba verde con una VPN roja es una combinación real. Compare el sujeto del certificado con el nombre del perfil y revise el registro RasClient en las compilaciones que lo incluyen, porque registra la etapa que falló en lugar de un tiempo de espera genérico.

Luego considere la opción que elimina el problema en lugar de documentarlo: reenviar el TCP 443 del exterior al 10443 del servidor VPN. El cliente usa entonces el perfil predeterminado sin ningún puerto, que suele ser la disposición más limpia para una flota gestionada y deja el puerto personalizado como detalle interno.