WSL2 172.XXX.XXX.XXX ip address thing

Question

Got a WSL2 Kali-linux machine on my windows.

For some reason WSL2 has issues with network adapters. It only shows a specific network adapter with an address of 172.xxx.xxx.xxx.

The problem is I can't interact directly with other IPs assigned to me. For example - listen on a specific address.

I do cyber security so one scenario where it implicates my work is:

• got a vpn local address assigned to me, say 10.7.3.120 (configured through my windows host)
• I run code on a remote machine that suppose to connect back to me

Now, I need to put an an hardcoded IP address in the code:

• if I hardcode 172.1.11.11 my wsl will be able to bind incoming connection but the remote machine won't know how to reach me
• if I hardcode 10.7.3.120 the remote machine will able to reach me but wsl won't let me bind because it doesn't recognizes that address

I hope this scenario will be able explain the problem correctly.

Thanks.

Answer 1

I do keep both WSL1 and WSL2 instances around, but more for the faster NTFS filesystem access in WSL1 (when I need it) than for the networking. WSL2 is actually more capable when it comes to networking than WSL1, but that power comes at a price. To give WSL2 a "real" networking stack and still be able to get it in the Windows release on time, the WSL team was apparently forced to launch it without getting bridging working out-of-the-box.

Unfortunately, to truly recommend whether you should pursue getting this working on WSL2 further, you'd need to provide some more details on what you are trying to accomplish in your question. "Need to set configuration on a remote host" just isn't enough for me to go on. It's not even clear from your question whether you are connecting to the VPN through Windows or through Kali.

In the meantime, though, checkout out some other questions on the topic where I've answered with suggestions - here, here, and (also related to VPN, despite bad titling) here.

The simplest solution is definitely WSL1, and you'll see that in most of my answers related to this topic.

Answer 2

Check Wsl-IpHandler on GitHub. Usage is quite simple. I recommend read README.md fully, but here is a basic example:

Invoke-WebRequest https://raw.githubusercontent.com/wikiped/Wsl-IpHandler/master/Install-WslIpHandlerFromGithub.ps1 | Select -ExpandProperty Content | Invoke-Expression
Install-WslIpHandler -WslInstanceName Ubuntu-22.04 -GatewayIpAddress 192.168.65.1 -WslInstanceIpAddress 192.168.65.2 -PrefixLength 29 -UseScheduledTaskOnUserLogOn -WindowsHostName windows

If you don't plan to use Install-WslIpHandler later, you can add -DontModifyPsProfile flag to not modify PSProfile.

Answer 3

Because WSL 2 is running in a virtual machine, you can never actually get direct access to the host’s physical network adapters. (Technically you can, using Discrete Device Assignment AKA device passthrough, but not on consumer Windows Hyper-V.) This means you cannot listen on your host’s IP addresses. You can use port forwarding though.

Even so-called bridged mode does not give you access to the physical interface, but it’s the next best thing. It’s like plugging another PC into the same network cable.

Since this question was created, WSL 2 has gained experimental support for bridged mode in version 0.51.2 and above (Windows 11 exclusive). To enable it, add the following to your .wslconfig:

[wsl2]
networkingMode = bridged
vmSwitch = My-Bridged-vSwitch

You also have to create the virtual switch. This means you need Hyper-V. This means you need Windows 11 Pro.

Be aware that doing this has severe implications. All your WSL 2 distros will now be exposed directly to whatever network My-Bridged-vSwitch is connected to. They will acquire their IP address using DHCP (or whatever other mechanism is set up). WSL localhost binding may no longer function. All this will most likely not work with Wi-Fi adapters.

---

For penetration testing and the like, my strong recommendation is to dual-boot Linux and Windows, using whatever is appropriate for the task at hand.