Internet no funciona al conectarse al VPN corporativo en Windows: causas, diagnóstico y soluciones (con y sin split tunneling)

¿Te conectas a la VPN corporativa y, de inmediato, Internet “desaparece” en el navegador, Slack u otras apps, mientras que un Google Meet o un huddle de Slack que ya estaba en curso sigue funcionando? Aquí tienes causas, comprobaciones y soluciones claras para Windows, tanto con como sin split tunneling.

Índice

Resumen de la situación

Al activar el VPN de la empresa, a menudo se instala una ruta por defecto (0.0.0.0/0) hacia el túnel. Si el extremo corporativo no publica salida a Internet (o la fuerza vía proxy y no te lo aplica) las nuevas conexiones quedan bloqueadas. Las sesiones ya establecidas (por ejemplo, una videollamada iniciada antes) continúan hasta que caducan porque aprovechan estados previos en la NAT o el firewall.

Síntomas típicos

El navegador deja de cargar páginas justo después de conectar el VPN.
Slack o Teams no se reconectan; los huddles o videollamadas previas siguen activas.
No puedes iniciar nuevas conexiones (RDP, SSH, túneles adicionales, etc.).
Resolver DNS puede fallar de forma intermitente, o resuelve pero no hay tráfico saliente.
La desconexión del VPN restaura Internet al instante.

En dos líneas (resumen ejecutivo)

Arreglo inmediato (si tu empresa lo permite): desmarcar “Usar puerta de enlace predeterminada en la red remota” en IPv4 del adaptador VPN (split tunneling).
Si se exige túnel completo: elevar a TI para que habiliten salida a Internet/proxy y DNS adecuados a través del VPN; desde el cliente no hay una solución duradera sin cambios del lado corporativo.

Por qué sucede: una explicación en lenguaje claro

Windows decide por dónde sacar cada paquete comparando rutas y métricas. Al conectar un VPN corporativo, es normal que inyecte la ruta por defecto (0.0.0.0/0) con una métrica baja para que todo el tráfico “vaya por el túnel”. Si el concentrador de VPN no ofrece Internet (o lo condiciona a un proxy PAC no configurado en tu equipo), todas las conexiones nuevas se quedan sin salida. Las conexiones previas pueden mantenerse porque el firewall/NAT conserva estados mientras el flujo esté activo.

Además, los clientes de VPN pueden cambiar DNS, proxy y métricas de interfaz al vuelo. Si el VPN fuerza DNS internos que no resuelven dominios públicos o impone un proxy que tu sistema no aplica, tendrás síntomas de “sin Internet” pese a estar conectado.

Cómo corroborarlo en minutos

Con el VPN conectado:

Abre Símbolo del sistema (CMD) o PowerShell como administrador.
Revisa las rutas: route print -4 Si ves una entrada 0.0.0.0 0.0.0.0 cuyo Gateway es el adaptador del VPN, y a partir de ese momento no navegas, la apuesta fuerte es: la salida a Internet no está disponible del lado corporativo.
Comprueba DNS: nslookup www.microsoft.com Si falla con el VPN pero funciona sin él, hay un problema de resolución o de proxy.
Prueba conectividad básica: ping 1.1.1.1 ping 8.8.8.8 Si esto responde pero un ping www.microsoft.com no, el bloqueo está en DNS.
En PowerShell, prueba: Test-NetConnection www.bing.com -Port 443 Resolve-DnsName www.bing.com

Indicador	Qué esperas ver	Interpretación
`route print -4`	Ruta `0.0.0.0/0` vía la interfaz VPN	El VPN toma todo el tráfico (túnel completo)
`nslookup` falla	Tiempo de espera agotado o servidor no responde	Problema de DNS del lado VPN o de proxy
Meet/Huddle sigue pero nuevas pestañas no cargan	Sesiones antiguas OK, nuevas NO	Rutas/proxy cambian solo para flujos nuevos

Solución en Windows: habilitar split tunneling desmarcando la puerta de enlace remota

Efecto: el tráfico a Internet sale por tu red local y solo el tráfico corporativo viaja por el túnel.

Abre Panel de control → Centro de redes y recursos compartidos → Cambiar configuración del adaptador.
Haz clic derecho sobre el adaptador del VPN → Propiedades.
Pestaña Red → selecciona Protocolo de Internet versión 4 (TCP/IPv4) → Propiedades.
Haz clic en Avanzadas… → pestaña Configuración de IP.
Desmarca: “Usar puerta de enlace predeterminada en la red remota”.
Acepta todo y reconecta el VPN.

Esta acción ha resuelto el problema en múltiples casos reales.
Advertencia: algunas organizaciones prohíben el split tunneling por seguridad. Si es tu caso, no lo apliques y pasa a la siguiente solución.

Si no encuentras la casilla

Asegúrate de estar en Avanzadas… → IPv4 del adaptador VPN correcto.
Si usas un cliente propietario (AnyConnect, GlobalProtect, FortiClient, Zscaler, etc.) o hay políticas de grupo (GPO), la opción puede estar oculta o forzada. Solo TI puede cambiarlo.
Si la conexión se creó en Configuración > VPN de Windows, abre ncpa.cpl y repite los pasos sobre el adaptador del VPN, no en la app genérica.

Variante controlada: enrutar solo subredes corporativas

Si tu empresa lo permite, puedes dejar sin puerta de enlace remota y definir rutas específicas a las redes internas (una forma más ordenada de split tunneling):

route add &lt;red.corp&gt; mask &lt;máscara&gt; &lt;gateway_vpn&gt; metric 1 -p

Consulta a TI las subredes (por ejemplo, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) y la puerta de enlace del túnel. Evita “adivinar” para no romper tráfico interno.

Solución sin split tunneling: Internet a través del VPN

Si la política corporativa exige túnel completo, la navegación debe salir por el propio VPN. Esto se corrige en el concentrador o mediante políticas gestionadas, no desde el PC del usuario:

Publicar una ruta por defecto hacia Internet y realizar NAT de salida en el perímetro corporativo.
Proveer y aplicar el proxy corporativo (PAC/WPAD) dentro del túnel si es obligatorio; empujarlo vía GPO o por el propio cliente VPN.
Asegurar DNS funcional para dominios públicos (forwarders válidos) o un fallback permitido.
Verificar que no exista una política de “bloquear Internet al estar en VPN” pensada para sesiones de mantenimiento.
Alinear el manejo de IPv6: si el VPN no tuneliza IPv6, Windows podría preferirlo y “agujerear” sesiones; la pasarela debe soportarlo o despriorizarlo correctamente.

Quién	Acción requerida	Detalle clave
Redes/Seguridad	Salida a Internet	NAT + política que permita tráfico de usuarios VPN
TI Endpoints	Proxy PAC/WPAD	Distribuir y forzar en el navegador/sistema
DNS	Resolución pública	Resolver dominios externos sin latencia ni bloqueos

Solución si el problema es DNS o el “stack” local

Si las políticas lo permiten, prueba estos pasos de saneamiento en Windows (consola de administrador):

ipconfig /flushdns
netsh winsock reset
shutdown /r /t 0

Luego revisa el proxy: Opciones de Internet → Conexiones → Configuración de LAN. Marca “detección automática” o especifica el script PAC si tu empresa lo requiere. Si usas proxy del sistema para servicios WinHTTP:

netsh winhttp import proxy source=ie   (importa desde Internet Options)
netsh winhttp reset proxy              (para limpiar si toca)

Comprueba las métricas de interfaz para evitar rutas “ganadoras” no deseadas:

Get-NetIPInterface | Sort-Object InterfaceMetric | Format-Table InterfaceAlias,AddressFamily,InterfaceMetric

Preferible dejar Métrica automática activada. Si TI lo autoriza, puedes ajustar de forma fina:

Set-NetIPInterface -InterfaceAlias "Ethernet" -AutomaticMetric Enabled
o, si TI lo pide:
Set-NetIPInterface -InterfaceAlias "Tu VPN" -InterfaceMetric 5

Comprobaciones rápidas de diagnóstico

Con el VPN conectado, ejecuta: route print Si ves una 0.0.0.0/0 por el adaptador VPN y no navegas, el problema está en la salida/proxy del lado corporativo.
Prueba: nslookup www.microsoft.com con y sin VPN para detectar fallos de DNS.

Clientes VPN: particularidades a tener en cuenta

AnyConnect: opciones como “Tunnel All Traffic” o “Allow Local LAN Access” pueden estar forzadas por perfil. El split tunneling suele definirse en el ASA/Firepower; si no te aparece, TI lo bloquea.
GlobalProtect: modo Full Tunnel por defecto; el portal/gateway decide rutas, DNS y proxy. Puede ocultar el tráfico local si no se configura lista de exclusiones.
FortiClient: perfiles SSL-VPN ip-pool y rutas empujadas por el firewall. Si no se publica 0.0.0.0/0 o no hay política de salida, Internet se corta.
Zscaler/ZPA: puede exigir que todo el tráfico web pase por su agente; sin política de bypass o sin credenciales, el navegador aparenta “sin Internet”.

En todos los casos, si la interfaz de usuario no muestra la casilla de puerta de enlace remota o split tunneling, no es un fallo tuyo: es la política aplicada desde el servidor o por GPO.

Preguntas frecuentes

¿Por qué las sesiones iniciadas antes continúan?
Porque la NAT/el firewall mantiene un estado para esos flujos. El cambio de rutas afecta a conexiones nuevas; las existentes siguen hasta que expira su temporizador.

¿Es seguro el split tunneling?
Depende del riesgo aceptable. Separar tráfico corporativo e Internet reduce latencia y ancho de banda del túnel, pero expone al equipo a la red local sin el perímetro corporativo. Por esa razón muchas empresas lo deshabilitan.

¿Debo desactivar IPv6?
No es recomendable de forma general. Lo correcto es que TI tunelice IPv6 o ajuste la preferencia para evitar “fugas” o agujeros negros de rutas.

¿Puedo usar DNS públicos como 1.1.1.1 o 8.8.8.8?
Solo si TI lo autoriza. Algunos VPN bloquean consultas fuera de sus resolvers para evitar fugas, y forzar DNS públicos puede romper servicios internos.

¿Qué tiene que ver el proxy PAC?
Si la empresa requiere PAC/WPAD, el tráfico web puede estar bloqueado hasta que el navegador use ese archivo. Sin PAC válido, “no hay Internet” aunque exista salida física.

Checklist para elevar a TI

Cuando abras un ticket, adjunta:

Fecha/hora del incidente y ubicación (oficina, casa, tethering).
Cliente VPN y versión, tipo de túnel (SSL/IPsec) y si es equipo gestionado o BYOD.
Capturas o salida de: route print -4 ipconfig /all nslookup www.microsoft.com Test-NetConnection www.bing.com -Port 443
Si con el VPN desconectado navegas con normalidad.
Si usas proxy y cómo está configurado (automático, PAC, manual).

Plantilla de informe para copiar/pegar

Resumen: Al conectar el VPN corporativo, pierdo navegación web y apps. Sesiones previas (Meet/Huddle) se mantienen activas.
Fecha/Hora: 
Ubicación/Red: (casa/oficina/tethering) _
Cliente/Versión VPN: _
Sistema: Windows (versión/edición/build) 
Proxy: (PAC/WPAD/manual) 
Pruebas:
- route print -4: la ruta 0.0.0.0/0 apunta al adaptador VPN [Sí/No]
- nslookup www.microsoft.com con VPN [OK/Falla]
- Test-NetConnection www.bing.com -Port 443 [OK/Falla]
Adjuntos: salidas de comandos e imágenes.

Glosario rápido

Término	Definición breve
Ruta por defecto (`0.0.0.0/0`)	Camino que usa el sistema para todo destino no conocido.
Split tunneling	Solo el tráfico corporativo va por el VPN; Internet sale directo.
PAC/WPAD	Archivo/script que indica al navegador qué proxy usar.
Métrica de interfaz	Preferencia numérica: menor métrica, mayor prioridad de ruta.
DNS corporativo	Resolver usado dentro del túnel; puede no resolver dominios públicos si no está bien configurado.

Buenas prácticas para evitar reincidencias

No toques políticas gestionadas por GPO ni perfiles del cliente VPN fuera de lo aprobado.
Evita desactivar el firewall para “probar”; no soluciona rutas/DNS/proxy y te expone innecesariamente.
Si usas varios adaptadores (Ethernet, Wi‑Fi, USB, vSwitch), desconecta los que no necesites para reducir complejidad de rutas.
Tras cambios de proxy/DNS, reinicia el navegador o limpia cachés (ipconfig /flushdns).
Documenta la red doméstica (router, CGNAT, repetidores); a veces el problema solo aparece en ciertas topologías.

Conclusión

Cuando al conectarte a la VPN corporativa “mueres” para Internet, casi siempre es por una ruta por defecto desviada al túnel sin que el extremo corporativo ofrezca salida web (o sin que tu equipo aplique el proxy/DNS requerido). Si tu empresa permite split tunneling, desmarcar la puerta de enlace remota suele restaurar la navegación en segundos. Si exige túnel completo, la solución real pasa por TI: habilitar salida a Internet (y/o proxy PAC) y garantizar DNS funcional desde el propio túnel. Las pruebas con route print, nslookup y Test-NetConnection te darán, en minutos, el dato objetivo que necesitan para arreglarlo de raíz.