WSL2: guía avanzada de configuración de red y modos NAT y mirrored

Informatec Digital » Recursos » WSL2: guía avanzada de configuración de red y modos NAT y mirrored

WSL2 ha cambiado por completo la forma en la que Linux se integra con Windows, especialmente en todo lo que tiene que ver con la red: ahora tenemos una máquina virtual ligera con su propio stack de red, IP propia y reglas de acceso diferenciadas. Esto abre un montón de posibilidades para desarrollo, pruebas, contenedores y entornos de auto-hosting, pero también genera dudas cuando los servicios dejan de ser accesibles como ocurría con WSL1.

Entender la configuración de red de WSL2, sus modos NAT y mirrored, el uso de .wslconfig y wsl.conf, y cómo interactúan con el firewall, VPN, Docker o herramientas como Tailscale es clave para evitar quebraderos de cabeza. Vamos a ver paso a paso cómo funciona todo este tinglado, cómo exponer servicios a Windows y a la LAN, qué comandos usar para obtener las IPs correctas y qué opciones de configuración avanzada tienes para dejar tu entorno fino, estable y, sobre todo, seguro.

Cómo funciona realmente la red en WSL2

WSL2 ya no comparte la pila de red del host como WSL1, sino que ejecuta cada distribución de Linux dentro de una pequeña máquina virtual gestionada por Hyper-V. Esa VM tiene su propio adaptador virtual (normalmente eth0) y una IP privada asignada por un switch virtual interno.

En el modo predeterminado, WSL2 utiliza una arquitectura basada en NAT (Network Address Translation). Windows actúa como router/host y la distribución Linux vive en una subred privada, normalmente en el rango 172.16.0.0/12. Esa subred puede cambiar tras reinicios o reinicios de WSL, algo que a más de uno le ha vuelto loco al configurar reglas de firewall estáticas.

Desde el punto de vista práctico, esto implica que la IP de tu distro WSL2 no es estable ni accesible directamente desde la LAN como pasaba con WSL1: por defecto, solo hay conectividad entre Windows y WSL2 a través de reglas de redirección y NAT, y la exposición hacia la red local requiere pasos extra o el uso del modo mirrored.

Además de esta arquitectura base, Windows 11 22H2 y versiones posteriores añaden nuevas capacidades de red (modo mirrored, dnsTunneling, autoProxy, firewall de Hyper-V, etc.) que se controlan desde el archivo global .wslconfig, mientras que ciertas opciones dentro de Linux se gestionan con /etc/wsl.conf.

Identificar las direcciones IP en WSL2

Trabajar con WSL2 implica distinguir claramente dos escenarios de IP: cuándo necesitas la IP de la distro Linux y cuándo necesitas la IP del host Windows vista desde Linux. Cada uno se resuelve con un comando diferente.

Escenario 1: desde Windows quieres conocer la IP de la distro WSL2 para que una aplicación en el host (por ejemplo, un cliente, navegador o herramienta de testing) se conecte a un servicio que corre dentro de Linux. Para ello puedes ejecutar en Windows (CMD o PowerShell):

wsl.exe --distribution <DistroName> hostname -i

Si quieres usar la distro por defecto, puedes omitir el parámetro de distribución y llamar simplemente a wsl.exe hostname -i. En segundo plano, este comando lanza en Linux hostname --ip-addresses y devuelve la IP de la instancia. Un resultado típico podría ser algo como:

172.30.98.229

Escenario 2: desde la distro Linux necesitas saber la IP del host Windows, por ejemplo para que una aplicación en WSL2 se conecte a un servidor que corre nativamente en Windows (Node.js, SQL Server, Caddy, etc.). Dentro de la shell de Linux puedes usar:

ip route show | grep -i default | awk '{ print $3 }'

La salida será la puerta de enlace por defecto de la VM de WSL2, que corresponde a la IP del host Windows vista desde Linux, algo como:

172.30.96.1

Ese valor (por ejemplo, 172.30.96.1) es la dirección a la que debes apuntar tus clientes Linux cuando quieras llegar a servicios que corren en el Windows anfitrión mientras estás en modo NAT clásico.

Modo NAT: comportamiento por defecto de la red WSL2

De fábrica, WSL2 trabaja en modo NAT y para muchos entornos de desarrollo sencillo es más que suficiente. Lo importante es entender qué funciona “solo” y qué no, para no perder el tiempo persiguiendo fantasmas.

Acceso desde Windows a servicios Linux usando localhost: si levantas una aplicación de red (por ejemplo, un servidor Node.js, un Flask, un SQL Server en Linux) en tu distro WSL2, puedes acceder desde Windows usando localhost:puerto. Windows se encarga de reenviar automáticamente las conexiones entrantes a la IP interna de la VM WSL2.

Acceso desde Linux a servicios que se ejecutan en Windows: aquí la cosa cambia. Para llegar desde WSL2 a una aplicación de red en el host (como un servidor Node.js, SQL Server o Caddy en Windows), tienes que usar la IP del host vista desde Linux, obtenida con el comando de la ruta por defecto:

ip route show | grep -i default | awk '{ print $3 }'

Con esa IP podrás conectarte desde Linux a cualquier servicio del host, por ejemplo http://172.30.96.1:3000 si tu servidor Windows escucha en el puerto 3000 de todas las interfaces.

Cuando te conectas usando IPs remotas (no localhost), las aplicaciones las ven como conexiones LAN. Eso implica que muchos servidores deben estar configurados para escuchar en 0.0.0.0 en lugar de 127.0.0.1. Por ejemplo, con Flask podrías lanzar:

app.run(host='0.0.0.0')

Este cambio mejora la accesibilidad pero requiere cabeza en seguridad, porque estás permitiendo conexiones desde tu red local, no solo desde el propio equipo.

Acceso a WSL2 desde la red local (LAN) usando NAT

Uno de los cambios más molestos al pasar de WSL1 a WSL2 es que las distros dejan de ser accesibles directamente desde la LAN. En WSL1, si tu Windows estaba visible en la red, los servicios de la distro heredaban esa exposición casi sin esfuerzo.

En WSL2, la VM tiene su propia IP privada y no se publica automáticamente en la LAN. Para lograr algo parecido al antiguo comportamiento, en modo NAT tienes que crear un proxy de puertos en Windows, como harías con cualquier máquina virtual de Hyper-V.

Windows incluye una herramienta clásica para esto: netsh interface portproxy. Un comando típico para redirigir un puerto del host a la IP/puerto de WSL2 sería:

netsh interface portproxy add v4tov4 listenport=<puertoHost> listenaddress=0.0.0.0 connectport=<puertoWSL> connectaddress=(wsl hostname -I)

En la práctica sustituirías los marcadores por valores concretos, por ejemplo:

netsh interface portproxy add v4tov4 listenport=4000 listenaddress=0.0.0.0 connectport=4000 connectaddress=192.168.101.100

Aquí listenaddress=0.0.0.0 indica que Windows escuchará en todas las IPs IPv4 del host, y reenviará lo que entre por el puerto 4000 a 192.168.101.100:4000, que sería la IP de WSL2 obtenida con:

• wsl hostname -I te da la IP de la distro Linux dentro de la VM WSL2
• cat /etc/resolv.conf te revela la IP del host Windows vista desde WSL2

Con esta técnica puedes hacer que un servicio que corre en WSL2 sea accesible desde cualquier equipo de la LAN, siempre que el firewall de Windows lo permita y tengas claro que estás exponiendo un servicio de una VM, no del host directamente.

IPv6 y características de red modernas

WSL2 también puede trabajar con IPv6, algo especialmente relevante en entornos modernos, VPN y redes corporativas. Para manejar direcciones, los comandos básicos en Linux son equivalentes a los de IPv4:

• wsl hostname -i desde Windows para ver la IP de la distribución WSL2
• ip route show | grep -i default | awk '{ print $3 }' desde Linux para obtener la IP del host Windows

Donde de verdad se nota el salto de calidad en soporte IPv6 y VPN es en el modo de red mirrored, disponible en Windows 11 22H2 y versiones posteriores, que veremos en detalle más adelante.

Modo de red mirrored: reflejando interfaces de Windows en Linux

En equipos con Windows 11 22H2 o superior, puedes activar el modo de red “mirrored” en WSL2, que cambia por completo el modelo: en vez de NAT clásico, Linux “ve” reflejadas las interfaces de red de Windows.

Para habilitarlo, necesitas editar el archivo .wslconfig de tu usuario, que se encuentra en %UserProfile%\.wslconfig. Desde PowerShell con permisos de administrador puedes abrirlo con:

notepad $env:USERPROFILE\.wslconfig

Dentro, añade (o modifica) la sección [wsl2] para activar el modo mirrored:

[wsl2]
networkingMode=mirrored

Una vez guardado el archivo, tienes que reiniciar WSL2 para que surta efecto, por ejemplo con:

wsl --shutdown

Cuando lo vuelvas a arrancar, WSL utilizará la nueva arquitectura de red reflejada, lo que trae varias ventajas muy potentes:

• Compatibilidad nativa con IPv6 y mejor integración con redes corporativas y VPN
• Posibilidad de conectarse a servicios Windows desde Linux usando 127.0.0.1 directamente (aunque no se admite ::1 como loopback IPv6 para esto)
• Soporte de multidifusión mejorado dentro de la integración Windows-Linux
• Acceso directo a WSL desde la LAN sin necesidad de netsh portproxy, usando la IP del propio equipo Windows

Activar este modo resuelve buena parte de los problemas clásicos del NAT de WSL2 y es la opción recomendada en la mayoría de entornos de desarrollo y auto-hosting modernos donde puedas usar Windows 11 actualizado.

Tunelización de DNS y uso de proxies en WSL2

En Windows 11 22H2 y versiones posteriores, la resolución de nombres desde WSL2 también ha recibido un buen lavado de cara. La clave está en dos funcionalidades definidas en .wslconfig: dnsTunneling y autoProxy.

La opción dnsTunneling viene activada por defecto en la sección [wsl2] y hace que las peticiones DNS de Linux se gestionen mediante una característica de virtualización, en lugar de salir como paquetes de red normales. Esto mejora mucho la compatibilidad con VPN y configuraciones de red complejas en el host.

Por su parte, autoProxy=true obliga a que WSL use la configuración de proxy HTTP de Windows. Si el host está detrás de un proxy corporativo o de seguridad, WSL2 lo hereda automáticamente sin que tengas que pelearte con variables de entorno a mano.

Podrías tener, por ejemplo, algo así en tu .wslconfig:

[wsl2]
dnsTunneling=true
autoProxy=true

Con esto te aseguras de que la red de WSL2 se comporte de forma coherente con la configuración del host, especialmente útil en empresas con políticas estrictas de red y filtrado.

Firewall de Hyper-V y exposición segura de servicios

En entornos modernos, la red de WSL2 también pasa a través de un firewall específico. A partir de WSL 2.0.9 en Windows 11 22H2, la característica de firewall de Hyper-V se activa por defecto, lo que añade una capa extra de filtrado para el tráfico de las VMs (incluida la de WSL2).

Si estás trabajando con modo mirrored y quieres exponer permanentemente servicios de WSL2 a la LAN (por ejemplo, APIs, dashboards o servicios de auto-hosting), necesitas asegurarte de que las reglas del firewall lo permiten.

Una aproximación razonable desde PowerShell con permisos de administrador es crear una regla de Hyper-V para redes privadas:

New-NetFirewallHyperVRule -DisplayName "WSLPrivateInboundRule" -Profiles Private -Direction Inbound -Action Allow -VMCreatorId ((Get-NetFirewallHyperVVMCreator).VMCreatorId)

Si por alguna razón quieres desactivar esa protección específica de Hyper-V (algo menos recomendable), podrías usar:

Set-NetFirewallHyperVVMSetting -Name ((Get-NetFirewallHyperVVMCreator).VMCreatorId) -Enabled False

La idea es mantener el firewall activo siempre que sea posible, limitando reglas a redes privadas y solo a los puertos que realmente necesites, y reservando cualquier desactivación masiva como último recurso y siempre con vistas a volver a endurecer la configuración en cuanto todo funcione.

Arquitectura de red de WSL2, X11 y rangos 172.16.0.0/12

Un caso clásico que destapa detalles de la red de WSL2 es el uso de aplicaciones gráficas vía X11, por ejemplo lanzando Xming en Windows y enviando aplicaciones de Linux a través de DISPLAY.

Al pasar de WSL1 a WSL2, muchos usuarios ven cómo X deja de funcionar porque la red deja de estar “compartida” y pasa a ser una red virtual NAT con rangos como 172.16.0.0/12, que además pueden cambiar tras cada reinicio de Windows o de WSL.

Para volver a tener X funcionando con Xming desde WSL2, el truco habitual es obtener la IP de Windows que ve Linux usando:

ens

DISPLAY=$(grep nameserver /etc/resolv.conf | cut -d' ' -f2):0

En paralelo, es necesario ajustar el firewall de Windows para permitir tráfico X11 desde esa subred NAT. Un enfoque típico es editar la regla de Xming añadiendo el rango 172.16.0.0/12 en TCP+UDP 6000.

Muchos terminan desactivando la autenticación de Xming con la opción -ac, lo que efectivamente “abre la puerta” a cualquier cliente X que llegue desde esa red. Funciona, pero desde el punto de vista de seguridad es bastante discutible, así que conviene valorar soluciones más acotadas o el uso de WSLg (aplicaciones GUI integradas) en Windows 11.

wsl.conf y .wslconfig: configuración avanzada de WSL2

WSL ofrece dos archivos de configuración clave que controlan tanto el comportamiento de la VM como el de cada distribución: /etc/wsl.conf (por distro) y %UserProfile%\.wslconfig (global para todas las distros WSL2).

wsl.conf vive dentro de la distribución Linux, en /etc/wsl.conf. Sirve para configurar opciones locales de esa distro: automontajes, generación de hosts y resolv.conf, interoperabilidad con Windows, usuario por defecto, systemd, etc.

.wslconfig se guarda fuera de Linux, en el perfil de usuario de Windows (C:\Users\<Usuario>\.wslconfig) y controla parámetros globales de la VM que alimenta WSL2: memoria, CPUs, kernel, modo de red, firewall, DNS, tamaño del disco virtual, soporte GUI, etc.

Un detalle curioso es la “regla de los 8 segundos” al cambiar configuración: cuando modificas alguno de estos archivos, tienes que asegurarte de que la VM de WSL se apaga de verdad. Aunque cierres la ventana de la distro, puede seguir en memoria unos segundos.

Para forzar el reinicio del subsistema puedes usar:

• wsl --list --running para comprobar si quedan distros activas
• wsl --shutdown para cerrar todas las distribuciones de golpe
• wsl --terminate <distroName> para detener una distro concreta

Solo cuando WSL se apaga y se vuelve a arrancar se aplican realmente los cambios de configuración, algo que muchos pasan por alto y piensan que sus ajustes “no funcionan”.

Opciones principales de wsl.conf por secciones

El archivo wsl.conf está inspirado en el formato .ini clásico, con secciones y claves. Las secciones principales son [automount], [network], [interop], [user], [boot], [gpu] y [time].

En [automount] controlas cómo se montan las unidades de Windows dentro de Linux (típicamente bajo /mnt):

• enabled (bool, por defecto true): si es true, C:/, D:/, etc., se montan automáticamente en /mnt/c, /mnt/d…
• mountFsTab (bool): si está a true, se procesa /etc/fstab al arrancar la distro.
• root (cadena): directorio raíz donde se montarán las unidades, por ejemplo /windir/ para tener /windir/c.
• options (lista separada por comas): parámetros específicos de DrvFs como metadata, uid, gid, umask, fmask, dmask o case.

DrvFs es el sistema de archivos puente entre Windows y Linux, diseñado para acceder a NTFS desde WSL con control de permisos, metadatos y sensibilidad a mayúsculas/minúsculas.

En la sección [network] ajustas la generación automática de ficheros de red:

• generateHosts: si es true, WSL genera automáticamente /etc/hosts.
• generateResolvConf: si es true, WSL crea /etc/resolv.conf con los DNS heredados.
• hostname: nombre de host que usará la distribución.

La sección [interop] controla la interoperabilidad con Windows:

• enabled: habilita o deshabilita la posibilidad de lanzar procesos de Windows desde WSL.
• appendWindowsPath: decide si se añaden rutas de Windows al $PATH de Linux.

En [user] puedes especificar el usuario que se usará por defecto al iniciar la distro:

• default: nombre del usuario que se arrancará por defecto en WSL.

La sección [boot] es particularmente útil en Windows 11 y Server 2022 para lanzar servicios automáticamente, como Docker dentro de WSL:

• command: cadena del comando a ejecutar al iniciar WSL, por ejemplo service docker start.
• protectBinfmt: protege la generación de unidades systemd cuando systemd está activado.

Además tienes secciones como [gpu] (activar acceso a la GPU de Windows desde Linux), y [time] para sincronizar la zona horaria con Windows, lo que evita desajustes cuando cambias de horario de verano o viajas.

.wslconfig: control de la máquina virtual de WSL2

Si wsl.conf afina el comportamiento de cada distro, .wslconfig permite tunear la VM compartida por todas las distros WSL2. Este archivo solo lo tienen en cuenta las distros que se ejecutan como WSL2, no WSL1.

Dentro de .wslconfig la sección principal es [wsl2], donde defines parámetros clave:

• kernel y kernelModules: rutas absolutas de Windows a un kernel Linux personalizado y sus módulos.
• memory: límite de memoria de la VM (por defecto 50 % de la RAM del host), por ejemplo 4GB.
• processors: número de procesadores lógicos asignados a la VM.
• localhostForwarding: permite que los puertos abiertos en WSL2 sean accesibles desde Windows usando localhost.
• swap y swapFile: tamaño y ruta del archivo de swap para la VM.
• guiApplications: activa o desactiva el soporte de aplicaciones GUI (WSLg).
• dnsProxy: cuando estás en modo NAT decide si el servidor DNS de Linux será la instancia NAT del host o una copia de los DNS de Windows.
• networkingMode: aquí eliges entre none, nat, bridged (en desuso), mirrored o virtioproxy.
• firewall, dnsTunneling y autoProxy: opciones que hemos comentado para integrar mejor la red de WSL con las políticas de Windows.
• defaultVhdSize: tamaño máximo del VHD donde se almacena el sistema de archivos de la distro (por defecto 1 TB).

También hay una sección [experimental] donde se activan características en pruebas como:

• autoMemoryReclaim: ajustes de recuperación automática de memoria (disabled, gradual, dropCache).
• sparseVhd: creación de discos virtuales dispersos para ahorrar espacio.
• bestEffortDnsParsing y dnsTunnelingIpAddress: ajustes finos para la tunelización DNS.
• ignoredPorts: puertos que las apps Linux pueden usar incluso si están ocupados en Windows cuando estás en modo mirrored.
• hostAddressLoopback: permite que host y contenedor se conecten usando direcciones IP locales del host en modo mirrored.

Configurar correctamente .wslconfig marca la diferencia entre una VM derrochadora de recursos y un entorno optimizado que se lleva bien con tu Windows y tu red, sobre todo si trabajas con cargas de trabajo pesadas, contenedores o múltiples distros simultáneas.

WSL2, Docker y redes para auto-hosting con Tailscale

Un caso muy práctico es usar WSL2 en servidores Windows (incluso Windows Server 2025) como plataforma de auto-hosting, combinando Ubuntu en WSL2, Docker Engine (sin Docker Desktop), Tailscale y un proxy inverso como Caddy para exponer servicios tipo n8n o Supabase.

La idea es tener un entorno Docker estable dentro de WSL2, evitando los problemas de Docker Desktop en servidores. Al instalar Docker Engine directamente en Ubuntu (WSL2), la red de los contenedores se apoya sobre la red de WSL2, que a su vez depende del modo NAT o mirrored definido en .wslconfig.

Con Tailscale instalado en WSL2 puedes publicar tus servicios en una VPN mesh sin abrir puertos en el router, y usar Caddy como proxy inverso para centralizar certificados TLS, rutas y balanceo ligero entre contenedores.

Para mantener una red limpia, predecible y segura conviene:

• Elegir un solo modo de red coherente (NAT o mirrored) y documentarlo
• Evitar conflictos de puertos entre Windows y WSL2, apoyándote en ignoredPorts si usas mirrored
• Controlar la exposición de servicios únicamente vía Tailscale o Caddy, en lugar de abrir puertos “a pelo” en el firewall
• Automatizar el arranque de Docker, Tailscale y Caddy desde [boot] en wsl.conf para tener un entorno más cercano a producción

Con esta arquitectura, WSL2 deja de ser solo una herramienta de desarrollo y puede convertirse en una plataforma de auto-hosting bastante seria, siempre que asumas sus límites (virtualización sobre Hyper-V, capa de red adicional, etc.) y la configures con mimo.

Buenas prácticas de red en WSL2 para desarrollo y pruebas

Al margen de la configuración fina, hay una serie de pautas que ayudan a trabajar cómodo con la red de WSL2 sin estar constantemente peleándote con IPs, puertos y firewalls.

Para servicios de desarrollo, utiliza puertos altos (por encima de 1024) y evita los puertos privilegiados o muy utilizados por el sistema; así minimizas conflictos y no necesitas privilegios extra.

Procura que el código y los datos vivan dentro del sistema de archivos Linux (tu ~/ o rutas internas) en lugar de trabajar directamente sobre /mnt/c, ya que el acceso a NTFS desde WSL es más lento y puede penalizar servicios intensivos en I/O.

Automatiza los ajustes de red y reglas de redirección con scripts en PowerShell y Bash: por ejemplo, un script que al arrancar WSL2 configure netsh portproxy (si sigues con NAT) o verifique reglas de firewall cuando usas mirrored.

Evita depender de IPs cambiantes generadas por el switch virtual interno. Siempre que puedas, trabaja con localhost, nombres de host o entradas en /etc/hosts para tus servicios, de modo que un cambio de IP no te rompa media infraestructura de pruebas.

En entornos profesionales o semi-productivos, es mejor no confiar ciegamente en los reenvíos automáticos de WSL. Configura explícitamente puertos, proxies y reglas de firewall para saber exactamente qué está expuesto y dónde.

Bien configurado, WSL2 ofrece una red aislada pero flexible, perfecta para desarrollo avanzado, pruebas de APIs, trabajo con contenedores y simulación de entornos distribuidos. La clave está en dominar los modos de red (NAT vs mirrored), los archivos wsl.conf y .wslconfig, y la interacción con el firewall y las herramientas de tu stack (Docker, Tailscale, proxies inversos), de forma que Windows y Linux jueguen en el mismo equipo sin pisarse los puertos ni comprometer la seguridad.