La VPN rompe el acceso LAN local: Túnel dividido en Windows, bien hecho

febrero 8, 2026 • febrero 8, 2026 • Lectura: 27 min • Views: 1

¿Te fue útil?

Todo funciona hasta que te conectas a la VPN corporativa. Entonces tu NAS local desaparece, la impresora indica “sin conexión” y ese interruptor IoT deja de existir en la práctica. La VPN no solo añadió un camino seguro al trabajo; silenciosamente reconfiguró toda tu red.

Esto casi nunca es “un error de Windows”. Son el enrutamiento y el DNS haciendo exactamente lo que se les dijo—solo que no era lo que esperabas. Vamos a solucionarlo correctamente: con túnel dividido, rutas explícitas, métricas previsibles y pruebas que te digan qué decisión tomar a continuación.

Qué se rompe en realidad cuando muere el acceso LAN

Cuando una VPN “rompe el acceso LAN local”, la gente culpa a la encriptación, los túneles, los firewalls o al ambiente. En la práctica, suele ser una de estas cosas:

Tu ruta por defecto cambió (0.0.0.0/0 y/o ::/0) para apuntar al adaptador VPN. Ahora “cualquier cosa que no sea explícitamente local” entra en el túnel—incluyendo aquello que creías local.
Perdiste la ruta hacia la subred local porque la VPN inyectó una ruta más amplia que gana. Ejemplo: estás en 192.168.1.0/24 en casa, pero la VPN empuja 192.168.0.0/16 y de repente tu LAN doméstica es “corporativa”.
La selección de ruta es correcta pero las métricas no. Windows elige la ruta con la máscara más específica; si hay empate, gana la métrica más baja. Si el adaptador VPN tiene una métrica muy baja, también ganará con demasiada frecuencia.
Cambios en DNS. Tus servidores DNS pasan a resolutores corporativos que no conocen nombres locales (o los rechazan deliberadamente), así que “nas” y “impresora” dejan de resolverse aunque la conectividad IP esté bien.
La política bloquea la LAN local. Algunos clientes de VPN añaden filtros (reglas WFP) para impedir el acceso local mientras estás conectado. Eso no es túnel dividido; eso es “sin salida local”.
IPv6 entró en escena. Windows prefiere IPv6 cuando está disponible. Una VPN que solo maneja IPv4 y una LAN que anuncia IPv6 puede provocar comportamientos sorprendentes a menos que conozcas qué rutas existen.

La solución raramente es “activar el túnel dividido” como una casilla mágica. La solución es: definir qué debe ir por el túnel, definir qué debe permanecer local, y luego aplicarlo con rutas y comportamiento DNS que puedas explicar a la siguiente persona de guardia.

Nueve hechos e historias breves que puedes usar en reuniones (o incidentes)

El túnel dividido fue polémico antes de estar de moda. Las VPN empresariales tempranas preferían “túnel completo” porque reducía el riesgo de unir redes corporativas y no confiables en el mismo equipo.
Windows ha usado la misma lógica básica de selección de rutas durante décadas. La coincidencia de prefijo más largo gana; si hay empate, gana la métrica más baja. Las GUIs cambian. Las reglas no.
“Usar puerta de enlace predeterminada en la red remota” era la trampa UX original. En clientes Windows antiguos, esa casilla decidía si la VPN instalaba una ruta 0.0.0.0/0 vía el túnel.
Los clientes VPN corporativos empezaron a empujar rutas agresivamente a medida que las redes crecían. Cuando tienes docenas de prefijos internos, es más fácil empujar “rutas resumen”. Así es como accidentalmente devoras subredes domésticas.
Always On VPN convirtió el túnel dividido en un problema de gobernanza. Una vez que la VPN está “siempre conectada”, la higiene de rutas y DNS deja de ser opcional y pasa a ser rutina.
DNS es el campo de batalla moderno. Muchos programas de seguridad se preocupan más por la fuga de DNS que por el enrutamiento bruto, así que los clientes VPN manipulan DNS de formas cada vez más creativas.
NRPT existe porque Windows entendió que DNS necesita política, no esperanza. La tabla de políticas de resolución de nombres permite decir “estos dominios usan estos servidores DNS”, que es túnel dividido para nombres.
La autotunelización de métricas puede ser “útil” hasta que no lo es. Windows puede asignar métricas de interfaz según la velocidad del enlace. Tu NIC virtual de VPN puede reportar valores raros y ganar la guerra de enrutamiento.
El espacio IP privado superpuesto es la tragedia de oficina de larga duración. RFC1918 dio a todos los mismos tres rangos privados; no sorprende que mucha gente reutilizara los mismos /24. Luego llegaron las VPN con rutas resumen y se comieron las redes domésticas en el desayuno.

Guía rápida de diagnóstico (comprueba primero/segundo/tercero)

Si necesitas pasar de “la VPN rompió mi LAN” a la causa raíz en cinco minutos, hazlo en este orden:

Primero: determina si es enrutamiento o DNS

Intenta alcanzar un dispositivo local por dirección IP (no por nombre). Si la IP funciona pero el nombre no, estás en terreno DNS.
Si la IP falla, estás en enrutamiento/firewall. No adivines; lee la tabla de rutas.

Segundo: inspecciona las rutas que capturarían tu LAN

Busca 0.0.0.0/0 vía VPN (túnel completo).
Busca rutas privadas grandes/resumidas empujadas por la VPN (como 192.168.0.0/16) que se solapen con tu subred doméstica.
Confirma que la ruta de la subred local aún existe y tiene métricas sensatas.

Tercero: comprueba si el cliente VPN está aplicando bloqueo de LAN local

Algunos clientes instalan reglas de Windows Filtering Platform. El enrutamiento puede ser perfecto y los paquetes aún morir.
Revisa reglas de firewall activas, cambios de perfil y si de repente se aplicó el perfil “Público”.

Cuarto: verifica métricas de adaptador y prioridad de interfaz

Si dos rutas tienen especificidad similar, la métrica decide. Una métrica VPN de 1 es básicamente una opinión, y suele ser la equivocada.

Eso es tu escalera de triaje: IP vs DNS, luego rutas, luego filtros, luego métricas.

Tareas prácticas: comandos, salidas, decisiones (12+)

Todo esto son “tareas reales”: un comando, qué significa la salida y qué haces después. Usa PowerShell elevado cuando sea necesario. No estás aquí para hacer clic; estás aquí para controlar el sistema.

Tarea 1: Identificar si la resolución de nombres es el único problema

cr0x@server:~$ ping 192.168.1.10
Pinging 192.168.1.10 with 32 bytes of data:
Reply from 192.168.1.10: bytes=32 time=2ms TTL=64

Ping statistics for 192.168.1.10:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss)

Qué significa: Existe conectividad de Capa 3 al dispositivo. El enrutamiento hacia la LAN probablemente está bien.

Decisión: Si “ping nas” falla pero hacer ping a su IP funciona, salta la modificación de rutas y ve directo a las tareas de DNS.

Tarea 2: Demuestra la ruta de la búsqueda de nombres (y qué servidor DNS respondió)

cr0x@server:~$ nslookup nas
Server:  corp-dns01.example
Address:  10.20.30.40

*** corp-dns01.example can't find nas: Non-existent domain

Qué significa: Tu sistema está consultando el DNS corporativo, que no conoce el hostname local “nas”.

Decisión: Arregla el comportamiento DNS dividido (NRPT, listas de sufijo de búsqueda o servidores DNS locales) en lugar de tocar rutas.

Tarea 3: Inspecciona la configuración de interfaz activa (detecta la toma de control por la VPN)

cr0x@server:~$ ipconfig /all

Ethernet adapter Ethernet:
   IPv4 Address. . . . . . . . . . : 192.168.1.50
   Default Gateway . . . . . . . . : 192.168.1.1
   DNS Servers . . . . . . . . . . : 192.168.1.1

PPP adapter CorpVPN:
   IPv4 Address. . . . . . . . . . : 10.99.12.34
   Default Gateway . . . . . . . . : 10.99.12.34
   DNS Servers . . . . . . . . . . : 10.20.30.40
   DNS Suffix Search List. . . . . : corp.example

Qué significa: La VPN se anuncia como puerta de enlace y empuja DNS corporativo. Esto es típico de túnel completo (o de un túnel dividido mal configurado).

Decisión: Revisa la tabla de rutas a continuación para ver si 0.0.0.0/0 ahora va vía CorpVPN.

Tarea 4: Lee la tabla de rutas como si lo sintieras

cr0x@server:~$ route print
===========================================================================
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0       10.99.12.34     10.99.12.34     5
        10.0.0.0        255.0.0.0       10.99.12.34     10.99.12.34     5
     192.168.1.0    255.255.255.0      192.168.1.50    192.168.1.50    25
===========================================================================

Qué significa: La ruta por defecto está vía la VPN. La ruta de la subred local todavía existe, por lo que el tráfico local debería seguir siendo local—salvo que exista una ruta superpuesta más amplia o un filtrado que lo bloquee.

Decisión: Busca rutas que se solapen con tu red doméstica (como 192.168.0.0/16) o comprueba si el cliente VPN bloquea la LAN local vía firewall/WFP.

Tarea 5: Busca la clásica ruta superpuesta que se come tu LAN

cr0x@server:~$ route print | findstr 192.168.
     192.168.0.0    255.255.0.0       10.99.12.34     10.99.12.34     5
     192.168.1.0    255.255.255.0      192.168.1.50    192.168.1.50    25

Qué significa: Tienes tanto 192.168.0.0/16 vía VPN como 192.168.1.0/24 local. El /24 es más específico, así que debería ganar. Pero si tu LAN en realidad es 192.168.0.0/24, estás jodido: el /16 de la VPN gana sobre tu /24 solo si falta o está mal la ruta local.

Decisión: Confirma tu prefijo local real y asegúrate de que exista una ruta local explícita para él. Si la VPN empuja una ruta que coincide exactamente con tu prefijo local, solo cambios de política (o renumeración) lo arreglan limpiamente.

Tarea 6: Muestra qué interfaz usará Windows para alcanzar una IP local

cr0x@server:~$ powershell -NoProfile -Command "Find-NetRoute -RemoteIPAddress 192.168.1.10 | ft -AutoSize"
DestinationPrefix NextHop     InterfaceAlias RouteMetric ifIndex PolicyStore
----------------- -------     -------------- ---------- ------ -----------
192.168.1.0/24    0.0.0.0     Ethernet       25         12     ActiveStore

Qué significa: Para 192.168.1.10, Windows selecciona Ethernet (local). Bien.

Decisión: Si esto muestra la interfaz VPN en su lugar, necesitas arreglar la especificidad de rutas o las métricas (o eliminar la ruta conflictiva que instaló la VPN).

Tarea 7: Confirma si la conexión VPN está configurada para túnel dividido

cr0x@server:~$ powershell -NoProfile -Command "Get-VpnConnection -Name 'CorpVPN' | Select-Object Name,SplitTunneling,RememberCredential,AuthenticationMethod | Format-List"
Name                 : CorpVPN
SplitTunneling       : False
RememberCredential   : True
AuthenticationMethod : MSChapv2

Qué significa: El túnel dividido está deshabilitado. Espera una ruta por defecto vía la VPN.

Decisión: Si la política lo permite, habilita el túnel dividido y luego añade rutas corporativas explícitas (no al revés).

Tarea 8: Habilitar túnel dividido (VPN integrado de Windows)

cr0x@server:~$ powershell -NoProfile -Command "Set-VpnConnection -Name 'CorpVPN' -SplitTunneling $True -PassThru | Select-Object Name,SplitTunneling"
Name    SplitTunneling
----    --------------
CorpVPN True

Qué significa: Windows dejará de forzar una ruta por defecto a través de la VPN (dependiendo de cómo el servidor VPN empuje rutas). Ahora necesitas rutas explícitas hacia las redes corporativas.

Decisión: Añade de inmediato rutas para los prefijos corporativos (o confía en las rutas empujadas si son correctas). Verifica con route print después de reconectar.

Tarea 9: Añadir una ruta explícita a una subred corporativa vía la interfaz VPN

cr0x@server:~$ powershell -NoProfile -Command "Add-VpnConnectionRoute -ConnectionName 'CorpVPN' -DestinationPrefix '10.20.0.0/16' -PassThru | ft -AutoSize"
ConnectionName DestinationPrefix
-------------- -----------------
CorpVPN        10.20.0.0/16

Qué significa: Estás haciendo túnel dividido correctamente: solo el tráfico corporativo va por el túnel.

Decisión: Repite para todos los prefijos internos requeridos. No añadas rutas enormes “por si acaso”; así es como vuelves a capturar la LAN del usuario.

Tarea 10: Validar que la ruta por defecto volvió a la puerta de enlace local (después de reconectar)

cr0x@server:~$ route print | findstr /c:" 0.0.0.0"
          0.0.0.0          0.0.0.0        192.168.1.1     192.168.1.50    10

Qué significa: El tráfico de Internet/ruta por defecto es local otra vez. La VPN debe manejar solo los prefijos que hayas enrutado hacia ella.

Decisión: Si 0.0.0.0 aún apunta a la VPN, tu cliente/servidor está imponiendo túnel completo. No luches contra el SO: pasa a “permitir LAN local” en política o ajustes del cliente (si están disponibles).

Tarea 11: Inspecciona métricas de interfaz (el desempate silencioso)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetIPInterface -AddressFamily IPv4 | Sort-Object InterfaceMetric | Select-Object InterfaceAlias,InterfaceMetric,NlMtu,ConnectionState | ft -AutoSize"
InterfaceAlias InterfaceMetric NlMtu ConnectionState
-------------- -------------- ----- ---------------
CorpVPN        5              1400  Connected
Ethernet       25             1500  Connected
Wi-Fi          55             1500  Disconnected

Qué significa: La VPN tiene una métrica más baja, así que si instala cualquier ruta de especificidad similar, probablemente ganará.

Decisión: Si el enrutamiento es inestable, fija métricas explícitas: sube la métrica de la VPN o baja la de la LAN según convenga. Ten cuidado: algunos clientes VPN restablecen métricas al conectar.

Tarea 12: Establecer una métrica de interfaz para el adaptador VPN (cuando lo controlas)

cr0x@server:~$ powershell -NoProfile -Command "Set-NetIPInterface -InterfaceAlias 'CorpVPN' -InterfaceMetric 50"

Qué significa: La ausencia de salida es normal. Cambiaste el orden de preferencia.

Decisión: Compruébalo con Get-NetIPInterface y luego con Find-NetRoute. Si el cliente VPN lo vuelve a cambiar, necesitas política del cliente o configuración del proveedor, no métricas afinadas manualmente.

Tarea 13: Traza la ruta del paquete a un host “local” que falla

cr0x@server:~$ tracert 192.168.1.10

Tracing route to 192.168.1.10 over a maximum of 30 hops

  1    25 ms    24 ms    25 ms  10.99.12.34
  2     *        *        *     Request timed out.

Qué significa: Tu tráfico “local” está yendo a la VPN (el primer salto es la gateway/interfaz VPN). Eso es un problema de enrutamiento, no de la impresora.

Decisión: Arregla la tabla de rutas: asegúrate de que exista una ruta on-link explícita para tu subred local vía Ethernet/Wi‑Fi, y elimina/evita rutas VPN en conflicto.

Tarea 14: Comprueba si el perfil de firewall de Windows cambió (y bloquea descubrimiento/SMB)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetConnectionProfile | ft -AutoSize"
Name           InterfaceAlias NetworkCategory IPv4Connectivity IPv6Connectivity
----           -------------- --------------- ---------------- ---------------
HomeNetwork    Ethernet       Private         Internet         NoTraffic
CorpVPN        CorpVPN        Public          Internet         NoTraffic

Qué significa: La interfaz VPN está en perfil Público. Algunos entornos también hacen que el perfil principal pase a Público, lo que rompe el descubrimiento de archivos/impresoras y las reglas entrantes.

Decisión: Si tu perfil LAN se volvió Público, corrige la categoría de red cuando la política lo permita o ajusta reglas de firewall para los servicios requeridos (SMB, mDNS, LLMNR, WS-Discovery) con cuidado.

Tarea 15: Inspecciona reglas de firewall activas que bloqueen la subred local mientras la VPN está conectada

cr0x@server:~$ powershell -NoProfile -Command "Get-NetFirewallRule -Enabled True -Direction Outbound | ? DisplayName -match 'VPN|Block|Local' | Select-Object -First 8 DisplayName,Action,Profile | ft -AutoSize"
DisplayName                          Action Profile
-----------                          ------ -------
Block local subnets when VPN active  Block  Any

Qué significa: El cliente VPN (o la política corporativa) instaló una regla de bloqueo explícita. Las modificaciones de ruta no ayudarán.

Decisión: Necesitas una excepción en la política (“permitir LAN local”), una postura de VPN distinta o un diseño de red de confianza separado. No hagas cambios de rutas a ciegas frente a un bloqueo de firewall.

Tarea 16: Verifica servidores DNS y asignación DNS por interfaz

cr0x@server:~$ powershell -NoProfile -Command "Get-DnsClientServerAddress -AddressFamily IPv4 | ft -AutoSize"
InterfaceAlias ServerAddresses
-------------- --------------
Ethernet       {192.168.1.1}
CorpVPN        {10.20.30.40,10.20.30.41}

Qué significa: DNS está dividido por interfaz, pero el comportamiento del resolvedor de Windows puede aún preferir DNS corporativo para nombres sin sufijo o determinadas búsquedas.

Decisión: Usa FQDNs para servicios corporativos, configura una lista de sufijos de búsqueda intencionada o utiliza NRPT para que los dominios corporativos vayan al DNS corporativo mientras todo lo demás permanece local.

Túnel dividido en Windows: cómo funciona realmente

Túnel dividido significa: solo el tráfico destinado a redes remotas específicas pasa por la VPN. Todo lo demás—tu LAN local, tu salida a Internet doméstica, la interfaz web de la impresora—permanece en la red local.

Túnel completo significa: la VPN se convierte en tu puerta de enlace por defecto. Eso es más simple para equipos de seguridad (un único punto de control) y a veces obligatorio por cumplimiento. También es la razón por la que terminas intentando imprimir a través de un centro de datos a tres estados de distancia.

En Windows, el túnel dividido se expresa finalmente como rutas:

En túnel completo, obtienes 0.0.0.0/0 vía VPN.
En túnel dividido, obtienes solo prefijos corporativos vía VPN.
Las rutas de subred local permanecen on-link (Ethernet/Wi‑Fi).

Tres modelos que verás en el mundo real

VPN integrada de Windows (IKEv2/SSTP/L2TP) con Set-VpnConnection
Funciona bien cuando controlas ambos extremos o puedes empujar rutas sensatas. Bueno para implementaciones Always On VPN.
Cliente de terceros que inyecta rutas y reglas de firewall
A veces puedes configurar el túnel dividido en el cliente, pero el cliente también puede imponer “bloquear LAN local” con reglas WFP. Lee la configuración del proveedor; no asumas que las opciones de Windows aplican.
“Túnel dividido” que no lo es
Algunas configuraciones se llaman túnel dividido porque excluyen un par de servicios de Internet, pero aún envían todos los rangos privados por el túnel. Eso no es túnel dividido; eso es miseria selectiva.

Qué deberías hacer, con opinión

Prefiere el túnel dividido basado en rutas. Declara prefijos corporativos explícitamente. Manténlos lo más estrechos posible. Las rutas resumen están bien solo si controlas el plan de direcciones y no coincidirá con redes de usuarios.
No confíes en la “magia de métricas”. Las métricas resuelven empates, no son herramientas de diseño. Usa prefijos explícitos primero.
Asume que ocurrirán solapamientos RFC1918. Si tu red corporativa usa 192.168.0.0/16, básicamente decidiste pelear con todos los routers domésticos del planeta.

Una frase para tener en mente durante revisiones de diseño VPN: parafraseando a John Ousterhout: “La buena ingeniería trata de gestionar la complejidad.” La complejidad del enrutamiento siempre acumula intereses.

DNS: la forma más silenciosa en que la VPN rompe tu LAN

El enrutamiento recibe toda la atención porque es visible: tablas de rutas, gateways, contadores de saltos. Las fallas de DNS parecen fantasmas. Escribes \\nas y Windows se encoge de hombros. Intentas \\192.168.1.10 y funciona. Eso no es sobrenatural; es el resolvedor haciendo lo que está configurado para hacer.

Por qué el DNS de la VPN causa dolor local

El DNS corporativo no conoce tus nombres locales. Los nombres de una sola etiqueta como nas o printer a menudo dependen de sufijos de búsqueda locales, mDNS, LLMNR o del proxy DNS del router doméstico.
El DNS corporativo puede bloquear intencionalmente búsquedas inversas privadas. Los equipos de seguridad a veces endurecen los resolutores para rechazar consultas “raras” desde clientes, incluidas ciertos patrones de reverse DNS locales.
Windows puede preferir el DNS de una interfaz para ciertas consultas. Existe DNS por interfaz, pero el comportamiento del resolvedor depende de sufijos, políticas y de si el cliente VPN ajusta la prioridad de la interfaz.

Estrategia práctica de DNS que no te hará llorar

Usa FQDNs para servicios corporativos. No dependas del sufijo de búsqueda para herramientas de producción. Es cómodo hasta que deja de serlo.
Usa NRPT para enviar dominios corporativos al DNS corporativo. Eso es túnel dividido limpio para nombres.
Mantén DNS local para nombres locales. Si quieres que nas se resuelva, tu sistema necesita un resolvedor que lo conozca (router doméstico, servidor DNS local, archivo hosts como último recurso).

Broma #1: DNS es como una guía telefónica, excepto que suele estar más equivocada y aún así la llamas “infraestructura crítica”.

NRPT y estrategias de resolución de nombres (truquillos para Windows Pro)

NRPT (Name Resolution Policy Table) te permite decir: “Para estos espacios de nombres, usa estos servidores DNS.” Es la versión adulta de esperar que Windows elija la interfaz DNS correcta.

Patrón típico:

Para corp.example y quizá un par de zonas internas, usa servidores DNS corporativos accesibles por VPN.
Para todo lo demás, continúa usando DNS local (router de casa, ISP, lo que provea tu LAN).

NRPT suele gestionarse vía Group Policy en empresas. Pero para diagnóstico es útil inspeccionar lo que ya existe.

cr0x@server:~$ powershell -NoProfile -Command "Get-DnsClientNrptPolicy | Select-Object Namespace,NameServers,DirectAccessDnsServers,Comment | ft -AutoSize"
Namespace      NameServers          DirectAccessDnsServers Comment
---------      ----------          ---------------------- -------
.corp.example  {10.20.30.40,10.20.30.41} {}

Qué significa: Las consultas por *.corp.example irán a los servidores DNS corporativos listados.

Decisión: Si no hay NRPT y tu VPN está secuestrando DNS globalmente, pide DNS dividido basado en NRPT o configura políticas DNS/puerta de enlace según la postura de seguridad de tu organización.

Tres historias corporativas desde la trinchera

Mini-historia 1: El incidente causado por una suposición errónea (espacio de direcciones solapado)

Una empresa mediana desplegó un nuevo perfil de cliente VPN tras una fusión. El equipo de redes había resumido rutas internas para mantener la configuración ordenada: un prefijo privado amplio, empujado a todos los clientes. En papel, era elegante. En la realidad, asumía que los empleados no tendrían los mismos rangos RFC1918 en casa.

El lunes por la mañana, la cola de helpdesk se volvió frenética. “No puedo imprimir”, “no alcanzo el NAS de casa”, “Zoom funciona pero la app del termostato no”, y el mejor: “La consola de juegos de mi hijo dice que está en otro país.” Ese último no fue estrictamente culpa de la VPN, pero no ayudó a la moral.

Los primeros respondedores buscaron reglas de firewall y problemas de drivers porque la VPN se conectaba correctamente y las apps corporativas funcionaban. El truco fue notar un patrón: las fallas siempre iban a dispositivos tipo 192.168.0.0. La gente con redes domésticas 10.0.0.0/24 estaban mayormente bien.

Las tablas de rutas contaron la historia: una gran ruta 192.168.0.0/16 vía la VPN, “porque la corporación usa muchos 192.168.*.” Los routers domésticos de los empleados también usaban… 192.168.*. Los paquetes para la impresora doméstica entraban en el túnel, llegaban a un router corporativo que no tenía idea de dónde estaba la “HP de Bob”, y morían en silencio.

La solución no fue ingeniosa; fue responsable. Dejaron de empujar el prefijo amplio y en su lugar empujaron subredes corporativas específicas. A largo plazo, se comprometieron con un plan de direcciones interno que no colisionara con las configuraciones de consumidor. El incidente terminó cuando reemplazaron una suposición por un inventario.

Mini-historia 2: La optimización que salió mal (métricas y “VPN más rápida”)

Otra organización recibió una queja de rendimiento: “La VPN es lenta.” Alguien notó que la métrica del adaptador VPN era mayor que la del Wi‑Fi, y decidió “optimizar” forzando la métrica de la VPN a 1. El cambio se desplegó vía un script. Fue rápido. También fue equivocado.

Para algunos usuarios, las apps corporativas parecieron más rápidas. Para muchos otros, los servicios locales se degradaron de forma sutil: copias de archivos al NAS de casa empezaron a fallar, las copias de seguridad locales se detenían, y las impresoras se volvieron poco fiables. No completamente muertas—suficientemente inconsistentes como para generar tickets interminables sin un único culpable evidente.

Lo que pasó es clásico: con una métrica VPN súper baja, Windows prefería la VPN para rutas que no estaban totalmente definidas, especialmente cuando múltiples interfaces estaban activas (Ethernet y Wi‑Fi) y algunas rutas tenían la misma especificidad. Añade algo de churn de DHCP y la selección de ruta se podía flipar en momentos inoportunos.

La reversión lo arregló. Luego hicieron la versión adulta: dejaron las métricas mayormente automáticas, habilitaron el túnel dividido correctamente y empujaron rutas corporativas explícitas. El rendimiento mejoró por las razones correctas: menos tráfico innecesario por el túnel, menos retransmisiones, menos flujos locales rotos.

Mini-historia 3: La práctica aburrida pero correcta que salvó el día (diagnóstico estándar y snapshots de rutas)

Un equipo de servicios financieros tenía una regla interna: cada incidente de acceso remoto llevaba un “snapshot de red” adjunto al ticket. Sin excepciones. Era aburrido. La gente se quejaba. Luego pagó por sí mismo repetidamente.

Cuando un nuevo perfil VPN provocó reportes dispersos de “LAN inalcanzable”, el ingeniero on-call no adivinó. Comparó dos snapshots de un usuario afectado: antes de conectar la VPN y después. La diferencia era obvia: una ruta por defecto vía VPN y una nueva regla de bloqueo nombrada exactamente por lo que hacía.

Porque tenían artefactos consistentes—ipconfig /all, route print, métricas de interfaz, servidores DNS—pudieron escalar con precisión: “Tu política cliente está instalando bloqueos de salida a subredes locales cuando está conectado. Esto no es un problema de rutas del usuario.”

El equipo de seguridad lo reconoció rápido porque era medible, no emocional. Crearon un grupo de excepción aprobado para usuarios que necesitaban acceso LAN local (entornos de laboratorio, técnicos en sitio) y documentaron el riesgo. La práctica aburrida—diagnósticos repetibles—mantuvo el debate anclado en hechos en lugar de capturas de pantalla.

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

Esta sección recoge lo que aparece en tickets, hilos de Slack y tus reuniones menos favoritas.

1) “La VPN se conectó, pero no puedo acceder a mi impresora/NAS”

Síntoma: El dispositivo local por nombre falla; a veces por IP también falla.

Causa raíz: Ruta por defecto de túnel completo vía la VPN, o la VPN bloquea la subred local vía firewall/WFP.

Solución: Si está permitido, habilita túnel dividido y añade rutas corporativas explícitas. Si la política bloquea la LAN local, solicita la opción “permitir LAN local” o un perfil de excepción. Valida con tracert e inspección de reglas de firewall.

2) “Por IP funciona, por nombre falla”

Síntoma: ping 192.168.1.10 funciona; ping nas falla.

Causa raíz: El DNS corporativo es ahora tu resolvedor principal y no puede resolver nombres locales.

Solución: Usa NRPT para dirigir dominios corporativos al DNS corporativo. Mantén DNS local para nombres locales. O usa FQDNs/entradas estáticas donde corresponda.

3) “Algunos IP locales funcionan, otros no”

Síntoma: Puedes alcanzar 192.168.1.1 pero no 192.168.1.10 mientras estás en la VPN.

Causa raíz: Rutas solapadas o una ruta resumen empujada que captura parte de la LAN, o una regla de bloqueo específica dirigida a rangos.

Solución: Compara Find-NetRoute para destinos que funcionan vs los que no. Elimina/evita rutas VPN conflictivas. Si es una regla de bloqueo, arregla la política en lugar de las rutas.

4) “Los recursos locales desaparecen solo en Wi‑Fi, no en Ethernet”

Síntoma: El comportamiento cambia según el medio de acceso.

Causa raíz: Subredes locales diferentes, métricas distintas, servidores DNS distintos o perfiles de firewall distintos por interfaz.

Solución: Comprueba Get-NetConnectionProfile y Get-NetIPInterface en ambas. Estandariza métricas y DNS por interfaz. Confirma rutas para el prefijo local exacto en el que te encuentras.

5) “Todo va lento después de habilitar túnel dividido”

Síntoma: Apps corporativas lentas, Internet bien.

Causa raíz: Faltan rutas corporativas, por lo que el tráfico se enruta mal (por ejemplo, sale localmente y falla al volver), o consultas DNS de dominios corporativos van a DNS público y se agotan.

Solución: Añade los prefijos corporativos correctos con Add-VpnConnectionRoute e implementa DNS dividido (NRPT). Valida con tracert a puntos finales corporativos y nslookup para FQDNs corporativos.

6) “La VPN funciona, pero solo una app interna es inaccesible”

Síntoma: La mayoría de recursos corporativos funcionan; una subred no.

Causa raíz: La ruta de esa subred no fue empujada/añadida, o solapa con un rango local y pierde.

Solución: Find-NetRoute -RemoteIPAddress x.x.x.x para el servidor de la app. Añade una ruta específica vía VPN o arregla el solapamiento renumerando (sí, en serio) o usando NAT en el concentrador VPN.

7) “Tras conectar la VPN, Windows dice que la red es Pública y el descubrimiento muere”

Síntoma: Los dispositivos no son descubiertos; el explorador de SMB falla; las reglas entrantes no coinciden.

Causa raíz: La categoría de red cambió a Pública, a menudo desencadenada por el comportamiento del adaptador VPN o confusión de NLA.

Solución: Corrige la categoría de red cuando esté permitido, o crea reglas de firewall explícitas para los servicios necesarios en el perfil adecuado. No desactives el firewall salvo que te guste llevarte hallazgos de auditoría.

Broma #2: “Simplemente desactiva el firewall” es el equivalente en redes de arreglar un coche que suena mal subiendo el volumen de la radio.

Listas de verificación / plan paso a paso (aburrido a propósito)

Paso a paso: arreglar un perfil VPN integrado de Windows para túnel dividido

Inventario de lo que debe ir por la VPN. Lista prefijos y dominios corporativos necesarios para el trabajo. Si tu lista es “todo”, estás haciendo túnel completo y hay que admitirlo.
Habilita el túnel dividido. Usa Set-VpnConnection -SplitTunneling $True.
Añade rutas para cada prefijo corporativo. Usa Add-VpnConnectionRoute por prefijo.
Reconecta la VPN. Los cambios de ruta a menudo aplican correctamente tras reconectar.
Valida rutas. Confirma que la ruta por defecto es local y que los prefijos corporativos van a la VPN.
Arregla el comportamiento DNS. Usa NRPT para zonas corporativas. Asegura que los nombres locales sigan resolviéndose con DNS local (o pasa a FQDNs).
Fija métricas solo si es necesario. Si la selección de rutas es inestable, ajusta métricas de interfaz—pero cuidado con los reinicios del cliente.
Documenta la decisión. El túnel dividido es una postura de seguridad. Haz explícito el riesgo y apruébalo.

Lista de verificación: qué capturar para un ticket reproducible “La VPN rompe la LAN”

Subred local (p. ej., 192.168.1.0/24), IP de gateway y si es Wi‑Fi/Ethernet
ipconfig /all antes y después de conectar la VPN
route print antes y después de conectar la VPN
Get-NetIPInterface (métricas) y Get-NetConnectionProfile (perfil de firewall)
Una prueba fallida por nombre y por IP (ping nas y ping 192.168.1.10)
nslookup tanto para un FQDN corporativo como para un nombre local
tracert a una IP local y a una IP corporativa
Cualquier ajuste del cliente VPN etiquetado “bloquear subredes locales” / “permitir acceso LAN”

Preguntas frecuentes

1) ¿Por qué mi VPN mata el acceso a dispositivos 192.168.1.x?

O la VPN se convirtió en tu puerta de enlace por defecto (túnel completo), o empuja rutas que solapan tu subred doméstica. Revisa route print y busca 0.0.0.0/0 vía VPN o rutas amplias 192.168.0.0/16.

2) ¿Es inseguro el túnel dividido?

PUEDE serlo, si tu endpoint no está gestionado o si efectivamente conectas redes no confiables y acceso corporativo sin controles. En entornos gestionados, el túnel dividido es común con controles compensatorios (EDR, verificaciones de postura, políticas DNS, VPN por aplicación, identidad fuerte). La seguridad es un diseño, no una casilla.

3) Habilité el túnel dividido pero las apps corporativas dejaron de funcionar. ¿Qué me faltó?

Probablemente eliminaste la ruta por defecto vía VPN pero no añadiste rutas para todos los prefijos corporativos requeridos, o el DNS de dominios corporativos sigue yendo a resolutores locales. Añade rutas faltantes e implementa DNS dividido (NRPT).

4) ¿Por qué falla `\\nas` pero funciona `\\192.168.1.10`?

DNS (o LLMNR/mDNS) es el culpable. Probablemente tu VPN configuró DNS corporativo como primario, y ese DNS no puede resolver tus nombres locales de una sola etiqueta. Arregla con NRPT, uso de FQDNs o ajustes DNS locales.

5) ¿Puedo simplemente añadir una ruta estática para mi subred doméstica?

En ocasiones sí. Si la VPN empuja una ruta conflictiva, una ruta local más específica puede ganar. Pero si la VPN instala bloqueos de firewall o el conflicto es exacto (mismo tamaño de prefijo), las rutas estáticas no te salvarán. Además, muchos clientes VPN reaplican rutas al conectar.

6) ¿Por qué el cliente VPN tiene una opción “Permitir acceso LAN”?

Porque algunos clientes bloquean intencionalmente subredes locales mientras estás conectado para prevenir riesgos de split-horizon (por ejemplo, malware que alcanzaría recursos corporativos a través de una LAN comprometida). Ese interruptor suele controlar comportamiento de firewall/WFP, no solo rutas.

7) ¿Y IPv6—debería desactivarlo?

No desactives IPv6 como primera medida. Primero inspecciona rutas IPv6 y si la VPN soporta IPv6. Si tienes IPv6 en la LAN y la VPN solo maneja IPv4, puedes acabar con asimetrías extrañas. Arregla asegurando políticas coherentes: o soportas IPv6 correctamente o defines cómo debe manejarse el tráfico IPv6.

8) ¿Cómo sé si Windows envía tráfico a la VPN o a la interfaz local?

Usa Find-NetRoute -RemoteIPAddress para ver la interfaz elegida para un destino, y tracert para confirmar el primer salto. Si el salto 1 es una gateway/interfaz VPN, no te estás quedando local.

9) Mi empresa prohíbe el túnel dividido. ¿Estoy atascado?

Tal vez, pero aún tienes opciones: solicita una excepción oficial “permitir LAN local”, usa una subred doméstica no solapada (renumera tu LAN), o emplea un dispositivo separado para recursos locales. Luchar contra la política con rutas parchadas suele perder—y crea incidentes peores.

10) ¿Por qué esto pasa más en redes domésticas que en oficinas?

Las redes domésticas suelen usar subredes consumidoras por defecto (192.168.0.0/24, 192.168.1.0/24). Las empresas que empujan rutas privadas amplias colisionan con esos valores por defecto. Las oficinas suelen tener planes de direcciones gestionados y menos solapamientos—idealmente.

Conclusión: próximos pasos que puedes hacer hoy

Si tu VPN rompe el acceso LAN local, deja de tratarlo como un bug espeluznante del cliente. Es enrutamiento, DNS o política—por lo general en ese orden.

Ejecuta el diagnóstico rápido: prueba por IP vs nombre, luego inspecciona rutas, luego busca bloqueos firewall/WFP, luego métricas.
Toma una decisión: Si la política lo permite, implementa túnel dividido real (rutas corporativas explícitas). Si la política lo prohíbe, persigue excepciones “permitir LAN” o arregla el solapamiento renumerando tu subred doméstica.
Arregla el DNS intencionalmente: NRPT para zonas corporativas, DNS local para nombres locales y menos nombres de una sola etiqueta en flujos críticos.
Estandariza la evidencia: captura ipconfig /all, route print y salidas clave de PowerShell antes/después de conectar. Convierte discusiones en ingeniería.

Hazlo una vez, documenta, y la próxima vez que alguien diga “la VPN se comió mi impresora”, tendrás una respuesta mejor que un suspiro.