2

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.

Trigosin Darom
  • 31
  • 1
    Thanks for adding some details - It's starting to be more clear. One more question for now - When Windows is connected via VPN, does Kali/WSL2 still have networking access? Can it, for example, ping 8.8.8.8? Some VPN's operate in a full tunnel mode that will essentially "kill" any other VM adapters' networking (such as WSL2). Need to know if that is the case, since it may change how we approach it. – NotTheDr01ds Feb 02 '21 at 23:54
  • Also, is the traffic that needs to reach Kali/WSL2 coming in over a known port? – NotTheDr01ds Feb 02 '21 at 23:56
  • I can do anything when it comes to outbound connections. However, as I explained, I can't listen or dump traffic on a specific address, remote machines can't initiate a connection with me. Regarding the incoming traffic I described - I don't think I used a known port, but I don't see how using a known one would make any difference. Thanks for your response. – Trigosin Darom Feb 03 '21 at 01:52

3 Answers3

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.

NotTheDr01ds
  • 21,923
  • I just came to realization that running kali on wsl1 would be bad because I'd very limited. Many networking tools are unusable on ws1. Regarding my problem with ws2 - when I use VPN I get a new local address. Other instances in that network try to initiate connection with that address but they fail. My wsl2 won't recognize that address. – Trigosin Darom Feb 01 '21 at 21:10
  • If you are connecting to the VPN through Windows, then a WSL2 instance's networking capability is going to be very limited. Again, need to know what you are trying to do. What service are you trying to access with "other instances in that network", what application are you trying to run? There may be workarounds you can use, but it's going to be dependent on what you are trying to accomplish. Be detailed, and edit the question, not a comment, please. – NotTheDr01ds Feb 01 '21 at 22:11
  • Thanks for your response. I edited my post. – Trigosin Darom Feb 02 '21 at 23:39
0

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.

dragoangel
  • 1
  • 1
  • 1
    This will not solve OP’s issues. They are intrinsic to WSL 2 networking. – Daniel B Oct 31 '22 at 13:38
  • Misslooked, yeah, but actually OP can bind service to wildcard on WSL, and this will be available on host IP network, so he need to share Windows IP (host) in hist reverse shell or whatever scripts he run. – dragoangel Nov 01 '22 at 14:06
  • “and this will be available on host IP network”—it won’t. Not without port forwarding. Because by default WSL 2 uses NAT networking. – Daniel B Nov 01 '22 at 15:54
  • it will be available on loopback interface without any actions, to be available on any IP on host OS - yes, need to NAT or proxy it – dragoangel Nov 02 '22 at 16:25
0

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.

Daniel B
  • 62,883