WSL2 + VPN: por qué falla (y cómo arreglarlo)

El modelo mental: por qué WSL2 y las VPN chocan

WSL2 no es una capa de compatibilidad en el sentido antiguo. Es una VM ligera con un kernel Linux real.
En términos de red, se comporta como una máquina situada detrás de una pequeña pasarela NAT implementada por Windows.
Tu distro Linux obtiene una dirección en un rango privado (típicamente 172.16.0.0/12 o algo tipo 192.168.0.0/16),
y Windows hace la traducción y el reenvío.

Los clientes VPN, por otro lado, son profesionalmente intrusivos. Instalan adaptadores virtuales, inyectan rutas,
sobrescriben DNS, aplican políticas y a veces bloquean encaminamientos “no corporativos” a propósito.
La VPN normalmente asume que trata con una única pila de red del host. WSL2 es una segunda pila detrás de ella.
Ahora tienes dos dominios de enrutamiento y al menos tres lugares donde el DNS puede ser “útilmente” reescrito:
Windows, el cliente VPN y el /etc/resolv.conf autogenerado por WSL.

Por dónde van los paquetes realmente

Cuando un proceso en WSL2 conecta a git.internal.corp, hace:

• La app Linux pide al resolvedor de Linux el DNS.
• El resolvedor de Linux consulta /etc/resolv.conf (a menudo apuntando a una IP del resolvedor en el lado de Windows).
• El tráfico sale de la VM WSL hacia el host Windows vía el switch virtual de WSL.
• Windows decide qué interfaz/ruta gana: adaptador VPN, Wi‑Fi/Ethernet, o “nope”.
• El cliente VPN puede NATear, cifrar o bloquear el reenvío según la política.

La rotura suele caer en uno de cuatro cubos: enrutamiento, DNS, MTU/fragmentación o política/firewall.
Puedes arreglar los cuatro, pero tienes que dejar de adivinar en cuál estás.

Chiste #1: Los clientes VPN son como los gatos: independientes, territoriales y convencidos de que son lo único que importa en la casa.

La verdad incómoda

Algunas políticas VPN hacen intencionalmente difícil usar WSL2. No porque WSL2 sea malvado, sino porque es efectivamente una segunda máquina.
Los equipos de seguridad se preocupan por entornos Linux no administrados que pivoten dentro de redes internas.
Así que la “solución” puede no ser un ajuste; puede ser “pide a tu equipo de VPN que lo permita” o “usa una VM de desarrollo sancionada”.
Aun así, en muchas compañías es solo una pelea entre configuraciones por defecto.

Guía rápida de diagnóstico (verificar 1/2/3)

Cuando WSL2 + VPN se rompe, no empieces por reinstalar WSL ni cambiar diez ajustes a la vez.
Haz lo siguiente en orden. Cada paso reduce el dominio de fallo.

1) ¿Es DNS o enrutamiento?

• Si ping 10.x.x.x funciona pero ping git.internal.corp no, es DNS.
• Si DNS resuelve a la IP correcta pero TCP no puede conectar, es enrutamiento/firewall/MTU.
• Si solo algunos subredes internas funcionan, es inyección de rutas de túnel dividido.

2) Compara el comportamiento en Windows vs WSL

• Si Windows puede alcanzar recursos internos pero WSL no, el problema está en el límite NAT/reenvío o en la transferencia del DNS.
• Si Windows tampoco puede alcanzarlos, deja de culpar a WSL. Arregla la conexión VPN, las rutas o el DNS corporativo primero.

3) Identifica la interfaz que debería ganar

• Túnel completo: la ruta por defecto debe ir vía VPN. El DNS debe ser corporativo.
• Túnel dividido: solo prefijos internos específicos van por la VPN; la ruta por defecto queda en Internet local.
• En ambos casos: el tráfico de WSL debe permitirse atravesar Windows hacia esa interfaz.

4) Revisa MTU al final (pero no lo olvides)

Los problemas de MTU parecen “DNS funciona, ping funciona, HTTPS se queda colgado” o “las peticiones pequeñas van, las grandes se quedan”.
Si ves ese patrón, prueba MTU antes de perder una hora discutiendo tablas de enrutamiento.

Hechos e historia: por qué esto se repite

• WSL1 y WSL2 tienen redes fundamentalmente diferentes. WSL1 compartía la pila de Windows; WSL2 está NATeado detrás de una VM.
• WSL2 usa un switch virtual de Hyper‑V bajo el capó. Incluso en Windows Home, la tubería se comporta como una mini configuración de Hyper‑V.
• Muchos clientes VPN aún incluyen drivers de kernel. Se enganchan profundamente en la red de Windows para aplicar políticas y rutas.
• El “split horizon” de DNS es común en empresas. El mismo hostname puede resolverse diferente dentro y fuera de la VPN, haciendo que resolvedores obsoletos sean desastrosos.
• NRPT y DNS por interfaz son cosa de Windows. Windows puede enviar consultas DNS distintas a distintos servidores según reglas de dominio; Linux típicamente no a menos que se configure.
• El dolor por MTU es anterior a WSL. La encapsulación VPN reduce el MTU efectivo, y PMTUD sigue siendo frágil en redes reales.
• La precedencia de la ruta por defecto no es universal. Las métricas de ruta de Windows y los ajustes “forzar túnel” de la VPN sorprenden a quienes vienen de Linux.
• Las baselines de seguridad corporativas a menudo bloquean el reenvío IP. Incluso si Windows puede alcanzar la VPN, puede negarse a reenviar tráfico desde una NIC “virtual”.
• El acceso a localhost desde WSL2 cambió con el tiempo. Las compilaciones recientes de Windows mejoraron el reenvío de localhost entre Windows y WSL, pero las VPNs todavía pueden interferir.

Modos de fallo mapeados a causas raíz

Modo de fallo A: “El DNS está roto en WSL, pero Windows está bien”

Lo más común. WSL autogenera /etc/resolv.conf apuntando a una IP del resolvedor en Windows.
Cuando te conectas a la VPN, los servidores DNS de Windows cambian. WSL no siempre actualiza limpiamente, o se actualiza a un resolvedor que no puede alcanzar el
DNS corporativo debido al binding de interfaz.

Modo de fallo B: “IPs internas hacen timeout desde WSL, pero resuelven correctamente”

Eso suele ser enrutamiento o política. Windows puede enrutar a la subred interna vía el adaptador VPN,
pero el tráfico de WSL puede que no esté permitido para atravesar ese camino (firewall, política del cliente VPN o ruta de retorno faltante).

Modo de fallo C: “Túnel dividido: una subred funciona, otra no”

El túnel dividido depende de empujar muchos prefijos internos. Algunos clientes VPN empujan solo a Windows y asumen que los procesos locales son la única fuente.
El tráfico de WSL puede usar un rango de origen diferente (el rango NAT de WSL), y el lado corporativo puede no tener una ruta de retorno.

Modo de fallo D: “HTTPS se queda, git clone cuelga, pero ping funciona”

MTU / fragmentación. La encapsulación reduce el MTU; algunos caminos descartan mensajes ICMP de “fragmentación necesaria”; TCP se queda en blackhole.
Es aburrido, antiguo y sigue quemando equipos semanalmente.

Modo de fallo E: “Todo funciona hasta que suspendes/ reanudas”

Reanudar a menudo cambia el orden de las interfaces, las métricas de ruta o el estado interno del cliente VPN.
WSL sigue corriendo, reteniendo DNS o rutas antiguas, mientras Windows ha cambiado.

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

Estas tareas están diseñadas para ejecutarse exactamente cuando algo está roto. Cada una te dice algo específico
y te indica qué hacer después. Ejecuta comprobaciones tanto en Windows como en WSL; la diferencia es la pista.

Tarea 1 (WSL): ¿Qué IP y gateway por defecto tengo?

cr0x@server:~$ ip -br addr
lo               UNKNOWN        127.0.0.1/8 ::1/128
eth0             UP             172.26.112.45/20

cr0x@server:~$ ip route show
default via 172.26.112.1 dev eth0
172.26.112.0/20 dev eth0 proto kernel scope link src 172.26.112.45

Qué significa: WSL está en 172.26.112.0/20 y usa 172.26.112.1 como gateway (NAT de Windows).
Decisión: Si falta el gateway o la interfaz está DOWN, tu red WSL está rota antes de que la VPN entre en escena.
Reinicia WSL (wsl --shutdown desde Windows) y prueba de nuevo.

Tarea 2 (WSL): ¿El DNS apunta a un lugar razonable?

cr0x@server:~$ cat /etc/resolv.conf
# This file was automatically generated by WSL. To stop automatic generation of this file, add the following entry to /etc/wsl.conf:
# [network]
# generateResolvConf = false
nameserver 172.26.112.1

Qué significa: WSL está usando el gateway de Windows como proxy/resolvedor DNS.
Decisión: Si el DNS corporativo falla, este es tu primer sospechoso. O bien el resolvedor de Windows está equivocado para el estado de la VPN,
o WSL se quedó con DNS obsoleto. Procede a las Tareas 3 y 4.

Tarea 3 (WSL): ¿Puedo resolver un nombre interno y qué servidor respondió?

cr0x@server:~$ resolvectl status 2>/dev/null | sed -n '1,120p'
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: foreign
Current DNS Server: 172.26.112.1
       DNS Servers: 172.26.112.1

Qué significa: Tu resolvedor es el gateway de WSL. Eso puede funcionar, pero solo si Windows reenvía consultas apropiadamente.
Decisión: Si los dominios internos no resuelven, prueba DNS directo a servidores corporativos (Tarea 4) para separar “resolvedor de WSL” de “alcanzabilidad DNS”.

Tarea 4 (WSL): Consulta el DNS corporativo directamente (evita el proxy)

cr0x@server:~$ dig @10.20.30.40 git.internal.corp +time=2 +tries=1

; <<>> DiG 9.18.24-1ubuntu1.3-Ubuntu <<>> @10.20.30.40 git.internal.corp +time=2 +tries=1
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

Qué significa: WSL no puede alcanzar la IP del servidor DNS corporativo directamente.
Decisión: Esto es enrutamiento/política, no un problema del archivo de resolvedor. Ve a la Tarea 6 (rutas) y la Tarea 10 (pistas sobre firewall/política).

Tarea 5 (Windows desde el shell WSL): ¿Puedo comparar rápido con Windows DNS?

cr0x@server:~$ powershell.exe -NoProfile -Command "Resolve-DnsName git.internal.corp | Select-Object -First 1"
Name                                           Type   TTL   Section    IPAddress
----                                           ----   ---   -------    ---------
git.internal.corp                              A      60    Answer     10.50.12.34

Qué significa: Windows puede resolver el nombre.
Decisión: Ahora sabes: el DNS funciona en Windows, pero WSL no puede usarlo. La solución suele ser la integración DNS de WSL (ver sección de soluciones: “fijar resolv.conf” o “usar systemd-resolved correctamente”).

Tarea 6 (WSL): ¿Qué ruta usaría para llegar a una IP interna?

cr0x@server:~$ ip route get 10.50.12.34
10.50.12.34 via 172.26.112.1 dev eth0 src 172.26.112.45 uid 1000

Qué significa: WSL enviará el tráfico interno al gateway de Windows. Eso es esperado.
Decisión: Si Windows luego no lo reenvía hacia la VPN, estás ante un problema de enrutamiento/política/firewall de Windows o un cliente VPN que bloquea el reenvío desde la vNIC de WSL.

Tarea 7 (WSL): ¿Puedo alcanzar la IP interna en absoluto?

cr0x@server:~$ ping -c 2 10.50.12.34
PING 10.50.12.34 (10.50.12.34) 56(84) bytes of data.

--- 10.50.12.34 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1027ms

Qué significa: No hay alcanzabilidad ICMP. No es concluyente (ICMP puede estar bloqueado), pero es una señal fuerte.
Decisión: Prueba conectividad TCP a continuación. Si TCP también falla, es enrutamiento/política. Si TCP funciona y ping falla, es solo política sobre ICMP.

Tarea 8 (WSL): Prueba TCP a un puerto interno conocido

cr0x@server:~$ nc -vz -w 2 10.50.12.34 443
nc: connect to 10.50.12.34 port 443 (tcp) timed out: Operation now in progress

Qué significa: TCP no llega.
Decisión: Sube por la pila: revisa rutas de Windows y el comportamiento del adaptador VPN. Si Windows puede conectar pero WSL no, sospecha restricciones del cliente VPN sobre reenvío/NAT.

Tarea 9 (Windows desde WSL): ¿Qué piensa Windows que son las rutas?

cr0x@server:~$ powershell.exe -NoProfile -Command "Get-NetRoute -AddressFamily IPv4 | Sort-Object -Property RouteMetric | Select-Object -First 8"
ifIndex DestinationPrefix NextHop     RouteMetric ifMetric PolicyStore
------- ----------------- -------     ----------- -------- -----------
19      0.0.0.0/0         10.8.0.1    5           25       ActiveStore
3       0.0.0.0/0         192.168.1.1 35          25       ActiveStore
19      10.0.0.0/8        0.0.0.0     5           25       ActiveStore
19      172.16.0.0/12     0.0.0.0     5           25       ActiveStore
19      192.168.0.0/16    0.0.0.0     5           25       ActiveStore
1       127.0.0.0/8       0.0.0.0     256         75       ActiveStore

Qué significa: La VPN (ifIndex 19) está ganando la ruta por defecto y los rangos RFC1918 internos.
Decisión: En túnel completo esto es esperado. En túnel dividido puede estar mal y romper el acceso a la red local.
En cualquier caso, si WSL no puede atravesar esto, el cliente VPN puede estar bloqueando el reenvío o el firewall de Windows está filtrando la interfaz vEthernet de WSL.

Tarea 10 (Windows desde WSL): ¿El perfil/firewall de vEthernet (WSL) es hostil?

cr0x@server:~$ powershell.exe -NoProfile -Command "Get-NetAdapter -Name 'vEthernet (WSL)' | Format-List -Property Name,Status,MacAddress,LinkSpeed"
Name       : vEthernet (WSL)
Status     : Up
MacAddress : 00-15-5D-4A-2B-1C
LinkSpeed  : 10 Gbps

cr0x@server:~$ powershell.exe -NoProfile -Command "Get-NetConnectionProfile -InterfaceAlias 'vEthernet (WSL)' | Format-List"
Name             : Network
InterfaceAlias   : vEthernet (WSL)
NetworkCategory  : Public
IPv4Connectivity : Internet

Qué significa: La NIC virtual de WSL está categorizada como Public. Muchos firewalls corporativos restringen mucho los perfiles Public.
Decisión: Si la política lo permite, cámbiala a Private. Si la política no lo permite, necesitas reglas de firewall específicas en lugar de cambiar perfiles ampliamente.

Tarea 11 (WSL): Revisa MTU y prueba por blackholing

cr0x@server:~$ ip link show dev eth0 | sed -n '1,3p'
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 00:15:5d:4a:2b:1c brd ff:ff:ff:ff:ff:ff

cr0x@server:~$ ping -c 2 -M do -s 1472 10.50.12.34
PING 10.50.12.34 (10.50.12.34) 1472(1500) bytes of data.
ping: local error: message too long, mtu=1500

cr0x@server:~$ ping -c 2 -M do -s 1360 10.50.12.34
PING 10.50.12.34 (10.50.12.34) 1360(1388) bytes of data.

--- 10.50.12.34 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1018ms

Qué significa: El primer ping muestra la lógica de MTU de tu interfaz. El segundo muestra que el camino aún falla—así que no es solo “paquetes demasiado grandes”.
Decisión: Si tamaños más pequeños tienen éxito pero los grandes se atascan, reduce el MTU (o MSS) en el lado WSL o arregla PMTUD. Si ambos fallan, vuelve al enrutamiento/política.

Tarea 12 (WSL): Traza dónde se detienen los paquetes (básico)

cr0x@server:~$ traceroute -n -w 1 -q 1 10.50.12.34
traceroute to 10.50.12.34 (10.50.12.34), 30 hops max, 60 byte packets
 1  172.26.112.1  0.240 ms
 2  * 
 3  * 
 4  *

Qué significa: El tráfico llega al gateway de Windows y luego desaparece. Ese es el límite.
Decisión: Deja de tocar las rutas de Linux. Necesitas hacer que Windows+VPN reenvíen el tráfico correctamente, o ajustar la postura de la VPN para soportar WSL.

Tarea 13 (WSL): Comprueba si un proxy es esperado (común en VPNs corporativas)

cr0x@server:~$ env | grep -iE 'http_proxy|https_proxy|no_proxy'
https_proxy=http://proxy.internal.corp:8080
http_proxy=http://proxy.internal.corp:8080
no_proxy=localhost,127.0.0.1,.internal.corp

Qué significa: Tu entorno espera un proxy HTTP.
Decisión: Si el TCP directo a endpoints internos falla pero el proxy funciona en Windows, puedes necesitar variables de proxy consistentes dentro de WSL (o usar una solución PAC vía Windows). También asegúrate de que no_proxy incluya dominios internos que no deben pasar por el proxy.

Tarea 14 (WSL): Confirma qué hace git realmente

cr0x@server:~$ GIT_CURL_VERBOSE=1 GIT_TRACE=1 git ls-remote https://git.internal.corp/team/repo 2>&1 | sed -n '1,40p'
20:17:14.123456 git.c:460               trace: built-in: git ls-remote https://git.internal.corp/team/repo
20:17:14.130000 http.c:725              == Info:   Trying 10.50.12.34:443...
20:17:14.132000 http.c:725              == Info: connect to 10.50.12.34 port 443 failed: Connection timed out
fatal: unable to access 'https://git.internal.corp/team/repo/': Failed to connect to git.internal.corp port 443 after 2002 ms: Timeout was reached

Qué significa: La resolución tuvo éxito; la conexión falló por timeout.
Decisión: No toques DNS. Arregla el enrutamiento/reenvío/política o usa el proxy corporativo si es necesario.

Patrones de solución que realmente funcionan

Hay docenas de “arreglos” en foros para WSL2+VPN. La mitad son culto cargo. Una cuarta parte violan políticas de seguridad.
El resto se puede volver fiable si eliges el patrón correcto para tu entorno: túnel completo, túnel dividido, solo proxy, o “el cliente VPN lo prohíbe”.

Patrón 1: Estabilizar DNS dentro de WSL (deja de perseguir objetivos móviles)

Si Windows resuelve nombres internos pero WSL no, normalmente quieres que WSL use directamente los servidores DNS corporativos,
o usar un reenviador local estable que realmente siga el estado de la VPN.

Opción A: Fijar resolv.conf (simple, contundente, efectivo)

Desactiva la autogeneración y define servidores DNS explícitos.
Esto funciona mejor cuando las IPs DNS corporativas son estables mientras estás conectado a la VPN.

cr0x@server:~$ sudo tee /etc/wsl.conf >/dev/null <<'EOF'
[network]
generateResolvConf = false
EOF

cr0x@server:~$ sudo rm -f /etc/resolv.conf
cr0x@server:~$ sudo tee /etc/resolv.conf >/dev/null <<'EOF'
nameserver 10.20.30.40
nameserver 10.20.30.41
search internal.corp
options timeout:2 attempts:2
EOF

Qué significa la salida: No hay salida, estás escribiendo archivos.
Decisión: Reinicia WSL (wsl --shutdown) para que vuelva a leer la configuración. Si esto arregla la resolución interna pero rompe el DNS público fuera de la VPN,
necesitas DNS condicional o un resolvedor que cambie con la VPN.

Opción B: Usar systemd-resolved correctamente (menos contundente, más correcto)

En builds de WSL más nuevos se puede activar systemd. Cuando funciona, te da un verdadero demonio resolvedor,
y puedes apuntarlo a servidores DNS con caché y comportamiento de fallback adecuado.
La pega: debes mantener la historia DNS de Windows/VPN consistente, o fallarás más rápido.

Si no estás usando systemd en WSL, no lo actives solo para arreglar DNS de la VPN a menos que puedas soportar el cambio.
Es bueno. También es otra parte móvil. Regla práctica: añade complejidad solo si te aporta estabilidad.

Patrón 2: Realidad del túnel dividido (las rutas deben existir en ambos sentidos)

El túnel dividido es donde el optimismo va a morir. Tu Windows obtiene rutas a 10.0.0.0/8 y similares vía la VPN.
WSL envía paquetes al gateway de Windows. Windows los reenvía a la VPN. Genial.
Luego el lado corporativo recibe paquetes con origen 172.26.112.45 (el rango NAT de WSL) y no sabe cómo responder.

En túnel completo, esto a menudo funciona “accidentalmente” porque el cliente VPN NATea el tráfico saliente y lo hace parecer procedente de la IP VPN del host Windows.
En túnel dividido, el comportamiento NAT varía enormemente. Algunos clientes NATean, otros no, algunos solo lo hacen para procesos Windows y otros lo rechazan para “adaptadores virtuales”.

Tus opciones de solución:

• Mejor: El cliente VPN soporta NAT/reenvío para el tráfico WSL (o se configura así).
• También válido: La red corporativa tiene rutas de retorno al subnet NAT de WSL (raro; requiere aceptación del equipo de red y controles estrictos).
• Solución alternativa: Usa un proxy/host jump/bastión que Windows pueda alcanzar, y tunela desde WSL por esa única ruta permitida.

Patrón 3: Evitar que el firewall de Windows sabotee la vEthernet (WSL)

Si el adaptador WSL está en “Public” y tu firewall corporativo es estricto, el tráfico de WSL puede ser bloqueado para alcanzar el adaptador VPN.
Esto es común en portátiles endurecidos.

Si te permiten, configura la NIC virtual de WSL como Private. Si no te lo permiten, añade reglas de firewall estrechas en lugar de cambiar perfiles de forma amplia.
Tu equipo de seguridad agradecerá “reglas estrechas y auditables” más que “toqué cosas hasta que funcionó”.

Patrón 4: Arreglar MTU (o MSS) cuando TCP se atasca

La encapsulación VPN consume MTU. Si tienes un MTU subyacente de 1500 y la VPN añade overhead,
tu MTU efectivo puede ser ~1400 o menos. Si PMTUD falla (porque ICMP está filtrado en alguna parte),
segmentos TCP grandes desaparecen y las conexiones cuelgan de forma mística.

La solución pragmática es reducir el MTU en la interfaz WSL o ajustar MSS de TCP.
Estás intercambiando algo de rendimiento por estabilidad. En redes corporativas, la estabilidad es la única moneda aceptada.

cr0x@server:~$ sudo ip link set dev eth0 mtu 1400
cr0x@server:~$ ip link show dev eth0 | sed -n '1,2p'
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1400 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 00:15:5d:4a:2b:1c brd ff:ff:ff:ff:ff:ff

Qué significa: El MTU ahora es 1400.
Decisión: Vuelve a probar el flujo que colgaba (git clone, curl, lo que sea). Si arregla los cuelgues, hazlo persistente (vía la configuración de red de la distro),
y documenta por qué. Si no cambia nada, restaura y sigue diagnosticando.

Patrón 5: Tratar los proxies como ciudadanos de primera clase

Muchos entornos VPN corporativos no son “encaminar a donde quieras”. Son “encaminar al proxy, luego al proxy”.
Si Windows tiene auto-configuración de proxy, pero WSL no, WSL fallará aunque el portátil “funcione”.

En ese entorno, la solución correcta es configurar variables de proxy en WSL de forma coherente y mantener no_proxy.
No lo codifiques en archivos de inicio del shell con condiciones misteriosas; usa un enfoque gestionado (scripts de perfil),
y mantenlo visible. Las credenciales pertenecen a almacenes secretos, no a .bashrc.

Chiste #2: Depurar redes VPN es como ver un truco de magia, excepto que el conejo es tu paquete y nunca vuelve.

Patrón 6: Cuando el cliente VPN prohíbe WSL, deja de pelear

Algunos clientes VPN aplican “no tráfico desde adaptadores virtuales” o similar. A veces es política explícita; a veces es un artefacto de implementación.
Si tu diagnóstico muestra consistentemente que los paquetes mueren en el gateway de Windows y sabes que tu cliente VPN bloquea el reenvío,
tienes tres opciones sensatas:

• Usar WSL1 (si tu carga de trabajo lo tolera) porque comparte la pila de red de Windows y a menudo evita el límite NAT por completo.
• Usar una VM de desarrollo sancionada en la VPN (administrada por TI) o un host de desarrollo remoto dentro de la red.
• Usar un bastión SSH accesible desde Windows y conectar a través de él (port-forwarding) desde WSL; trátalo como una salida controlada.

La opción insana es “instalar un driver sospechoso” o “desactivar el firewall del endpoint” para hacerlo funcionar.
Así haces que tu portátil termine en cuarentena, y tu semana empeora.

Un principio de fiabilidad que vale la pena

La esperanza no es una estrategia. — James Cameron

Aplícalo aquí: deja de esperar que la tabla de rutas “se vea bien” y prueba cada capa con tests dirigidos.

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

1) Síntoma: “WSL no puede resolver dominios internos; Windows sí”

Causa raíz: /etc/resolv.conf de WSL apunta a un resolvedor que no sigue los cambios DNS de la VPN, o el DNS de Windows es por interfaz y la ruta proxy de WSL no aplica las reglas NRPT.

Solución: Fija el DNS dentro de WSL (desactiva generateResolvConf) a servidores DNS corporativos cuando estés en la VPN, o implementa un enfoque de resolvedor que siga el estado de la VPN de forma fiable.

2) Síntoma: “DNS resuelve, pero TCP a la IP interna hace timeout desde WSL”

Causa raíz: El cliente VPN bloquea el reenvío desde la vEthernet de WSL, o el perfil del firewall de Windows lo bloquea.

Solución: Revisa la categoría de red del adaptador WSL; añade excepciones de firewall estrechas; si la política de la VPN lo prohíbe, usa WSL1 o un host de desarrollo sancionado.

3) Síntoma: “Túnel dividido: algunas subredes internas funcionan, otras no”

Causa raíz: Rutas faltantes del cliente VPN, redes locales solapadas, o ruta de retorno desconocida para el rango NAT de WSL.

Solución: Verifica las rutas de Windows para cada prefijo; evita rangos LAN locales que solapen RFC1918 corporativo; empuja las rutas correctas vía el perfil VPN; asegura que el comportamiento NAT sea consistente.

4) Síntoma: “Tras suspender/reanudar, WSL pierde conectividad hasta reiniciar”

Causa raíz: Cambios en métricas de interfaz o estado de resolvedor obsoleto en WSL; la reconexión de la VPN cambia el orden de DNS/rutas.

Solución: Automatiza wsl --shutdown tras reconectar la VPN (o al menos documenta esto). Prefiere configuración DNS estable en lugar de depender de resolv.conf autogenerado.

5) Síntoma: “HTTPS se queda; peticiones pequeñas funcionan; ping funciona”

Causa raíz: Blackhole MTU por encapsulación VPN y PMTUD roto.

Solución: Reduce MTU en la interfaz WSL (o ajusta MSS) y vuelve a probar. Si funciona, hazlo persistente y anota el overhead de la VPN.

6) Síntoma: “Servicios locales en Windows no son accesibles desde WSL mientras estoy en la VPN”

Causa raíz: La VPN fuerza rutas o políticas de firewall que interfieren con la red local/forwarding de localhost; a veces la VPN cambia reglas de firewall agresivamente.

Solución: Usa IPs explícitas del host, valida reglas de firewall de Windows y considera enlazar servicios a la interfaz correcta. Para desarrollo, prefiere conectar vía localhost cuando sea compatible, pero verifícalo después de conectar la VPN.

Listas de verificación / plan paso a paso

Lista A: Necesitas DNS interno + TCP interno desde WSL (VPN túnel completo)

1. Confirma que Windows puede resolver y conectar al servicio interno.
2. En WSL, revisa /etc/resolv.conf; prueba dig al DNS corporativo directamente.
3. Si Windows funciona y WSL no, fija el DNS de WSL a resolvers corporativos o arregla la ruta proxy DNS.
4. Verifica las rutas de Windows: ruta por defecto y prefijos internos deben ir por el adaptador VPN.
5. Revisa el perfil de firewall del adaptador WSL; cámbialo a Private si se permite o añade reglas estrechas.
6. Si TCP se atasca de forma rara, prueba MTU y reduce si es necesario.
7. Documenta el estado final: servidores DNS, MTU y qué falla cuando estás fuera de la VPN.

Lista B: Necesitas túnel dividido (Internet local, subredes corporativas por VPN)

1. Lista los prefijos internos exactos que necesitas (no adivines; consíguelos del perfil VPN o del equipo de red).
2. En Windows, confirma que esos prefijos tienen rutas vía el adaptador VPN (enfoque Tarea 9).
3. En WSL, verifica que el tráfico a cada prefijo vaya al gateway de Windows (Tarea 6) y no desvíe.
4. Prueba la alcanzabilidad a una IP interna por prefijo (Tarea 8).
5. Si falla, sospecha ruta de retorno/NAT: comprueba si el lado corporativo espera tráfico solo desde la IP VPN de Windows.
6. Decide: (a) el cliente VPN soporta reenvío/NAT para WSL; (b) la red corporativa rutas al subnet NAT de WSL; o (c) usa proxy/bastión.
7. Estabiliza DNS: los dominios internos deben resolver a IPs internas solo mientras estás en la VPN; evita mezclar resolvers públicos y privados.

Lista C: Estás en un endpoint corporativo bloqueado

1. Asume que no puedes cambiar perfil de firewall, instalar drivers o añadir rutas persistentemente.
2. Prueba dónde mueren los paquetes (Tarea 12 traceroute a IP interna).
3. Si la caída ocurre en el gateway de Windows y Windows puede alcanzar el destino, probablemente sea política que prohíbe el reenvío desde adaptadores virtuales.
4. Deja de pelear con el portátil. Cambia de estrategia: WSL1, host de desarrollo remoto o bastión con port-forwards.
5. Documenta la excepción si WSL2 es una necesidad de negocio; “es molesto” no es una necesidad de negocio.

Tres mini-historias corporativas (anonimizadas, plausibles y dolorosamente familiares)

Mini-historia 1: El incidente causado por una suposición equivocada

Un equipo desplegó un nuevo mirror de paquetes interno durante una migración. Los desarrolladores usaban WSL2 para compilaciones.
El mirror vivía en una subred interna accesible solo vía VPN.
Los portátiles Windows podían llegar. El equipo asumió que eso significaba “los desarrolladores pueden llegar”, punto final.

El primer lunes después del despliegue, los tiempos de build pasaron de normales a catastróficos. No porque el mirror estuviera abajo.
Porque WSL2 no podía alcanzarlo, así que las herramientas recurrieron a mirrors públicos y a reintentos. Algunas compilaciones tuvieron éxito lentamente; otras fallaron; todos culparon al mirror.
El on-call recibió paginaciones por una “caída del registro” que no era una caída.

El modo de fallo fue claro en retrospectiva: Windows tenía las rutas VPN; el tráfico de WSL2 moría en el límite del host.
El cliente VPN aplicaba una política que no permitía reenvío desde adaptadores virtuales. Los procesos Windows estaban bien; WSL2 no.
Nadie comprobó la suposición temprano porque “funciona en mi máquina” era cierto—simplemente no en la misma pila de red.

La solución no fue un hack de rutas ingenioso. Fue una decisión: para la postura de seguridad de esa compañía, WSL2 no tendría acceso VPN directo.
Publicaron una imagen de VM Linux sancionada para builds y dejaron WSL2 para flujos locales. Fue menos cómodo.
También dejó de generar la arqueología semanal en Slack de “por qué apt está roto”.

Mini-historia 2: La optimización que salió mal

Otra organización intentó “acelerar la VPN” imponiendo túnel dividido agresivamente. El tráfico de Internet se mantenía local; solo prefijos internos iban por la VPN.
Redujo la carga en los concentradores y mejoró las videollamadas. Todos celebraron.

Luego las herramientas de desarrollo empezaron a fallar de formas raras. Los contenedores en WSL2 alcanzaban algunos servicios internos pero no otros.
El DNS a veces devolvía IPs internas, a veces públicas. Git sobre HTTPS colgaba intermitentemente.
No era aleatorio. Era caos determinista.

La optimización introdujo dos puntos de acoplamiento: completitud de rutas y consistencia de DNS.
Sus rutas de túnel dividido no incluían cada dependencia interna, especialmente las recién añadidas. Y su estrategia DNS se basaba en reglas NRPT de Windows,
que WSL2 no respetaba cuando usaba una ruta de resolvedor genérica.
El resultado: la resolución tenía éxito, pero la ruta no existía, así que las conexiones hacían timeout. Los desarrolladores “lo arreglaron” con archivos hosts y IPs hardcodeadas.
Lo que funcionó hasta el siguiente renuméreo.

No hicieron rollback total. Mantuvieron túnel dividido para la mayoría, pero crearon un perfil VPN “developer”:
o bien túnel completo o un conjunto de prefijos mucho más amplio y DNS estable. Menos elegante, más ancho de banda, menos outages misteriosos.
También prohibieron arreglos con hosts-file para servicios internos, no por pureza, sino porque era deuda operativa con mordidas.

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

Un equipo de plataforma tenía la costumbre que parecía burocracia: cada vez que un desarrollador reportaba “la VPN rompió WSL”,
la primera respuesta no era consejo: era una pequeña lista de salidas de comandos para pegar.
WSL: ip route, cat /etc/resolv.conf, dig dominio interno.
Windows: fragmento de la tabla de rutas y lista de servidores DNS. La misma solicitud, siempre.

La gente se quejó al principio. “¿Por qué necesitas todo eso? Obviamente es DNS.” No siempre lo era.
La lista de verificación les hizo dejar de discutir con sus propias corazonadas.
Tras un mes, emergieron patrones: una versión de cliente VPN rompía el reenvío; una actualización de controlador Wi‑Fi cambió métricas; una actualización de política de endpoint reclasificó la NIC de WSL.

Cuando llegó un incidente real—un repositorio interno inaccesible desde WSL en todo un departamento—esas salidas base hicieron la triage rápida.
Podían decir: Windows resuelve y conecta, WSL resuelve pero no conecta, traceroute muere en el gateway, y la NIC WSL es Public.
Eso redujo el radio de desastre de “la red está caída” a “regresión de política del endpoint”.

La solución eventual fue aburrida: un ajuste de política para permitir flujos salientes específicos desde la interfaz WSL hacia la VPN,
más un workaround documentado para clamp MTU en cierto ISP. Nadie escribió un blog sobre ello.
Pero la próxima vez que pasó, el on-call durmió.

Preguntas frecuentes

1) ¿Por qué WSL2 se rompe en VPN cuando WSL1 no lo hacía?

WSL1 compartía la pila de red de Windows. WSL2 es una VM detrás de un límite NAT. Los clientes VPN y firewalls que gestionan la pila de Windows
no reenvían automáticamente tráfico para una segunda pila de red.

2) ¿Debería cambiar a WSL1 solo por compatibilidad con VPN?

Si tu carga de trabajo tolera WSL1 (el rendimiento del sistema de archivos y algunas características de kernel pueden ser limitantes), es una solución legítima.
Evita el límite NAT y a menudo se comporta como “red normal de Windows”.

3) ¿El problema es siempre DNS?

No. DNS es común, pero hay muchos fallos por enrutamiento/política: el tráfico llega al gateway de Windows y muere porque el cliente VPN bloquea el reenvío
o el perfil de firewall es hostil.

4) ¿Por qué funciona hasta que reconecto la VPN o reanudo desde suspensión?

La reconexión de la VPN y la reanudación pueden reordenar rutas, cambiar servidores DNS y métricas de interfaz.
WSL puede mantener configuración de resolvedor antigua y el estado Windows/VPN cambia debajo.

5) ¿Cómo sé si es MTU?

Si la resolución de nombres funciona y las peticiones pequeñas tienen éxito, pero descargas HTTPS, clones de git o llamadas API cuelgan o se detienen, sospecha MTU/PMTUD.
Reduce MTU temporalmente en WSL y vuelve a probar el flujo que falla.

6) ¿Puedo simplemente añadir rutas dentro de WSL para arreglar túnel dividido?

Normalmente no. Las rutas de WSL aún van por el gateway de Windows. Si Windows/VPN no reenvía, las rutas del lado Linux no cambiarán la política.
Enfócate en las rutas de Windows y el comportamiento de la VPN primero.

7) ¿Por qué Windows puede alcanzar IPs internas y WSL no?

Los procesos de Windows originan tráfico desde interfaces Windows y son tratados por el cliente VPN como se espera.
El tráfico de WSL procede del subnet NAT de la vEthernet; algunos clientes VPN tratan eso como “tráfico reenviado” y lo bloquean.

8) ¿Cuál es la solución más limpia y amigable para la empresa?

Un entorno de desarrollo sancionado dentro de la red corporativa: VM gestionada, VDI o host de desarrollo remoto.
Si se debe usar WSL2 localmente, negocia una excepción de política documentada e implementa reglas de firewall estrechas en lugar de cambios amplios de perfil.

9) ¿Habilitar systemd en WSL arregla los problemas de VPN?

A veces ayuda con DNS porque obtienes un servicio de resolvedor real, pero no sortea mágicamente la política VPN o reglas de firewall.
Úsalo cuando puedas soportarlo operativamente, no como superstición.

Próximos pasos prácticos

Haz tres cosas, en este orden:

1. Clasifica la falla: DNS vs enrutamiento/política vs MTU. Usa los pasos rápidos de diagnóstico y las tareas anteriores.
2. Elige un patrón de solución estable: fija DNS, ajusta firewall/perfil, reduce MTU, adopta proxy, o cambia de estrategia (WSL1/host remoto).
3. Hazlo repetible: documenta el estado esperado (servidores DNS, modo VPN, MTU) y guarda una checklist copia‑pega para la próxima incidencia.

El objetivo no es “hacer que funcione en tu portátil hoy”. El objetivo es “hacer que sea aburrido el mes que viene”.
WSL2 es excelente. Las VPN son necesarias. Conseguir que cooperen es menos cuestión de comandos ingeniosos y más de admitir dónde está realmente el límite.