VPN conectado pero sin internet en Windows: lista de comprobación de rutas y métricas

Guion de diagnóstico rápido

Cuando alguien te escribe “VPN conectada pero sin internet”, no quieres una discusión filosófica sobre tunelización. Quieres un árbol de decisiones que termine
con una solución o con una causa raíz escalable. Aquí está la vía rápida.

Primero: confirma qué significa realmente “sin internet”

• ¿Puedes hacer ping a una IP? Si ping 1.1.1.1 funciona pero las webs no, tienes un problema de DNS, no de conexión a Internet.
• ¿Puedes resolver DNS? Si nslookup falla o resuelve respuestas sólo internas, es un problema de selección de servidores DNS, NRPT o sufijos DNS.
• ¿Puedes alcanzar recursos internos? Si lo interno funciona pero lo externo no, probablemente tengas un túnel forzado / ruta por defecto vía VPN sin salida a Internet.
• ¿Todo falla? Si fallan tanto lo interno como lo externo, sospecha selección de rutas, problemas de métricas de interfaz o bloqueos por firewall/WFP.

Segundo: revisa rutas por defecto y métricas

La mayoría de incidentes “conectado pero sin internet” en Windows se reducen a: la ruta por defecto equivocada (0.0.0.0/0) ganó, o ganó con una métrica que al ordenador le pareció “razonable”
y al humano, una locura.

• Inspecciona rutas: route print o Get-NetRoute.
• Identifica qué interfaz posee la ruta por defecto y qué métrica tiene.
• Decide si quieres túnel completo (todo el tráfico por la VPN) o túnel dividido (solo subredes corporativas por la VPN).

Tercero: valida la ruta DNS y la política

• ¿Qué servidores DNS están en uso? Get-DnsClientServerAddress.
• ¿NRPT está forzando dominios específicos a DNS de la VPN? Get-DnsClientNrptPolicy.
• ¿El servidor DNS de la VPN es alcanzable por la ruta seleccionada? Si no, la resolución de nombres falla primero.

Cuarto: prueba la ruta con tracert y enlaces de interfaz

• tracert -d 1.1.1.1 muestra qué puerta de enlace estás usando realmente.
• Test-NetConnection te dice si es un problema de enrutamiento, DNS o filtrado por puerto.

Quinto: decide dónde arreglar

Si eres usuario: puedes ajustar métricas, alternar opciones de túnel dividido o arreglar DNS. Si eres operador de la VPN: necesitas desplegar una configuración sensata que no
secuestre rutas por defecto sin proporcionar egress y DNS.

Tu modelo mental: rutas, métricas, DNS y “conectado”

“Conectado” significa que el túnel está levantado, no que Internet sea accesible

Los clientes VPN informan “conectado” cuando el plano de control está bien: autenticación correcta, la interfaz del túnel existe, intercambio de claves, keepalives respondidos.
Eso no es el plano de datos. El plano de datos es donde tus paquetes sobreviven o mueren.

Windows acepta con gusto un adaptador VPN, instala rutas y luego enruta tu tráfico hacia un agujero negro si esas rutas apuntan a una puerta de enlace que no puede o
no debe reenviar tus paquetes. Esto no es que Windows sea tonto; Windows es obediente.

Windows elige una ruta según la longitud de prefijo y luego la métrica

La selección de rutas es mayormente determinista:

1. Gana el prefijo más largo. Un /32 vence a un /24 y ese a un /0. Si tu VPN instala rutas específicas para redes corporativas, esas deberían ganar a tu ruta por defecto local.
2. Luego gana la métrica. Si dos rutas tienen la misma longitud de prefijo, Windows usa la métrica de ruta más baja, y también considera la métrica de interfaz.
3. Y luego se complica. Windows puede considerar “métrica automática”, la velocidad de la interfaz, y a veces actualizaciones o reasignaciones pueden reordenarlo inesperadamente.

Por eso “el internet muere cuando se conecta la VPN” a menudo significa: llegó una nueva ruta 0.0.0.0/0 vía VPN con una métrica más baja que la de tu Wi‑Fi,
pero el extremo de la VPN no proporciona salida general a Internet (o la bloquea intencionalmente). Resultado: túnel completo sin una salida funcional.

DNS es un plano de fallo separado, y falla más ruidosamente

Los humanos experimentamos Internet a través de nombres, no de IPs. Los problemas de DNS aparecen como “sin internet” incluso cuando el enrutamiento está bien. Windows añade complejidad:

• Varias interfaces pueden tener servidores DNS; Windows elige según métricas de interfaz y políticas de sufijo.
• Los clientes VPN pueden empujar servidores DNS internos y sufijos de búsqueda.
• NRPT (Name Resolution Policy Table) puede forzar ciertos dominios (o todos) a servidores DNS de la VPN.
• DNS sobre HTTPS puede eludir tu plan DNS de la VPN y crear un comportamiento split‑brain confuso.

El túnel dividido es una decisión de política, no una técnica de depuración

La gente alterna el túnel dividido como si fuera “apagar y encender otra vez”. A veces funciona, pero no es magia. Cambia tu tabla de rutas y tu modelo de amenaza.
Si tu política de seguridad exige túnel completo, entonces “arreglar” significa hacer que el túnel completo sea funcional (incluyendo egress a Internet o bloqueos explícitos con mensajes al usuario),
no habilitar silenciosamente el túnel dividido porque se siente mejor.

Broma #1: El enrutamiento VPN es como la política de oficina: la persona con la métrica más baja gana, y nadie admite quién la puso.

Hechos e historia que conviene conocer (porque Windows no inventó el caos)

• El legado PPP y marcación aún importa. El comportamiento VPN de Windows hereda supuestos de enlaces PPP donde “red remota” a menudo significaba “úsala como puerta de enlace predeterminada”.
• Los debates sobre túnel dividido son antiguos. Las empresas discutieron esto hace décadas para marcación y primeros IPSec: seguridad quiere túnel completo; operaciones quiere egress predecible.
• La métrica automática se creó para ayudar. Windows introdujo métricas automáticas de interfaz para preferir enlaces “más rápidos”, pero los adaptadores virtuales pueden confundir esa heurística.
• NRPT vino de las necesidades de DirectAccess. Microsoft necesitaba una forma de resolver dominios corporativos vía DNS corporativo dejando los dominios públicos aparte—enrutamiento DNS basado en políticas.
• IPv6 no “rompió” las VPN; la adopción parcial sí. Muchas VPN son solo IPv4, mientras Windows prefiere IPv6 cuando está disponible; la descoordinación crea conectividad parcial extraña.
• La búsqueda de sufijos DNS es anterior a la web. Fue diseñada para el nombrado empresarial y sigue siendo responsable de muchos incidentes de “¿por qué esto resuelve mal?”.
• WFP hizo el filtrado más potente. Windows Filtering Platform permite a clientes VPN y agentes de endpoint aplicar políticas de red; también puede bloquear tráfico en silencio.
• NCSI no es Internet. El estado “Sin acceso a Internet” de Windows se basa en sondas y heurísticas; tus paquetes pueden estar bien mientras el icono se queja, o al revés.

Tareas prácticas: comandos, qué significa la salida y qué decides

Estos son los movimientos que separan “reinicié” de “lo arreglé”. Cada tarea tiene:
un comando, un ejemplo de salida realista, qué significa y la decisión que tomas.

Tarea 1: Confirma inventario de interfaces y estado

cr0x@server:~$ powershell -NoProfile -Command "Get-NetAdapter | Sort-Object -Property Status,Name | Format-Table -Auto Name,Status,LinkSpeed,InterfaceDescription"
Name                      Status LinkSpeed  InterfaceDescription
Wi-Fi                     Up     866.7 Mbps Intel(R) Wi-Fi 6 AX201 160MHz
Ethernet                  Down   0 bps      Realtek PCIe GbE Family Controller
Wintun Userspace Tunnel   Up     1 Gbps     WireGuard Tunnel
TAP-Windows Adapter V9    Down   0 bps      TAP-Windows Adapter V9

Significado: Tienes al menos dos adaptadores “Up”: Wi‑Fi y el túnel VPN.
Eso es normal. Lo que importa es cuál posee la ruta por defecto y el DNS.

Decisión: Si el adaptador VPN está Down, detente aquí: tienes un problema de establecimiento/autenticación del túnel, no “sin internet”. Si está Up, continúa con las rutas.

Tarea 2: Muestra la tabla de enrutamiento en términos humanos

cr0x@server:~$ powershell -NoProfile -Command "route print"
===========================================================================
Interface List
 12...18 56 80 1a 2b 3c ......Intel(R) Wi-Fi 6 AX201 160MHz
 34...00 ff 12 34 56 78 ......Wintun Userspace Tunnel
===========================================================================
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0      10.8.0.1        10.8.0.2       5
          0.0.0.0          0.0.0.0   192.168.1.1    192.168.1.123    25
        10.8.0.0    255.255.255.0         On-link       10.8.0.2     261
     192.168.1.0    255.255.255.0         On-link   192.168.1.123    281
===========================================================================

Significado: Tienes dos rutas por defecto. La ruta por defecto de la VPN tiene métrica 5, por lo que gana. Eso es túnel completo ahora.
Si el servidor VPN no hace NAT/egress hacia Internet, tu Internet queda efectivamente inaccesible.

Decisión: Decide la política: si se pretende túnel completo, verifica que la puerta de enlace VPN proporcione egress a Internet y lo permita. Si se pretende túnel dividido, elimina la ruta por defecto de la VPN y añade solo las rutas corporativas.

Tarea 3: Identifica la ruta por defecto ganadora precisamente (PowerShell)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetRoute -DestinationPrefix '0.0.0.0/0' | Sort-Object -Property RouteMetric,InterfaceMetric | Format-Table -Auto ifIndex,InterfaceAlias,NextHop,RouteMetric,InterfaceMetric,PolicyStore"
ifIndex InterfaceAlias           NextHop      RouteMetric InterfaceMetric PolicyStore
34      Wintun Userspace Tunnel  10.8.0.1              5             10 ActiveStore
12      Wi-Fi                    192.168.1.1          25             25 ActiveStore

Significado: La interfaz VPN (ifIndex 34) es la ruta por defecto preferida.
La InterfaceMetric también importa; Windows suma/compara de formas que todavía sorprenden a la gente.

Decisión: Si necesitas Internet local mientras la VPN está activa, o bien subes las métricas de la VPN, deshabilitas “use default gateway on remote network” o configuras correctamente el túnel dividido.

Tarea 4: Confirma tu IP de egress pública antes/después de la VPN

cr0x@server:~$ powershell -NoProfile -Command "curl.exe -s ifconfig.me; echo"
203.0.113.44

Significado: Esa es tu IP pública de egress. Ejecútalo de nuevo tras conectar la VPN. Si cambia a un rango corporativo de egress, el túnel completo está activo y el egress funciona.
Si se queda colgado, tu enrutamiento envía tráfico dentro de un túnel sin salida.

Decisión: Si el comando se cuelga solo cuando la VPN está conectada, céntrate en la ruta por defecto y en la política de egress/NAT de la VPN.

Tarea 5: Prueba si el problema es DNS o enrutamiento (ping a IP vs nombre)

cr0x@server:~$ powershell -NoProfile -Command "ping -n 2 1.1.1.1"
Pinging 1.1.1.1 with 32 bytes of data:
Reply from 1.1.1.1: bytes=32 time=17ms TTL=57
Reply from 1.1.1.1: bytes=32 time=16ms TTL=57

Ping statistics for 1.1.1.1:
    Packets: Sent = 2, Received = 2, Lost = 0 (0% loss),

cr0x@server:~$ powershell -NoProfile -Command "ping -n 2 www.microsoft.com"
Ping request could not find host www.microsoft.com. Please check the name and try again.

Significado: La conectividad por IP existe; la resolución DNS falla. Eso no es “sin internet”, es “no hay un resolvedor al que puedas acceder” o “la política envía DNS al lugar equivocado”.

Decisión: Deja de tocar rutas por un momento. Inspecciona servidores DNS, reglas NRPT y si las consultas DNS salen por la interfaz esperada.

Tarea 6: Inspecciona servidores DNS por interfaz

cr0x@server:~$ powershell -NoProfile -Command "Get-DnsClientServerAddress -AddressFamily IPv4 | Format-Table -Auto InterfaceAlias,ServerAddresses"
InterfaceAlias           ServerAddresses
Wi-Fi                    {192.168.1.1}
Wintun Userspace Tunnel  {10.8.0.53, 10.8.0.54}

Significado: Wi‑Fi usa el DNS del router doméstico. La VPN empuja resolutores internos. Dependiendo de la política, Windows puede preferir el DNS de la VPN para todo,
o usar un comportamiento de multienlace “inteligente” que no siempre es tan inteligente.

Decisión: Si el DNS de la VPN es solo interno y estás en túnel completo sin egress, los nombres públicos fallan. O bien proporciona egress o configura división de DNS (NRPT) para que los nombres públicos vayan a resolutores públicos.

Tarea 7: Comprueba políticas NRPT (enrutamiento DNS por dominio)

cr0x@server:~$ powershell -NoProfile -Command "Get-DnsClientNrptPolicy | Select-Object -First 5 | Format-List"
NameSpace : .corp.example
NameServers : 10.8.0.53,10.8.0.54
DirectAccessDnsServers :
DnsSecValidationRequired : False
Comment : VPN policy

NameSpace : .
NameServers : 10.8.0.53

Significado: Si ves una regla para NameSpace : ., eso es “todos los dominios”. Fuerza todas las consultas DNS al resolutor de la VPN.
Eso puede ser correcto para túnel completo; es horrible para túnel dividido si el DNS de la VPN no puede resolver dominios públicos o no es alcanzable.

Decisión: Si se pretende túnel dividido, elimina la regla NRPT de captura total y mantén solo los espacios de nombres corporativos.

Tarea 8: Valida la resolución DNS explícitamente y ve qué servidor responde

cr0x@server:~$ powershell -NoProfile -Command "Resolve-DnsName www.microsoft.com -Type A | Select-Object -First 3"
Name                                     Type TTL   Section IPAddress
----                                     ---- ---   ------- ---------
www.microsoft.com                        A    20    Answer  184.25.56.101

cr0x@server:~$ powershell -NoProfile -Command "nslookup www.microsoft.com 10.8.0.53"
Server:  vpn-dns-1
Address:  10.8.0.53

*** vpn-dns-1 can't find www.microsoft.com: Non-existent domain

Significado: El servidor DNS interno no resuelve dominios públicos (por diseño o por error). Si Windows está enviando todo el DNS allí, la navegación se rompe.

Decisión: O configura el DNS de la VPN para reenviar consultas públicas, o deja de forzar el DNS público a través de ella.

Tarea 9: Demuestra qué ruta siguen tus paquetes (tracert sin DNS)

cr0x@server:~$ powershell -NoProfile -Command "tracert -d 1.1.1.1"
Tracing route to 1.1.1.1 over a maximum of 30 hops

  1    35 ms    34 ms    36 ms  10.8.0.1
  2     *        *        *     Request timed out.
  3     *        *        *     Request timed out.

Trace complete.

Significado: El salto 1 es la puerta de enlace VPN, y luego nada. Eso es clásico “ruta por defecto sobre la VPN, pero la VPN no reenvía a Internet”
(o bloquea ICMP más allá de la puerta de enlace, pero normalmente verás fallos también en TCP).

Decisión: Confirma si la VPN debería proporcionar egress a Internet. Si no es así, elimina la ruta por defecto y usa túnel dividido.

Tarea 10: Prueba conectividad TCP a un endpoint conocido y captura qué interfaz se usa

cr0x@server:~$ powershell -NoProfile -Command "Test-NetConnection 8.8.8.8 -Port 53 -InformationLevel Detailed"
ComputerName           : 8.8.8.8
RemoteAddress          : 8.8.8.8
RemotePort             : 53
InterfaceAlias         : Wintun Userspace Tunnel
SourceAddress          : 10.8.0.2
TcpTestSucceeded       : False
PingSucceeded          : True

Significado: ICMP ping funciona pero TCP/53 falla. Eso puede ser política en la VPN (bloqueo de salidas), un problema de firewall stateful o problemas de MTU/fragmentación.

Decisión: Si la interfaz es el túnel VPN y los puertos salientes están bloqueados, necesitas un cambio de política en la VPN (o túnel dividido) en lugar de ajustes del cliente.

Tarea 11: Comprueba el MTU en la interfaz VPN (asesino silencioso)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetIPInterface -AddressFamily IPv4 | Sort-Object -Property InterfaceAlias | Format-Table -Auto InterfaceAlias,NlMtu,InterfaceMetric,Dhcp"
InterfaceAlias           NlMtu InterfaceMetric Dhcp
Wi-Fi                    1500              25 Enabled
Wintun Userspace Tunnel  1420              10 Disabled

Significado: MTU 1420 es común para WireGuard; IPSec y algunas VPN SSL bajan más. Si el MTU es incorrecto, obtienes “algunos sitios funcionan, otros se quedan colgados”,
especialmente HTTPS con paquetes más grandes.

Decisión: Si los síntomas son parciales (pings pequeños funcionan; transferencias grandes se cuelgan), prueba con MTU menor o ajusta MSS en el gateway VPN.

Tarea 12: Confirma rutas IPv6 y si IPv6 está robando tráfico

cr0x@server:~$ powershell -NoProfile -Command "Get-NetRoute -AddressFamily IPv6 -DestinationPrefix '::/0' | Format-Table -Auto InterfaceAlias,NextHop,RouteMetric,InterfaceMetric"
InterfaceAlias           NextHop              RouteMetric InterfaceMetric
Wi-Fi                    fe80::1                     10             25
Wintun Userspace Tunnel  ::                          256             10

Significado: Ruta por defecto IPv6 vía Wi‑Fi existe y es preferida. Si tu “sin internet” ocurre sólo en ciertas aplicaciones, podrían estar intentando IPv6 primero.
Mientras tanto la VPN es solo IPv4 y tu DNS corporativo podría devolver registros AAAA que fallan.

Decisión: Si el acceso corporativo se rompe porque los clientes prefieren IPv6 que no atraviesa la VPN, o bien ofrece IPv6 sobre la VPN, o controla las respuestas DNS / desactiva IPv6 en el diseño del túnel (no como reflejo).

Tarea 13: Inspecciona ajustes de proxy WinHTTP (sí, aún existen)

cr0x@server:~$ powershell -NoProfile -Command "netsh winhttp show proxy"
Current WinHTTP proxy settings:

    Proxy Server(s) : 10.8.0.20:8080
    Bypass List     : (none)

Significado: Algunos scripts post‑conexión de VPN configuran un proxy. Si ese proxy solo es alcanzable vía VPN y el enrutamiento VPN está roto, los navegadores pueden fallar de formas confusas.
Algunas aplicaciones usan WinHTTP; otras usan WinINET; pueden discrepar.

Decisión: Si Internet falla solo en ciertas apps (o solo en servicios del sistema), arregla la alcanzabilidad del proxy o borra el proxy WinHTTP si está obsoleto.

Tarea 14: Comprueba la opción “usar puerta de enlace predeterminada en la red remota” (RAS/VPN)

cr0x@server:~$ powershell -NoProfile -Command "Get-VpnConnection -AllUserConnection | Select-Object Name,SplitTunneling,RememberCredential | Format-Table -Auto"
Name              SplitTunneling RememberCredential
----              -------------- ------------------
Corp-VPN          False          True

Significado: SplitTunneling False generalmente implica túnel completo (ruta por defecto a través de la VPN). Eso está bien si tu VPN está diseñada para ello.
Es un desastre si el extremo no proporciona egress.

Decisión: Cambia esto solo si la política lo permite. Si eres operador, arregla el perfil VPN y su método de distribución en lugar de pedir a los usuarios que lo alternen manualmente.

Tarea 15: Ajustar la métrica de interfaz (quirúrgico, pero a veces necesario)

cr0x@server:~$ powershell -NoProfile -Command "Set-NetIPInterface -InterfaceAlias 'Wi-Fi' -InterfaceMetric 10; Set-NetIPInterface -InterfaceAlias 'Wintun Userspace Tunnel' -InterfaceMetric 50"

cr0x@server:~$ powershell -NoProfile -Command "Get-NetIPInterface -AddressFamily IPv4 | Where-Object {$_.InterfaceAlias -in @('Wi-Fi','Wintun Userspace Tunnel')} | Format-Table -Auto InterfaceAlias,InterfaceMetric"
InterfaceAlias           InterfaceMetric
Wi-Fi                                10
Wintun Userspace Tunnel              50

Significado: Indicaste a Windows que prefiera Wi‑Fi cuando las rutas compiten.
Es una herramienta contundente y puede violar la política de túnel completo si no tienes cuidado.

Decisión: Usa métricas para resolver conflictos de prioridad de rutas, no para “vencer a la seguridad”. Si tu empresa requiere túnel completo, no distribuyas “trucos de métrica” como solución de soporte.

Tarea 16: Añadir una ruta específica de túnel dividido (ejemplo para subred corporativa)

cr0x@server:~$ powershell -NoProfile -Command "New-NetRoute -DestinationPrefix '10.20.0.0/16' -InterfaceAlias 'Wintun Userspace Tunnel' -NextHop '0.0.0.0' -RouteMetric 5"

cr0x@server:~$ powershell -NoProfile -Command "Get-NetRoute -DestinationPrefix '10.20.0.0/16' | Format-Table -Auto DestinationPrefix,InterfaceAlias,NextHop,RouteMetric"
DestinationPrefix InterfaceAlias           NextHop  RouteMetric
10.20.0.0/16       Wintun Userspace Tunnel  0.0.0.0          5

Significado: Estás enroutando explícitamente solo la subred corporativa hacia el túnel.
Para muchas tecnologías VPN, el siguiente salto “on-link” (0.0.0.0) es correcto porque la propia interfaz del túnel es el camino.

Decisión: Si el cliente VPN no gestiona rutas de forma fiable, puedes fijar rutas críticas. Pero prefiere arreglar la configuración empujada centralmente; la deriva es cómo el yo del futuro recibe llamadas de madrugada.

Tarea 17: Comprueba conexiones activas y direcciones fuente enlazadas

cr0x@server:~$ powershell -NoProfile -Command "Get-NetTCPConnection -State Established | Select-Object -First 5 LocalAddress,LocalPort,RemoteAddress,RemotePort,OwningProcess | Format-Table -Auto"
LocalAddress    LocalPort RemoteAddress   RemotePort OwningProcess
10.8.0.2        50214     10.8.0.53       53         1240
192.168.1.123   50215     93.184.216.34   443        8916
192.168.1.123   50216     142.250.72.14   443        8916

Significado: Tienes conexiones simultáneas originadas tanto desde VPN como desde Wi‑Fi. Eso puede ser normal con túnel dividido. También puede romper aplicaciones que esperan una única IP de origen estable.

Decisión: Si una aplicación concreta falla mientras otras funcionan, puede ser sensible a cambios de IP de origen. Enruta explícitamente los destinos de esa app, o usa túnel completo de forma consistente.

Tarea 18: Verifica el perfil de firewall de Windows y si la VPN te marcó como “Público” con reglas estrictas

cr0x@server:~$ powershell -NoProfile -Command "Get-NetConnectionProfile | Format-Table -Auto Name,InterfaceAlias,NetworkCategory,IPv4Connectivity"
Name          InterfaceAlias           NetworkCategory IPv4Connectivity
HomeNetwork   Wi-Fi                    Private         Internet
Corp-VPN      Wintun Userspace Tunnel  Public          LocalNetwork

Significado: La categoría de red de la VPN es Pública y solo muestra conectividad LocalNetwork. Algunas políticas de endpoint aplican reglas de firewall más estrictas en redes Públicas,
y algunos clientes VPN etiquetan mal el perfil.

Decisión: Si el tráfico está bloqueado solo cuando la VPN está activa y las rutas parecen correctas, inspecciona políticas de firewall/WFP y el etiquetado de perfiles en lugar de cambiar rutas al azar.

Broma #2: Las tablas de enrutamiento son el único lugar donde “gana el número más bajo” es una política que puedes aplicar sin que RRHH se meta.

Una cita para tener en el escritorio

“La esperanza no es una estrategia.” — James Cameron

Se aplica incómodamente bien al diagnóstico VPN: no esperes que los paquetes hayan ido a donde querías; demuestra a dónde fueron.

Errores comunes: síntoma → causa raíz → solución

Esta sección es deliberadamente específica. Si tu síntoma no está aquí, o es un problema más raro o pertenece a otra capa (autenticación, seguridad del endpoint, ISP).

1) “La VPN conecta, los sitios internos funcionan, Internet público muere”

• Causa raíz: Se instaló una ruta por defecto completa vía VPN, pero el egress/NAT de la VPN hacia Internet está deshabilitado o bloqueado.
• Solución: O bien (a) habilitar egress en el gateway VPN (NAT + política de firewall + registros), o (b) eliminar la ruta por defecto de la VPN y usar túnel dividido con prefijos corporativos explícitos.

2) “Ping a IP público funciona, las webs no cargan”

• Causa raíz: Las consultas DNS se envían a un servidor DNS inalcanzable o a un servidor interno que no reenvía dominios públicos.
• Solución: Ajustar el orden de servidores DNS, eliminar NRPT de captura total o configurar el resolutor interno para reenviar/resolver dominios públicos; asegurarse de que existan rutas al servidor DNS.

3) “Algunos sitios cargan, otros se quedan colgados (especialmente HTTPS)”

• Causa raíz: Problemas de MTU/MSS a través del túnel (fragmentación bloqueada, PMTUD en agujero negro), o bloqueos selectivos por firewall.
• Solución: Reducir MTU del túnel, clavar MSS en el gateway VPN, verificar comportamiento ICMP fragmentation-needed, o ajustar la política de firewall para TCP saliente.

4) “La VPN funciona en Wi‑Fi pero no en Ethernet (o al revés)”

• Causa raíz: Diferencias en métricas de interfaz causan distinta selección de ruta por defecto; la LAN corporativa usa opciones DHCP o proxy distintas; las políticas de VLAN difieren.
• Solución: Compara salidas de Get-NetRoute por entorno; establece métricas explícitas si es necesario; asegúrate de que las rutas VPN no choquen con subredes locales.

5) “La VPN dice conectada, pero DNS devuelve IPs internas extrañas para nombres públicos”

• Causa raíz: DNS split‑brain o secuestro DNS interno (intencional o accidental), a veces vía NRPT con regla “.”.
• Solución: Limita NRPT a espacios de nombres corporativos; asegúrate de que el DNS interno no sobrescriba zonas públicas a menos que realmente lo planees (y tengas un plan).

6) “Internet muere solo para una app (Teams, Outlook, navegador, gestor de paquetes)”

• Causa raíz: Configuración de proxy (WinHTTP vs WinINET), la app usa IPv6 primero, o la app se enlaza a una interfaz concreta y no soporta cambios de IP de origen.
• Solución: Comprueba netsh winhttp show proxy, verifica enrutamiento IPv6 y prueba con Test-NetConnection usando el host/puerto objetivo.

7) “La VPN conecta, pero no puedes alcanzar interno ni externo; la tabla de rutas parece correcta”

• Causa raíz: WFP/firewall bloquea, seguridad del endpoint interfiere, o el túnel está levantado pero sin plano de datos (claves erróneas, AllowedIPs incorrectos, selectores SA equivocados).
• Solución: Valida con Test-NetConnection hacia IPs internas; comprueba el perfil de firewall; para WireGuard verifica AllowedIPs; para IPSec verifica selectores de tráfico.

8) “Tras desconectar la VPN, Internet sigue roto hasta reiniciar”

• Causa raíz: Rutas persistentes, direcciones DNS obsoletas o configuración de proxy dejada por el cliente VPN.
• Solución: Eliminar rutas persistentes, resetear DNS a DHCP, limpiar proxy WinHTTP o reiniciar la pila de red (menos drástico que un reinicio completo).

Listas de verificación / plan paso a paso

Lista A: Triage de 5 minutos “¿es enrutamiento o DNS?”

1. Ejecuta ping 1.1.1.1. Si falla, probablemente tengas problemas de enrutamiento/firewall.
2. Ejecuta ping www.microsoft.com. Si el ping a IP funciona pero el nombre falla, céntrate en DNS.
3. Ejecuta route print e identifica la ruta 0.0.0.0/0 ganadora.
4. Ejecuta Get-DnsClientServerAddress y confirma que los servidores DNS son alcanzables por la ruta seleccionada.
5. Ejecuta tracert -d 1.1.1.1 para ver si el tráfico sale por la puerta de enlace VPN o por el router local.

Lista B: Sanidad del túnel completo (para operadores y on‑call)

Si tu organización exige túnel completo, asúmelo y haz que funcione. El túnel medio‑completo es donde nacen los incidentes.

1. Confirma que la VPN empuja una ruta por defecto con la métrica prevista.
2. Confirma que el gateway VPN proporciona egress a Internet (NAT) y tiene reglas de firewall que permitan tráfico saliente según la política.
3. Confirma que los servidores DNS empujados por la VPN pueden resolver zonas internas y dominios públicos (directamente o mediante reenvío).
4. Confirma el ajuste MTU/MSS para el tipo de túnel para evitar agujeros negros de paquetes grandes.
5. Registra las caídas de egress en el gateway VPN. Si no puedes ver caídas, discutirás con fantasmas.
6. Prueba la postura IPv6: o la soportas de extremo a extremo o la limitas deliberadamente para que los clientes no elijan una ruta muerta.

Lista C: Sanidad del túnel dividido (para quienes prefieren redes predecibles)

1. No empujes 0.0.0.0/0 sobre la VPN. Empuja solo prefijos corporativos.
2. Evita espacios de direcciones que colisionen con redes domésticas (las colisiones 192.168.0.0/16 son reales). Si no puedes evitarlas, usa NAT en el cliente o rediseña subredes corporativas.
3. Usa NRPT solo para espacios de nombres corporativos, no para . a menos que obligues deliberadamente todo el DNS.
4. Asegura que los servidores DNS corporativos sean alcanzables a través de las rutas del túnel (obvio, pero rutinariamente olvidado).
5. Sé consistente con la política de proxy: o proxy a través de VPN para apps internas, o no. Señales mixtas causan fallos mixtos.
6. Documenta qué tráfico debe ir por la VPN (control de versiones, CI/CD, repositorios internos de artefactos) y añade esos prefijos/rutas explícitamente.

Lista D: Acciones cliente para “desatascarme” sin romper la política

1. Desconecta y reconecta la VPN una vez (sí, una vez). Si la tabla de rutas cambia cada vez, es un bug que hay que reportar.
2. Vacía la caché DNS (ipconfig /flushdns) tras cambios de política DNS.
3. Reobtén DHCP en la interfaz física (ipconfig /renew) si el enrutamiento local parece incorrecto.
4. Comprueba y borra proxy WinHTTP si está obviamente obsoleto (netsh winhttp reset proxy)—pero solo si tu entorno no lo requiere.
5. Recolecta evidencia antes de escalar: tabla de rutas, servidores DNS, políticas NRPT y un par de pruebas fallidas con marcas de tiempo.

Conjunto útil de comandos “evidencia” (copiar/pegar para escalados)

cr0x@server:~$ powershell -NoProfile -Command "Get-Date; hostname; Get-NetAdapter | ? Status -eq 'Up' | ft -Auto Name,ifIndex,LinkSpeed; Get-NetRoute -DestinationPrefix '0.0.0.0/0' | ft -Auto; Get-DnsClientServerAddress -AddressFamily IPv4 | ft -Auto; Get-DnsClientNrptPolicy | ft -Auto NameSpace,NameServers; Test-NetConnection 1.1.1.1 -InformationLevel Detailed; Resolve-DnsName www.microsoft.com -ErrorAction SilentlyContinue"

Significado: Esto captura la hora, el nombre del host, interfaces activas, rutas por defecto, configuración DNS, NRPT, conectividad básica y un intento de resolución DNS.
Es la diferencia entre escalar y pedir ayuda sin información.

Decisión: Si no puedes arreglarlo localmente, envía este paquete al equipo de VPN/red. Aun así te harán una pregunta más, pero al menos no será “¿cuál es tu tabla de rutas?”

Tres microrelatos corporativos (anonimizados, plausibles y técnicamente molestos)

Microrelato 1: El incidente causado por una suposición errónea

Una empresa mediana desplegó un nuevo perfil VPN para contratistas. La idea era sencilla: los contratistas solo deberían alcanzar un par de aplicaciones web internas.
El concentrador VPN se configuró solo para enrutamiento interno—sin egress a Internet, sin NAT, ACLs salientes estrictas. Seguridad aprobó. Todos se sintieron responsables.

La suposición errónea apareció como una avalancha en el helpdesk: “La VPN conecta pero no hay internet.” El helpdesk lo interpretó como un problema del ISP porque empezaba a la misma hora
cada mañana. En realidad, comenzaba cuando la gente abría sus portátiles, conectaba la VPN y luego intentaba usar flujos MFA alojados en dominios públicos.
Sus navegadores no podían resolver ni alcanzar endpoints de identidad externos porque la VPN empujaba una ruta por defecto.

El equipo VPN insistía en que nunca tuvo la intención de tunelizar Internet. El equipo de endpoints insistía en que nunca tuvo la intención de cambiar rutas por defecto. Ambos tenían razón, y a la vez se
les pasó por alto un tercer actor: la plantilla de perfil que clonaron tenía “enviar todo el tráfico” activado por defecto, porque venía de un despliegue antiguo de túnel completo.

La solución no fue heroica. Eliminaban la ruta por defecto del perfil de contratistas, empujaron prefijos corporativos explícitos para las dos aplicaciones y añadieron una regla NRPT
solo para el dominio corporativo. Al día siguiente, la cola del helpdesk quedó en silencio. Luego alguien preguntó por qué tardó tres días. La respuesta fue, dolorosamente, “porque nadie miró route print.”

Microrelato 2: La optimización que salió mal

Un equipo de TI empresarial quería mejorar el rendimiento VPN, así que ajustaron las métricas de interfaz para preferir agresivamente el adaptador VPN. Métrica más baja, prioridad mayor, menos ambigüedad.
Funcionó en su laboratorio y en la Wi‑Fi corporativa. Los gráficos mejoraron. Lo desplegaron.

Entonces empleados remotos en redes domésticas inestables empezaron a reportar intermitentes “conectado pero sin internet” y “algunos sitios se cuelgan”. El adaptador VPN ahora ganaba decisiones de enrutamiento
incluso cuando el túnel estaba activo pero degradado. Mientras tanto, la Wi‑Fi aún tenía una ruta por defecto sana que podría haber llevado tráfico público durante los episodios de degradación de la VPN.
Pero las métricas se habían “optimizado” para eliminar ese respaldo.

La parte desagradable: el plano de control del túnel permanecía lo bastante estable como para mostrar “Conectado”, mientras el plano de datos sufría blackholing por MTU y pérdida de paquetes.
Así que los usuarios mantenían la VPN activa y culpaban “a Internet”. En realidad, su enrutamiento estaba bloqueado en un camino peor sin conmutación de respaldo.

El rollback mejoró las cosas de inmediato. La solución a largo plazo fue más madura: mantener túnel completo para dispositivos gestionados que lo necesiten, pero añadir comprobaciones de salud y mejor ajuste MTU;
y para poblaciones con túnel dividido, evitar forzar rutas por defecto vía trucos de métrica. Optimizar la métrica fue una victoria local que se convirtió en un outage global.

Microrelato 3: La práctica aburrida pero correcta que salvó el día

Una firma de servicios financieros tenía un entorno VPN que todos llamaban “viejo”, que en lenguaje corporativo significa “estable pero pasado de moda”. Su secreto no era hardware mágico.
Era disciplina operativa: cada cambio de perfil VPN requería una captura antes/después de rutas, servidores DNS, reglas NRPT y un conjunto de pruebas automatizadas desde una VM Windows limpia.

Un martes, una rotación de certificados coincidió con una actualización de cliente. Los usuarios empezaron a reportar fallos de navegación tras conectar la VPN. Los gateways VPN parecían bien.
La autenticación estaba bien. El túnel estaba levantado. La trampa clásica.

Porque tenían la práctica aburrida, el ingeniero de guardia comparó los paquetes de evidencia antes/después y detectó que la nueva actualización del cliente había introducido una regla NRPT de captura total
para ., forzando todo el DNS a resolutores internos. Los resolutores internos eran alcanzables, pero estaban configurados para no reenviar dominios públicos—otra vez, por política.

No “intentaron cosas al azar”. Eliminó la regla de captura total en el perfil, mantuvo NRPT para los espacios de nombres internos y desplegó la configuración corregida.
El incidente se contuvo rápido. Nadie escribió una entrada heroica. Ese es el punto: las prácticas aburridas previenen los outages emocionantes.

Preguntas frecuentes

1) ¿Por qué Windows dice “Conectado” si no puedo cargar páginas web?

Porque el plano de control del cliente VPN está conectado. Tus rutas y ajustes DNS aún pueden estar mal, y Windows no lo marcará como “desconectado”.
Piensa en ello como “túnel establecido”, no “paquetes entregados”.

2) ¿Cuál es la causa más común de “VPN conectada pero sin internet”?

Una ruta por defecto (0.0.0.0/0) preferida vía la VPN cuando el gateway VPN no proporciona egress a Internet (o lo bloquea).
Es un desajuste de enrutamiento + política, no un misterio.

3) ¿Cómo distinguo si es DNS o enrutamiento?

Haz ping a una IP (como 1.1.1.1) y luego a un nombre (como www.microsoft.com). Si la IP funciona y el nombre falla, es DNS.
Si ambos fallan, es enrutamiento/firewall o el plano de datos del túnel.

4) ¿Debo habilitar simplemente el túnel dividido para arreglarlo?

Solo si tu política de seguridad lo permite y tu VPN está diseñada para túnel dividido. De lo contrario estarás “arreglando” cambiando la política.
La solución correcta para túnel completo es hacer que el túnel completo funcione: egress, reenvío DNS, ajuste MTU y política clara de firewall.

5) ¿Por qué tengo dos rutas por defecto y por qué importa?

Puedes tener múltiples rutas por defecto (Wi‑Fi y VPN). Windows elige según métricas. La métrica más baja gana, y tu tráfico la sigue.
Si la ganadora es un callejón sin salida, tu Internet la seguirá hacia el vacío.

6) ¿Qué es NRPT y por qué rompe la navegación?

NRPT es la tabla de políticas de resolución de nombres de Windows. Si una política fuerza todos los dominios a DNS de la VPN (regla para .),
y ese servidor DNS no puede resolver dominios públicos o no es alcanzable, la navegación web falla aunque el enrutamiento IP esté bien.

7) ¿Por qué al desconectar la VPN a veces no se restaura Internet?

Algunos clientes VPN dejan rutas persistentes, ajustes DNS o configuración de proxy. Windows seguirá usándolos hasta que se eliminen o reemplacen.
Comprueba rutas persistentes y listas de servidores DNS, y resetea proxies obsoletos si es necesario.

8) ¿Puede IPv6 ser el culpable?

Sí. Windows prefiere IPv6 cuando puede. Si tu VPN no transporta IPv6 pero DNS devuelve registros AAAA para servicios internos o externos,
algunas apps intentarán IPv6 primero y parecerán rotas. Verifica rutas por defecto IPv6 y si el diseño de la VPN soporta IPv6 intencionalmente.

9) ¿Cambiar la métrica de interfaz es una buena solución a largo plazo?

Es una herramienta, no una estrategia. Las métricas pueden resolver desempates de rutas, pero usarlas para sobrescribir un perfil VPN mal diseñado crea deriva en las máquinas.
Prefiere arreglar las rutas y políticas DNS empujadas por la VPN de forma central.

10) ¿Qué evidencia debo enviar al equipo de VPN?

Rutas por defecto y métricas, servidores DNS, políticas NRPT y un par de pruebas fallidas (Test-NetConnection y Resolve-DnsName).
Incluye marcas de tiempo y si el problema ocurre solo en ciertas redes (Wi‑Fi doméstica, tethering, hotel).

Conclusión: próximos pasos que evitan reincidencias

“Conectado pero sin internet” rara vez es aleatorio. Normalmente es una de tres cosas: la ruta por defecto equivocada ganó, el DNS fue forzado a un lugar poco útil, o el túnel está levantado pero el plano de datos está roto
(a menudo MTU/firewall). No lo arreglas por adivinanza. Lo arreglas leyendo la tabla de rutas como si fuera un archivo de log.

Pasos prácticos siguientes:

1. Realiza el triage de 5 minutos: ping a IP vs ping a nombre, luego propiedad de la ruta por defecto.
2. Decide túnel completo vs túnel dividido y alinea rutas + política DNS con esa decisión.
3. Si operas la VPN: deja de distribuir perfiles que instalan una ruta por defecto sin proporcionar egress y DNS que puedan resolver lo que los usuarios necesitan.
4. Estandariza un conjunto de comandos “evidencia” y hazlo obligatorio para escalados. No porque seas duro, sino porque reduce el tiempo de outage.

La victoria no es solo dejar un portátil en línea. Es hacer que el siguiente incidente sea tan aburrido que nadie recuerde que ocurrió.