Skip to content

WSL steals UDP Ports from Windows #12228

New issue
New issue
Closed
Closed
WSL steals UDP Ports from Windows#12228
Assignees
keith-horton
Labels
networkquestion

Description

@avlec
Alec C (avlec)
opened on Nov 1, 2024

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

Activity

  1. github-actions commented on Nov 1, 2024

    @github-actions
    github-actionsBot
    on Nov 1, 2024 – with GitHub Actions
    Contributor

    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 [email protected] 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:

    Closed similar issues:

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

  2. github-actions
    added
    needs-author-feedback
    on Nov 1, 2024

  3. avlec commented on Nov 1, 2024

    @avlec
    Alec C (avlec)
    on Nov 1, 2024
    Author

    /question

  4. microsoft-github-policy-service
    removed
    needs-author-feedback
    on Nov 1, 2024

  5. github-actions commented on Nov 1, 2024

    @github-actions
    github-actionsBot
    on Nov 1, 2024 – with GitHub Actions
    Contributor
    Diagnostic information 
    Found '/question', adding tag 'question'
  6. github-actions
    added
    question
    on Nov 1, 2024

  7. zcobol commented on Nov 2, 2024

    @zcobol
    Toto (zcobol)
    on Nov 2, 2024

    Alec C (@avlec) please specify what networkingMode you're using.

  8. avlec commented on Nov 2, 2024

    @avlec
    Alec C (avlec)
    on Nov 2, 2024
    Author

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

  9. Blue (OneBlue)
    added
    network
    on Nov 5, 2024
  10. Blue (OneBlue)
    assigned
    Keith Horton (keith-horton)
    on Nov 5, 2024

  11. OneBlue commented on Nov 5, 2024

    @OneBlue
    Blue (OneBlue)
    on Nov 5, 2024
    Collaborator

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

  12. keith-horton commented on Nov 5, 2024

    @keith-horton
    Keith Horton (keith-horton)
    on Nov 5, 2024
    Member

    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.

  13. avlec commented on Nov 10, 2024

    @avlec
    Alec C (avlec)
    on Nov 10, 2024
    Author

    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.

  14. keith-horton commented on Nov 11, 2024

    @keith-horton
    Keith Horton (keith-horton)
    on Nov 11, 2024
    Member

    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.

  15. keith-horton commented on Nov 11, 2024

    @keith-horton
    Keith Horton (keith-horton)
    on Nov 11, 2024
    Member

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

  16. Keith Horton (keith-horton)
    closed this as completedon Nov 11, 2024

  17. avlec commented on Nov 11, 2024

    @avlec
    Alec C (avlec)
    on Nov 11, 2024
    Author

    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

  18. savely-krasovsky commented on Apr 2, 2025

    @savely-krasovsky
    Savely Krasovsky (savely-krasovsky)
    on Apr 2, 2025

    Alec C (@avlec) in my case I cannot bind neither TCP or UDP at this exact port range. Our corporate VPN uses port within range to receieve authorization code callback from OAuth2 flow and fails to run local HTTP server due to this problem. wsl.exe --shutdown helps, but are there any proper solutions? Why it occupies those ports only after running some amount of time?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

networkquestion

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions