Una mañana cualquiera los usuarios intentan iniciar su VPN corporativa y reciben un mensaje que los deja sin acceso: “The remote connection was not made because the name of the remote access server did not resolve”. El síntoma parece sencillo —no resuelve el nombre—, pero detrás puede haber DNS, firewall, NAT o un cambio involuntario del proveedor. A continuación encontrarás una guía completa, pensada para administradores de Windows Server 2019, que te ayudará a diagnosticar, corregir y evitar que este fallo vuelva a dejar tu infraestructura sin túnel seguro.
Por qué ocurre este error
El código subyacente suele ser el 868 o 809, ambos asociados a la imposibilidad de alcanzar el servidor VPN. El cliente inicia la fase de resolución DNS para transformar el FQDN (por ejemplo vpn.contoso.com) en una IP; si esa consulta falla o retorna una dirección incorrecta, el proceso se aborta antes de abrir cualquier puerto.
- Registro DNS inexistente o corrupto. Un borrado accidental, un TTL expirado que no se replicó o un cambio de IP pública sin actualización automática.
- Firewall del perímetro. Si el cortafuegos bloquea la salida de consultas DNS o la entrada del protocolo VPN, el cliente interpreta que no hay resolución.
- NAT mal encaminado. Un router que ya no reenvía el puerto al host interno provoca que la IP pública quede “muerta” para la petición.
- ISP con problemas. A veces un proveedor altera su propia caché o su pool de direcciones y corta la ruta.
Diagnóstico paso a paso
Cada red es única, pero el flujo lógico casi siempre coincide. Sigue los pasos en orden y tacha cada casilla antes de avanzar.
| Paso | Acción recomendada | Propósito / detalle |
|---|---|---|
| Comprobar DNS del servidor | Ejecuta nslookup vpn.tu-dominio.com desde el propio Windows Server. | Confirma que el servidor puede resolver su propio FQDN y que el registro A apunta a la IP pública vigente. |
| Vaciar y registrar de nuevo DNS | ipconfig /flushdns seguido de ipconfig /registerdns. | Borra entradas obsoletas y fuerza la re‑anunciación a los DNS internos y externos. |
| Verificar NAT o port forwarding | Ingresa al router/firewall y revisa la regla que redirige 443, 500, 4500, 1701 o 1723 según el protocolo. | Asegura que la IP interna del servidor no cambió (DHCP renovado, migración de NIC, etc.). |
| Revisar firewall Windows y perimetral | Comprueba perfiles Públicos/Privados en Windows Defender Firewall y reglas de borde. | Un parche o política de grupo puede haber bloqueado SSTP, IKEv2, L2TP o GRE. |
| Consultar Visor de eventos | Filtra System y Application por origen DNS Client Events, RRAS y RASMAN. | Errores 20227/20255 indican problemas de autenticación, pero si predominan errores 1014/1016 apuntas a DNS. |
| Validar la configuración RRAS | Abre Routing and Remote Access y repasa el asistente; exporta la configuración. | Un dato corrupto puede anunciar un FQDN viejo al cliente (visible en los perfiles .pbk). |
| Capturar tráfico | Con Wireshark o Microsoft Message Analyzer filtra dns y udp.port==53. | Verifica que la consulta sale del servidor y que la respuesta llega con la IP correcta. |
| Descartar problemas del ISP | Abre un ticket para confirmar que tu /29 o /30 no sufrió cambios y que no hay incidencia DNS. | Algunos proveedores rotan direcciones tras ciertas actualizaciones o mantenimiento. |
| Reforzar la capa DNS | Implementa zonas secundarias, DynDNS o Azure DNS con TTL corto. | Garantiza redundancia y una propagación veloz ante nuevas IP. |
Herramientas de diagnóstico clave
- nslookup y dig para consultas autoritativas.
- Get-DnsServerResourceRecord en PowerShell para inspeccionar registros A y su tiempo de vida.
- Test-NetConnection -ComputerName vpn.tu-dominio.com -Port 443 para validar la ruta hasta el puerto SSTP.
- WireShark con filtro
icmpytcp.port==443para ver si la IP responde ping y SSL. - Event Viewer para correlacionar ID 1014 (DNS client) y 20255 (RASMAN).
Escenarios frecuentes y su solución
Actualización automática de la IP pública
Si tu conexión es de tipo residencial o SMB, la IP puede cambiar sin previo aviso. Puntos a vigilar:
- Contrata una IP fija o usa un servicio de Dynamic DNS.
- Script programado en Task Scheduler que ejecute
nsupdateo las APIs del proveedor cada vez que se detecte una nueva WAN.
Cambio de la NIC interna
Un fallo de hardware o migración a VMware/Hyper‑V asigna una MAC distinta, con lo que DHCP otorga otra IP. Resultado: la regla NAT apunta a una dirección interna fantasma.
- Reserva la IP en DHCP o fija la NIC del servidor.
- Automatiza el reenvío en tu firewall mediante scripts REST o CLI.
Actualización de seguridad que endurece TLS
Parches mensuales de Microsoft pueden obligar a usar TLS 1.2 o 1.3. Si el cliente emplea una versión obsoleta (Windows 7 sin KB4555932, por ejemplo), el handshake falla y el usuario recibe el mensaje genérico de nombre no resuelto.
- Verifica los registros SChannel en
Event ID 36874 / 36888. - Habilita TLS 1.2 en el cliente mediante el registro:
[HKEYLOCALMACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client]
"DisabledByDefault"=dword:00000000
"Enabled"=dword:00000001
DNS interno responde diferente a DNS externo
En redes híbridas es habitual delegar contoso.com a un DNS interno para recursos de intranet. Si alguien crea un registro vpn solo en interno, los clientes externos reciben NXDOMAIN.
- Crea una zona split‑brain con registro A replicado en ambos lados.
- Reduce el TTL a 300 segundos para una propagación más rápida.
Medidas preventivas a largo plazo
Una vez resuelto el incidente, aprovecha para blindar tu infraestructura:
- Supervisión proactiva DNS + puerto. Herramientas como Zabbix, PRTG o Azure Monitor pueden efectuar un lookup y una conexión TCP cada minuto. Configura alertas SMS cuando el resultado sea negativo.
- Backups de RRAS y de la zona DNS. Exporta con
netsh ras dump > rras.cfgydnscmd /ZoneExportpara restaurar en minutos. - Documenta cambios de red. Usa un repositorio Git para versiones de configuración de firewall, scripts de NAT y plantillas de DHCP.
- Pruebas tras parches. Establece una ventana de mantenimiento en la que apliques actualizaciones a un clúster de ensayo antes de producción.
- Segmentación de la DMZ VPN. Un salto de red entre el dispositivo borde y el servidor RRAS permite inspección IPS sin exponer directamente el servidor a internet.
Preguntas frecuentes
¿Puedo conectarme usando directamente la IP pública?
Sí. Introduce la IP en lugar del FQDN en la conexión VPN mientras solucionas el DNS. No es ideal a largo plazo porque obliga a cambiar los clientes cada vez que cambie la dirección.
¿Qué puertos necesito abrir exactamente?
Depende del protocolo:
- SSTP: TCP 443
- IKEv2: UDP 500 y UDP 4500
- L2TP/IPsec: UDP 1701, 500, 4500 + ESP (IP protocol 50)
- PPTP: TCP 1723 + GRE (IP protocol 47)
¿El error puede deberse a certificados caducados?
Sí. Si el certificado del servidor expiró, el cliente puede abortar antes de intentar TLS, devolviendo también el mensaje de resolución. Revisa certificados en certlm.msc → Personal → Certificates y renueva con una autoridad externa o tu propia PKI.
Conclusión
El mensaje “The remote connection was not made because the name of the remote access server did not resolve” es casi siempre un síntoma, no la causa real. La clave está en seguir un procedimiento metódico: comprobar DNS, descartar NAT, revisar puertos y apoyarse en registros del sistema. Con una supervisión proactiva y redundancia DNS, el error pasará de crisis inesperada a mera notificación de mantenimiento programado.