La VPN de RRAS en Windows Server 2019 conecta y permite RDP al DC, pero sin Internet ni acceso estable a unidades mapeadas, SQL o Sage. A continuación, el porqué y dos caminos de solución (split tunneling o túnel completo con NAT), con pasos, comandos y checklist.
Resumen de la situación
Conectas la VPN y puedes abrir Escritorio Remoto hacia el controlador de dominio. Sin embargo, al estar conectado:
- Se corta Internet o deja de navegar.
- Las unidades mapeadas aparecen “rojas” o desconectadas y al abrirlas fallan.
- SQL y aplicaciones como Sage no responden por nombre.
La sensación es que “estás en la LAN”, pero sin salida a Internet ni resolución correcta de servicios internos. Esto suele tener raíces en enrutamiento, NAT, DNS o reglas de firewall/ACL, y en ocasiones por colisión de subredes.
Por qué ocurre
- Enrutamiento/NAT: el cliente envía todo por la VPN (túnel completo), pero el servidor RRAS no traduce/reenruta a Internet; como resultado, el tráfico externo muere en el borde.
- DNS: los clientes no usan el DNS del dominio ni reciben el sufijo de búsqueda; por eso no resuelven fileserver, SQL o Sage.
- Firewall/ACL: reglas internas o del edge que bloquean el rango de IP de la VPN (p. ej., la address pool de RRAS) hacia SMB (445), SQL (1433) o puertos de Sage.
- Subredes superpuestas: la red de casa (192.168.1.0/24) coincide con la de la oficina; Windows elige una ruta y la otra queda inaccesible.
- IPv6 inconsistente: el cliente prefiere IPv6 pero la red interna no lo usa; la resolución devuelve AAAA y el flujo falla.
- Falta de rutas inter-VLAN: el DC es alcanzable porque comparte subred con la address pool, pero otros segmentos (fileserver, SQL) están en VLAN diferentes sin rutas en RRAS.
Cómo elegir el modelo de túnel
Modelo | Ventajas | Cuándo usar | Requisitos clave | Riesgos/Notas |
---|---|---|---|---|
Split tunneling | Internet del usuario no pasa por la VPN; menos carga en RRAS; latencia menor para servicios públicos. | Usuarios en movilidad; pocas redes internas; ancho de banda limitado en el sitio. | Desmarcar gateway remoto o usar SplitTunneling; publicar rutas internas; entregar DNS del dominio y sufijo. | Considera postura de seguridad: filtra tráfico corporativo en el endpoint (EDR/Firewall) y aplica políticas. |
Túnel completo | Todo el tráfico corporativo e Internet atraviesa la VPN; control y registro centralizados. | Ambientes con requisitos de auditoría/filtrado; apps que exigen salida por IP corporativa. | RRAS con NAT habilitado en interfaz pública; ruta por defecto operativa; DNS del dominio con reenviadores o root hints. | Mayor uso de ancho de banda; RRAS se vuelve punto crítico; dimensiona y monitorea. |
Camino A: Split tunneling bien hecho
Configurar el cliente Windows (GUI)
- Panel de control → Centro de redes → Cambiar configuración del adaptador.
- Botón derecho sobre la conexión VPN → Propiedades.
- Pestaña Redes → selecciona Protocolo de Internet versión 4 (TCP/IPv4) → Propiedades → Avanzadas.
- Desmarca Usar la puerta de enlace predeterminada en la red remota y acepta.
Esto evita que Internet salga por la VPN. Ahora necesitas rutas hacia las subredes internas.
Configurar el cliente Windows (PowerShell)
Si creas o administras la VPN por PowerShell en Windows 10/11:
# Crear la conexión con split tunneling
Add-VpnConnection -Name "EmpresaVPN" -ServerAddress "vpn.empresa.com" `
-TunnelType Ikev2 -AuthenticationMethod Eap `
-SplitTunneling $true -DnsSuffix "dominio.local" -RememberCredential
(Si ya existe) habilitar split tunneling
Set-VpnConnection -Name "EmpresaVPN" -SplitTunneling \$true -PassThru
Publicar rutas corporativas (ejemplos)
Add-VpnConnectionRoute -ConnectionName "EmpresaVPN" -DestinationPrefix "10.10.0.0/16"
Add-VpnConnectionRoute -ConnectionName "EmpresaVPN" -DestinationPrefix "172.16.20.0/24"
Publicar rutas desde RRAS/NPS (opcional pero recomendado)
En entornos administrados, conviene empujar rutas desde el servidor, para no depender de la configuración manual del cliente:
- En Servidor de directivas de red (NPS) → Directivas de red → tu directiva VPN → pestaña Configuración → Configuración de IP:
- Agrega rutas estáticas mediante el atributo MS-Route o Framed-Route para cada subred interna.
- Alternativa: ejecuta
Add-VpnConnectionRoute
vía script de inicio de sesión.
Entregar DNS del dominio y sufijo
Para que \\fileserver
o sqlserver
funcionen por nombre, los clientes deben usar el DNS del dominio y recibir el sufijo de búsqueda:
- En RRAS, botón derecho sobre el servidor → Propiedades → pestaña IPv4.
- Define servidores DNS (normalmente los DC). Puedes usar Pool estático o Desde el adaptador.
- En el cliente, establece sufijo con PowerShell si hace falta:
Set-DnsClient -InterfaceAlias "VPN - EmpresaVPN" -ConnectionSpecificSuffix "dominio.local"
Adicionalmente, mapea recursos con FQDN para evitar ambigüedades: \\fileserver.dominio.local\compartido
.
Verificar tras aplicar split tunneling
# En el cliente, conectado a la VPN:
ipconfig /all # DNS debe apuntar a DCs y mostrar el sufijo de dominio
route print # Deben aparecer rutas específicas a 10.0.0.0/8, 172.16.0.0/12, etc.
nslookup fileserver # Debe resolver con la IP interna
nslookup google.com # Debe resolver; salida a Internet por tu red local
tracert 8.8.8.8 # No debe “pasar” por la VPN
Camino B: Túnel completo con NAT en RRAS
Habilitar NAT en RRAS
- En Administración del servidor asegúrate de haber instalado Acceso remoto y configurado RRAS para VPN.
- En la consola Enrutamiento y acceso remoto expande IPv4 → NAT.
- Botón derecho en NAT → Agregar interfaz:
- Selecciona la NIC externa (con salida a Internet), marca Interfaz pública conectada a Internet y activa Habilitar NAT en esta interfaz.
- Agrega la interfaz interna/VPN como Interfaz privada conectada a la red privada.
Con esto, el tráfico de los clientes VPN saldrá a Internet traducido por la NIC pública del RRAS.
Asegurar la ruta por defecto del servidor
# En el servidor RRAS
route print # Debe existir 0.0.0.0/0 apuntando al router/ISP correcto
Get-NetIPConfiguration # Verifica puerta de enlace en la NIC pública
Si RRAS no es el borde real (está detrás de un firewall), asegúrate de que ese firewall permita el tráfico desde el rango de la VPN hacia Internet y no rompa el NAT encadenado.
DNS capaz de resolver Internet
- El/los DC con rol DNS deben tener reenviadores a tu ISP o públicos, o usar root hints.
- En la NIC del DC, no apuntes a DNS públicos directamente; usa solo DCs (preferido: él mismo o pares).
- En RRAS → Propiedades IPv4, especifica esos DC como DNS a entregar a los clientes VPN.
Permisos de firewall y ACL
- En Windows Defender Firewall con seguridad avanzada, permite tránsito desde la address pool de VPN hacia:
- SMB: TCP 445
- RPC y WMI si se usan scripts de inicio
- SQL Server: TCP 1433 (o el puerto que uses)
- Puertos de Sage que utilices en tu entorno
- En el firewall perimetral/NGFW, crea reglas simétricas para el rango VPN.
Rutas entre VLAN y redes internas
Si tus servidores viven en múltiples subredes/VLAN, RRAS debe saber llegar a todas y el router core debe saber devolver al rango de VPN:
- En RRAS → IPv4 → Rutas estáticas agrega entradas a cada subred interna (ej.: 10.20.0.0/16 → siguiente salto: 10.10.0.1, que sería el router core).
- En el router core, agrega ruta de retorno hacia la address pool de VPN con siguiente salto = IP interna del RRAS.
Checklist de diagnóstico
Síntoma | Probable causa | Cómo verificar | Acción |
---|---|---|---|
Sin Internet al conectar VPN | Túnel completo sin NAT en RRAS | tracert 8.8.8.8 se queda en RRAS | Habilitar NAT o cambiar a split tunneling |
Unidades mapeadas “rojas” | DNS del cliente no apunta al DC | ipconfig /all muestra DNS públicos | Entregar DNS del dominio desde RRAS |
RDP al DC funciona, pero no a file/SQL | Faltan rutas hacia otras VLAN | route print y ping a IPs de otras subredes | Agregar rutas en RRAS y en router core |
No resuelve fileserver | Sin sufijo DNS del dominio | ipconfig /all sin Connection-specific DNS Suffix | Configurar sufijo en VPN o vía GPO |
Conexiones intermitentes a Sage/SQL | Firewall bloquea rango VPN | Logs del firewall; Test-NetConnection | Crear reglas explícitas para la address pool |
No llega nada por nombre, solo por IP | Servicios DNS en DC con errores | Eventos DNS en el DC; nslookup | Revisar reenviadores y zonas; reiniciar servicio si aplica |
Solo falla desde casa | Subred de casa coincide con la corporativa | Revisar IP local (ipconfig ) | Renumerar o usar prefijos más específicos |
Pruebas rápidas que ahorran horas
# Conectado a la VPN (cliente)
ping <IPdelDC>
ping fileserver.dominio.local
tracert 8.8.8.8
tracert fileserver
PowerShell: puertos típicos
Test-NetConnection fileserver -CommonTCPPort SMB
Test-NetConnection sqlserver -Port 1433
Comprobar rutas y DNS
route print
nslookup fileserver
nslookup google.com
Si cambiaste DNS recientemente
ipconfig /flushdns
Errores típicos y cómo evitarlos
- NIC del DC apuntando a DNS públicos: evita 8.8.8.8 en el DC. Usa tus DCs y configura reenviadores.
- RRAS sin NAT en túnel completo: recuerda marcar “Interfaz pública con NAT habilitado”.
- GPO de mapeo con nombres cortos: mapea con FQDN (
\\fileserver.dominio.local\compartido
). - Subredes superpuestas: renumera la oficina a un prefijo privado poco común (p. ej., 10.123.0.0/16) o segmenta por VLAN.
- Ignorar IPv6: si no lo usas, deshabilítalo en la interfaz VPN o fuerza preferencia por IPv4 para evitar resoluciones AAAA inalcanzables.
- Sin rutas de retorno: el router core debe saber devolver tráfico al rango de la VPN.
Guía exprés de corrección
Si optas por split tunneling:
- Desmarca el gateway remoto o usa
Set-VpnConnection -SplitTunneling $true
. - Publica rutas a todas las subredes internas (NPS → MS-Route/Framed-Route o
Add-VpnConnectionRoute
). - Entrega DNS del dominio y sufijo; valida con
nslookup
. - Revisa firewall/ACL para el rango VPN.
Si optas por túnel completo:
- Mantén gateway remoto habilitado en el cliente.
- Activa NAT en la interfaz pública de RRAS y marca la VPN como privada.
- Comprueba la ruta por defecto del servidor y la política del firewall perimetral.
- Asegura que el DNS del dominio resuelve Internet (reenviadores o root hints) y entrégalo al cliente.
Ejemplo práctico de configuración
Address pool de VPN y DNS en RRAS:
- RRAS → botón derecho servidor → Propiedades → IPv4.
- Selecciona Rango de direcciones estáticas (ej.: 10.99.50.1–10.99.50.200).
- Define servidores DNS: 10.99.0.10 y 10.99.0.11 (tus DCs).
Rutas estáticas a VLAN internas:
- RRAS → IPv4 → Rutas estáticas → Agregar ruta:
- Destino: 10.99.20.0, Máscara: 255.255.255.0, Siguiente salto: 10.99.0.1 (router core).
- Destino: 10.99.30.0, Máscara: 255.255.255.0, Siguiente salto: 10.99.0.1.
Cliente Windows con split tunneling y rutas:
Set-VpnConnection -Name "EmpresaVPN" -SplitTunneling $true -PassThru
Add-VpnConnectionRoute -ConnectionName "EmpresaVPN" -DestinationPrefix "10.99.20.0/24"
Add-VpnConnectionRoute -ConnectionName "EmpresaVPN" -DestinationPrefix "10.99.30.0/24"
Mapeo de unidades estable por FQDN (script de inicio de sesión):
New-PSDrive -Name "S" -PSProvider FileSystem -Root "\\fileserver.dominio.local\shared" -Persist
Consejos de seguridad
- Para split tunneling, aplica EDR/antivirus de última generación, firewall de endpoint y políticas de bloqueo de lateral movement.
- Evalúa Always On VPN con certificados (túnel de dispositivo) y políticas MDM para endurecer clientes.
- Registra y supervisa el tráfico VPN (RADIUS accounting, eventos RRAS, NetFlow en el edge).
Preguntas frecuentes
¿Por qué RDP al DC funciona pero no accedo a archivos o SQL?
Porque el DC suele estar en la misma subred que la address pool de VPN; sin rutas a otras VLAN o sin DNS correcto, los demás servicios quedan fuera de alcance.
¿Dónde activo NAT exactamente?
En RRAS → IPv4 → NAT, agrega la NIC externa como pública con NAT y la interfaz VPN como privada.
¿Puedo forzar split tunneling con IKEv2?
Sí. Usa Set-VpnConnection -SplitTunneling $true
y añade rutas con Add-VpnConnectionRoute
.
¿Qué hago si mi red de casa es 192.168.1.0/24 como la oficina?
Renumerar es lo ideal. Temporalmente, crea rutas más específicas para la oficina (p. ej., divide en /25 o usa prefijos 10.x) o levanta un segundo SSID/red en casa con un prefijo distinto.
¿Necesito WINS o NetBIOS?
No para la mayoría. Con DNS bien configurado y mapeos por FQDN es suficiente.
Resumen final
Diagnóstico más probable: falta de NAT en túnel completo, DNS del dominio no entregado a los clientes, firewall/ACL bloqueando el rango VPN o subredes superpuestas. Dos caminos válidos:
- Split tunneling: desmarcar gateway remoto o usar
SplitTunneling
, publicar rutas (NPS o PowerShell) y entregar DNS del dominio + sufijo. - Túnel completo: mantener gateway remoto y habilitar NAT en RRAS, verificar ruta por defecto y que DNS del dominio resuelva Internet.
Checklist rápido: DNS del cliente hacia DC, resolución de nombres interna y externa, rutas correctas (route print
), puertos permitidos para SMB/SQL/Sage, y evitar subredes que se pisan. Tras corregir, con split tunneling Internet fluye por la red local y los recursos internos por la VPN; con túnel completo + NAT, todo funciona a través de la VPN.
En resumen: decide split o túnel completo; si es split, publica rutas y cuida DNS. Si es túnel completo, activa NAT en RRAS y verifica la ruta por defecto. En ambos casos entrega DNS del dominio, revisa firewall/ACL para el rango de la VPN y evita subredes superpuestas.