Can't access UDP services running in WSL on localhost

[Jimmy-Z]

Version

Microsoft Windows [Version 10.0.19043.1889]

WSL Version

• [X] WSL 2
• [ ] WSL 1

Kernel Version

5.10.102.1

Distro Version

Debian 11

Other Software

No response

Repro Steps

start a UDP service in WSL, like nc:

nc -ul 5000

talk to that service from host, since windows doesn't come with nc, I'm actually using nc from msys2:

nc -u 127.0.0.1 5000

and type something in nc and press enter.

Expected Behavior

We should be able to access that service on localhost, like when we type something in nc and press enter, the same thing should show on the other side.

As the document says so: https://docs.microsoft.com/en-us/windows/wsl/networking#accessing-linux-networking-apps-from-windows-localhost

Actual Behavior

We can't.

Diagnostic Logs

• if we remove -u thus let nc listen on TCP, it will work.
• if we replace 127.0.0.1 with WSL's actual address(172...), it will work.

My conclusion is that WSL is not forwarding UDP, which is inconsistent with the document.

There seems to be similar issue reports, but they are too specific, this is actually a more generic and broad issue. https://github.com/microsoft/WSL/issues/6351

[NotTheDr01ds]

This sounds like it is probably the same root cause as #8610. A few questions:

• Do you have either KB5015807 or KB5016616 installed? Reportedly, the problem started in one (or both) of those (Windows 10, I believe) updates. I have KB5016616 installed on my Windows 10 system and have the problem there, but I also have the problem on Windows 11 where neither of those hotfixes is installed (so it's probably a different hotfix there).

  Side-note: You can check installed hotfixes from an Admin PowerShell using Get-Hotfix

• Assuming this is your issue, running ethtool -K eth0 tx off per this comment should also workaround the issue. It's not ideal, but the Hyper-V team appears to be investigating the issue.

[Jimmy-Z]

Thanks for the info.

• I do have KB5016616 installed.

• But turning off tx offload doesn't solve this issue, it's exactly the same as before.

Also I noticed tcpdump shows the traffic(tcp, where it works) is on lo instead of eth0, , so I don't think it would help.

And I think this is totally different from #8610

8610:

• talk via eth0, the address he's using is 172...
• specific size of udp traffic: <12 bytes.
• specific direction of udp traffic: wsl -> host.

I can't reproduce #8610 on my machine

while in my case:

• talk via lo/127.0.0.1.
• size doesn't matter, I tried over 12 bytes, it also doesn't work.
• I tried tcpdump in wsl, packets from host never arrived.

[NotTheDr01ds]

@Jimmy-Z

But turning off tx offload doesn't solve this issue, it's exactly the same as before.

And I think this is totally different from https://github.com/microsoft/WSL/issues/8610

Agreed then - Sounds like a different issue to me as well based on that.

[davidtphx]

Not a real fix, but a workaround: From WSL2, run the ifconfig command. Take whatever inet IP address the eth0 interface is set to use, and try connecting to that IP:. You just can't use localhost or 127.0.0.1 with UDP for some reason!

[boan-jfm]

Could this be related #9095?

[Jimmy-Z]

Could this be related #9095?

Yeah I think that is the same bug.

[stevenh]

Seeing the same running on latest pre-release:

WSL version: 1.2.4.0
Kernel version: 5.15.90.1
WSLg version: 1.0.51
MSRDC version: 1.2.3770
Direct3D version: 1.608.2-61064218
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.22621.1555

Confirmed with netcat its limited to where the destination in native Windows is WSL and is specified by a loopback address and is UDP. It effects both IPv4 and IPv6.

[juanbaromance]

I am not sure about where the flaw is really emplaced

If the docker container runs nc -lu 54321 you can push UDP data from the Windoze box with i.e. using bash and the ncat utilities with echo "Alive" | ncat -u 172.28.187.150 54321 And it behaviors like expected

Seen Alive on the container shell, one could argue that the UDP data flow is correctly routed from the Windows box

However the failure appears when the data is received from the outside of the windows box, more specifically when the proxy part is required through the recommend action netsh interface portproxy add v4tov4 listenaddress={YourWindowsIPaddressHere} listenport=54321 connectaddress=172.28.187.150 connectport=54321

Such stuff only works when the TCP is involved

Any progress related with ?

[Jimmy-Z]

I am not sure about where the flaw is really emplaced

If the docker container runs nc -lu 54321 you can push UDP data from the Windoze box with i.e. using bash and the ncat utilities with echo "Alive" | ncat -u 172.28.187.150 54321 And it behaviors like expected

Seen Alive on the container shell, one could argue that the UDP data flow is correctly routed from the Windows box

However the failure appears when the data is received from the outside of the windows box, more specifically when the proxy part is required through the recommend action netsh interface portproxy add v4tov4 listenaddress={YourWindowsIPaddressHere} listenport=54321 connectaddress=172.28.187.150 connectport=54321

Such stuff only works when the TCP is involved

Any progress related with ?

That's a different issue, read OP.

[sfostersaab]

This has caused me headache while trying to connect from windows to containers that bind to UDP ports running in WSL. I have tried the suggestions above but none of them work.

I am quite shocked that basic UDP communication is not functional.

[winne42]

@jstarks Is Microsoft aware of this quite fundamental problem? (you commented on #8610 but not here)

(confirming this problem on Win 10 22H2 19045.3324 with Ubuntu 20.04; TCP works, UDP doesn't; if using WSL's actual address (172...), UDP works)

[winne42]

The new experimental networking mode "mirrored" seems to be a possible solution, cf. #4150 (so far only available to Windows Insiders)

[xgalaxy]

It would be helpful if someone could report if any of the new networking options in the Windows Insiders build fix this issue.

[checkraisefold]

I tried using the new mirrored networking mode, and was met with successful UDP outbound to external internet, but somehow completely inaccessible from localhost. The supposedly newly-supported multicast also didn't work over UDP, as seen in this new discussion: https://github.com/microsoft/WSL/discussions/10614

Absolutely insane that there is this little support for such a fundamental protocol. Apparently this is by design (lol) https://github.com/microsoft/WSL/issues/8868#issuecomment-1597467686

[checkraisefold]

Actually, I just got it working! Works fine after turning hostAddressLoopback to true. Pretty much flawless UDP communication now!

[checkraisefold]

Actually, I just got it working! Works fine after turning hostAddressLoopback to true. Pretty much flawless UDP communication now!

An issue I noticed is that UDP seems to completely randomly break sometimes. WSL shutdown/reboot is not sufficient to fix this; a whole PC restart was the only thing that fixed the issue. Don't even know where to begin debugging that, can't repro it very often.

[sacefe]

it does not worked for me, sad to find out is by design :(

[matthid]

I ran into the same problem to forward some UDP ports and I wrote some lines of rust to do it. There you go: https://github.com/matthid/UdpPortForwarder Works for my use-case but be careful with production workloads.

[warent]

Ran into this, unfortunately. Docker for now I guess.

[Abhinav0002]

Can you Bridged Adapter here, by creating a virtual switch using Hyper-V and attaching it to the distribution.