WSL steals UDP Ports from Windows

[avlec]

Windows Version

Microsoft Windows [Version 10.0.22621.3880]

WSL Version

2.3.24.0

Are you using WSL 1 or WSL 2?

• WSL 2
• WSL 1

Kernel Version

5.15.153.1-2

Distro Version

Ubuntu 24.04

Other Software

Using python to check for a basic UDP socket connection to rule out application specific quirks.

Repro Steps

Launch WSL. Try opening UDP ports until you get the following error message and that doesn't correspond to a port a real application is using in WSL or Windows (checked via netstat).

OSError: [WinError 10048] Only one usage of each socket address (protocol/network address/port) is normally permitted

I was seeing a large range of ports that were unusable after starting WSL. I was seeing this range [44619, 48715] (4097 ports) being made un-bindable. If I start WSL with some application using a port in that range the range would shift. I was seeing this shift down to [37794, 41890] (4097 ports)

Expected Behavior

Launching WSL doesn't cause a blanket range of ports to be made unavailable in Windows but are still available in WSL. The ports shouldn't be

Actual Behavior

Launching WSL causes a blanket range of ports to be made available only inside WSL.

That is I can open UDP sockets on those ports within WSL but not in Windows.

Diagnostic Logs

No response

[github-actions]

Logs are required for review from WSL team

If this a feature request, please reply with '/feature'. If this is a question, reply with '/question'.
Otherwise please attach logs by following the instructions below, your issue will not be reviewed unless they are added. These logs will help us understand what is going on in your machine.

How to collect WSL logs

Download and execute collect-wsl-logs.ps1 in an administrative powershell prompt:

Invoke-WebRequest -UseBasicParsing "https://raw.githubusercontent.com/microsoft/WSL/master/diagnostics/collect-wsl-logs.ps1" -OutFile collect-wsl-logs.ps1
Set-ExecutionPolicy Bypass -Scope Process -Force
.\collect-wsl-logs.ps1

The script will output the path of the log file once done.

If this is a networking issue, please use collect-networking-logs.ps1, following the instructions here

Once completed please upload the output files to this Github issue.

Click here for more info on logging
If you choose to email these logs instead of attaching to the bug, please send them to wsl-gh-logs@microsoft.com with the number of the github issue in the subject, and in the message a link to your comment in the github issue and reply with '/emailed-logs'.

View similar issues

Please view the issues below to see if they solve your problem, and if the issue describes your problem please consider closing this one and thumbs upping the other issue to help us prioritize it!

Open similar issues:

• Applications running on host not receiving UDP multicast packets sent from WSL2 (#12122), similarity score: 0.71

Closed similar issues:

• WSL2 and Windows can bind listening TCP socket on 127.0.0.1 using same port without setting SO_REUSEADDR (#7150), similarity score: 0.74
• WSL does not report EADDRINUSE properly (#4407), similarity score: 0.73
• Huge amount of ports are being reserved (#5306), similarity score: 0.73
• Windows style WSL SO_REUSEADDR behaviour makes RPC over TCP unreliable (#3909), similarity score: 0.72

Note: You can give me feedback by thumbs upping or thumbs downing this comment.

[avlec]

/question

[github-actions]

Diagnostic information

Found '/question', adding tag 'question'

[zcobol]

@avlec please specify what networkingMode you're using.

[avlec]

Sorry I meant to put that in the post. I'm using mirrored networking

[OneBlue]

This is probably due to the fact that mirrored networking pre-reserves ports when starting WSL. assigning to @keith-horton

[keith-horton]

Right - this is by design with Mirrored mode.

Because Windows uses a global port pool, and mirrored mode forwards packets so the container has the same MAC and IP addressing as the host, we must give the WSL container a unique range of TCP+UDP ports that Linux can use as its ephemeral ports.
Similarly, if an application in WSL tries to directly bind() to a port, we must ensure it's 'reserved' on the host so that it's exclusively used by the WSL container.

[avlec]

Thanks for the response. I assumed it was something intentional. The problem I am running into is that the port ranges seem to for some reason now be consistently overlapping with ports an application in Windows needs to use which cause that application to not be able to function properly.

Workaround is OK but not ideal. However, there is no indication in Windows explaining that WSL is using these ports. That makes identifying this as the issue challenging.

[keith-horton]

Yeah, sorry about the confusion. If you launch the apps before starting WSL, we'll keep moving to find a different contiguous port range to configure in Linux.

If you need to know what was configured, you can run something like the following in Linux to read the programmed ephemeral port range: sysctl net.ipv4.ip_local_port_range.

[keith-horton]

if it's cool with you, I'll go ahead and close this.

[avlec]

Yeah that's the workaround I got to anyways. Or shutting down WSL then opening the app that uses the ports. However, I did notice that sometimes after closing WSL that some ports were still unbind-able, that might be worth looking into.

The workaround seems fine, as this is buried in internals it might change spontaneously one day and work better.

Thanks for the help, and for pointing out the sysctl endpoint