La VPN integrada de Windows no llega a una pasarela SSL de proveedor: por qué

Windows incluye cuatro tipos de túnel, y una pasarela de proveedor no es ninguno de ellos. Apunta un perfil integrado a una de ellas y la conexión falla antes de la petición de credenciales, normalmente con un mensaje que dice que el sistema local ha terminado la conexión. Ese texto es una señal de desajuste, no un diagnóstico. El tipo de perfil y el cliente que posee el protocolo tienen que coincidir, y uno de los dos falta.

Cuatro tipos y un diálogo

Cada perfil guardado lleva un tipo de túnel. El cliente integrado acepta PPTP, L2TP, IKEv2 y SSTP, además de un modo automático que los prueba en orden. No hay ninguna entrada genérica de SSL VPN, y no hay forma de añadir una desde el diálogo. Una pasarela de proveedor habla su propio protocolo de aplicación sobre TLS, que solo implementa el cliente de ese proveedor.

La lista está a una orden de distancia, y merece la pena ejecutarla antes de cualquier otra diagnosis porque tarda un segundo y elimina toda una clase de suposiciones erróneas:

Get-VpnConnection | Select-Object Name, ServerAddress, TunnelType, SplitTunneling
Get-VpnConnection -Name "Office" | Format-List

Si el perfil dice SSTP y la pasarela no es un servidor RRAS, el desajuste ya está establecido. Ningún trabajo de certificados o cortafuegos lo cambia.

SSTP y el TLS de proveedor se parecen en el puerto 443

SSTP envuelve una sesión PPP dentro de TLS y viaja por TCP 443. En la pila de Microsoft la termina RRAS, que presenta un certificado de servidor que el cliente valida. Un equipo Fortinet, Citrix o Pulse también termina TLS en el 443, y su portal se abre en cualquier navegador sin queja.

Esa prueba de navegador demuestra accesibilidad, no compatibilidad. El protocolo de sesión detrás del portal pertenece al proveedor, y el cliente integrado no tiene ninguna implementación de él. Si el proveedor distribuye un cliente propio te dice con qué mitad del desajuste tratas.

La confusión inversa también ocurre. Un perfil configurado como SSTP contra un servidor RRAS auténtico puede fallar en la validación del certificado mientras el portal está bien, y eso es un problema de certificado y no de protocolo.

Errores que aparecen antes de que exista un túnel

Los códigos de la serie 800 se notifican antes de que se establezca ningún túnel, por eso las reglas de cortafuegos rara vez los mueven. El error 812 es una política del servidor que rechaza el método de autenticación que ha ofrecido el cliente. Los demás del rango vienen del administrador de conexiones local y no de la red.

Activa el seguimiento antes de reconstruir nada. El seguimiento nombra la etapa que falla, y un nombre de etapa vale más que el texto del diálogo:

netsh ras set tracing * enable
Get-ChildItem "$env:windir\tracing" | Sort-Object LastWriteTime -Descending | Select-Object -First 5

Los seguimientos acaban en el directorio de seguimiento y se quedan allí hasta que los borres, así que desactiva el seguimiento después en lugar de dejarlo funcionando durante semanas.

Un perfil conectado todavía puede romperlo todo

Un perfil que se conecta y luego rompe la navegación, un recurso compartido local o un motor de contenedores tiene un problema de enrutamiento, no de túnel. La puerta de enlace predeterminada se ha movido al túnel, así que cada destino pasa ahora por un par que quizá no lo enrute.

Dos controles deciden esto. Uno es la propiedad de split tunneling del perfil. El otro es la opción por adaptador de usar la puerta de enlace predeterminada en la red remota, que está en la configuración avanzada de IPv4.

Set-VpnConnection -Name "Office" -SplitTunneling $true
Add-VpnConnectionRoute -ConnectionName "Office" -DestinationPrefix 10.20.0.0/16

Activar el split tunneling sin añadir rutas produce un túnel que se conecta y no llega a nada. Desactivarlo sin comprobar el DNS produce nombres internos que se resuelven a respuestas públicas, porque no se usan el sufijo ni los servidores propios del adaptador.

Verifica la instalación, luego el tipo

Trabaja en este orden, y detente cuando falle un paso en lugar de ajustarlo todo a la vez:

Test-NetConnection vpn.example.net -Port 443
Get-VpnConnection -Name "Office" | Format-List TunnelType, ServerAddress, DnsSuffix
netsh interface ipv4 show route
rasdial Office

La primera orden separa la accesibilidad del protocolo. La segunda confirma qué dice ser el perfil. La tabla de rutas muestra si el túnel ha capturado la ruta predeterminada. La orden de marcado informa del error propio del administrador de conexiones, que a menudo es más claro que el diálogo.

Anota el tipo de túnel, el producto de la pasarela y el error exacto en el tique. La siguiente persona sabe entonces en un minuto si es un desajuste de protocolo, un fallo de certificado o una decisión de enrutamiento, en lugar de empezar por “la VPN no funciona”.