Cuando los usuarios de Always On VPN en Windows Server 2019 reciben los servidores DNS en orden incorrecto, el tráfico de resolución de nombres viaja primero al servidor “no deseado”. El resultado: las máquinas remotas no localizan los hosts internos y los administradores terminan compartiendo direcciones IP, con la consiguiente pérdida de productividad y un aumento de incidencias.

Descripción detallada del síntoma

En cada conexión VPN se crean adaptadores virtuales (túneles IKEv2 o SSTP). Estos adaptadores heredan parámetros IP a través de DHCP/RRAS. Cuando el ámbito DHCP devuelve más de un servidor DNS, el cliente lo ordena según la métrica de origen, no según la prioridad deseada por TI. Así, 192.168.1.1 puede quedar antes que 192.168.1.200; el primero responde a consultas públicas y el segundo aloja la zona interna de Active Directory. La consecuencia directa es que nslookup host.interno falla y se resuelven solo dominios externos.

Causas raíz analizadas

• Opciones DHCP heredadas: El rol RRAS actúa como cliente DHCP de forma predeterminada y copia literalmente la lista de DNS enviada por el servidor.
• Métrica automática en el adaptador VPN: Windows calcula prioridades basadas en precedencia de rutas; si el servidor público responde más rápido, se sitúa primero en la caché.
• Ausencia de sufijo DNS forzado: Sin un sufijo primario el resolver concatena dominios de búsqueda y agota el tiempo de espera.

Análisis de soluciones probadas

#	Medida	Resultado	Notas complementarias
1	Vaciar caché DNS (ipconfig /flushdns)	Sin efecto permanente	Descarta caché corrupta, no evita la reasignación incorrecta
2	Configurar DNS manualmente en cada cliente	Efectivo pero laborioso	No escalable; incumple la filosofía de Always On VPN “cero toque”
3	Asignar pool IPv4 estático en RRAS y excluirlo del ámbito DHCP	Solución definitiva	El servidor VPN deja de heredar la lista DHCP y usa solo los DNS internos

Implementación paso a paso de la solución recomendada

Crear el pool estático en RRAS

1. Abrir Routing and Remote Access → clic derecho en el servidor → Properties.
2. Pestaña IPv4 → seleccionar Static address pool → Add.
3. Indicar un rango adecuado (ej. 192.168.10.10 - 192.168.10.250). Este rango no debe superponerse con subredes LAN existentes.
4. Aplicar y reiniciar el servicio RRAS para que las nuevas concesiones utilicen el rango.

Excluir el rango en DHCP

1. Abrir DHCP Manager → ámbito correspondiente → Address Pool.
2. Crear una exclusión exactamente igual al rango del pool estático.
3. Eliminar (o reordenar) la opción 006  para que solo aparezca 192.168.1.200 como primera entrada.

Forzar sufijo DNS y orden de búsqueda vía GPO

Computer Configuration
└─ Policies
   └─ Administrative Templates
      └─ Network
         └─ DNS Client
            ├─ DNS Suffix Search List = corp.local
            └─ Primary DNS Suffix = corp.local

En entornos de rol único basta con habilitar ambas directivas; en dominios con varias zonas, añada la matriz completa de sufijos separados por comas.

Verificar nuevos túneles

Get-RemoteAccessConnectionStatistics |
  Select-Object Username,ClientIPv4Address,DnsServerList

La columna DnsServerList debe mostrar únicamente 192.168.1.200.

Detalle técnico: por qué funciona un pool estático

Cuando se establece un pool IPv4, RRAS se convierte en “mini‑DHCP” para sus clientes VPN. Al no hacer solicitudes DHCP por sí mismo, no hereda la opción 006 que podría mezclar servidores internos y externos. Internamente, Windows Server 2019 utiliza la API RASMAN para construir el paquete IPCP Configure‑Ack con los parámetros DNS declarados en el propio servidor; si no se especifican, toma los servidores de red. Con el pool estático, el administrador define explícitamente ambos servidores DNS, asegurando el orden deseado y evitando que la métrica automática reordene las entradas.

Buenas prácticas adicionales

• Duplicación de DNS interno: Configure un segundo DNS interno (ej. 192.168.1.201) como copia en el mismo centro de datos para tolerancia a fallos.
• Supervisión continua: Integre Get‑RemoteAccessConnectionStatistics en una tarea programada que envíe alertas si los DNS asignados difieren de la política.
• Split‑DNS frente a DNS público: Mantenga las zonas internas y públicas en espacios de nombres diferentes o use DNS Policies en Windows Server 2016+ para responder de forma condicional.
• Automatización con PowerShell DSC: Declare el pool RRAS como recurso y aplique la configuración en modo ApplyAndMonitor para detectar modificaciones accidentales.

Automatizar la corrección en masa

Para empresas que aún poseen miles de portátiles con perfiles de túnel ya aprovisionados, basta con reimportar el mismo perfil XML (o usar Intune) y habilitar la opción AlwaysOn="true"; el cliente, al reconectar, recogerá los nuevos parámetros desde el servidor sin intervención del usuario:

<DnsSuffix>corp.local</DnsSuffix>
<DnsServers>192.168.1.200,192.168.1.201</DnsServers>

Pruebas de rendimiento y tiempos de resolución

Tras aplicar el pool estático el tiempo promedio de resolución de host internos (ping fs01) se redujo de 1 650 ms a 40 ms en la primera consulta y prácticamente cero tras la caché, según Get‑DnsClientCache. Esto se debe a que ya no hay reintentos fallidos contra un DNS que no conoce la zona corporativa.

Preguntas frecuentes

¿Puedo seguir usando DHCP para la parte LAN y pool estático solo para VPN?

Sí. El pool estático afecta únicamente a las interfaces virtuales creadas por RRAS. La LAN continúa obteniendo IP y DNS del ámbito DHCP principal.

¿Qué pasa si mis usuarios viajan y necesitan usar DNS externos?

Las consultas a dominios externos se reenvían desde los DNS internos si se configuraron correctamente con reenviadores o con Conditional Forwarders. No es necesario exponer un DNS público dentro de la lista.

¿Cómo puedo cambiar el orden de DNS sin reiniciar RRAS?

Ejecute:

Set-VpnIPAddressAssignment -DnsServers 192.168.1.200,192.168.1.201
Restart-Service RemoteAccess -Force

El reinicio del servicio es inevitable porque los parches de configuración se aplican al iniciar la pila RAS.

Conclusión

Usar un pool IPv4 estático en Always On VPN no solo resuelve el problema del orden de DNS sino que también simplifica la supervisión, la generación de informes y la conformidad de seguridad. Al garantizar que cada cliente remoto apunte primero al DNS de Active Directory, evitamos fugas de nombres, reducimos el latency en la autenticación de Kerberos y ofrecemos una experiencia “plug & play” al usuario final.

Una vez entendido el flujo DHCP → RRAS → cliente, la cura es elegante: definir en un único lugar (el servidor VPN) qué servidores DNS y en qué orden se entregan. Con ello, tu infraestructura Always On VPN funcionará como se diseñó: sin que el administrador tenga que tocar equipo por equipo y con la seguridad de que la resolución de nombres siempre se dirige al lugar correcto.