search

microsoft / WSL

Issues found on WSL
https://docs.microsoft.com/windows/wsl
MIT License
17.55k stars 823 forks source link

Mirrored networking does not loopback the entire 127.0.0.0/8 range #11766

Open GingerGeek opened 4 months ago

GingerGeek commented 4 months ago

Windows Version

Microsoft Windows [Version 10.0.22635.3858]

WSL Version

2.2.4.0

Are you using WSL 1 or WSL 2?

Kernel Version

5.15.153.1-2

Distro Version

Fedora 40

Other Software

Ncat: Version 7.95 ( https://nmap.org/ncat ) netcat.x86_64 1.226-3.fc40 @fedora

Believe this is also the root cause of docker/for-win#14184

Repro Steps

Using netcat from within a WSL2 session and ncat from a Powershell session on the same machine.

Executing the nc -l commands before attempting the ncat connections

zed@gingerpad ~
> nc -l 127.0.0.1 12345
This line is a sent message from Powershell to WSL2
This line is a sent message from WSL2 to Powershell
zed@gingerpad ~
> nc -l 127.0.0.2 12345
This message can't go anywhere because nothing is connected!
C:\Users\Zed> ncat 127.0.0.1 12345
This line is a sent message from Powershell to WSL2
This line is a sent message from WSL2 to Powershell
C:\Users\Zed> ncat 127.0.0.2 12345
Ncat: No connection could be made because the target machine actively refused it. .
C:\Users\Zed>

wsl.conf excerpt

[wsl2]
networkingMode=mirrored
firewall=true
dnsTunneling=true

[experimental]
hostAddressLoopback=true

Expected Behavior

Binding to any loopback address within 127.0.0.0/8 is mirrored/relay to the Windows OS.

127.20.30.1:12345 in WSL2 <-> 127.20.30.1:12345 within Windows

Actual Behavior

Only when binding to 127.0.0.1, all-hosts (0.0.0.0) or another specific IP assigned to the machine (only when )

hostAddressLoopback=true has no impact on the loopback behaviour - will only every pass through 127.0.0.1.

Diagnostic Logs

No response

github-actions[bot] commented 4 months ago

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](https://github.com/Microsoft/WSL/blob/master/diagnostics/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 scipt will output the path of the log file once done. Once completed please upload the output files to this Github issue. [Click here for more info on logging](https://github.com/microsoft/WSL/blob/master/CONTRIBUTING.md#8-collect-wsl-logs-recommended-method) 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:

Closed similar issues:

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

GingerGeek commented 4 months ago

/emailed-logs

github-actions[bot] commented 4 months ago
Diagnostic information ``` Found '/emailed-logs', adding tag 'emailed-logs' ```
shigenobuokamoto commented 4 months ago

it looks like support is progressing in WSL 2.3.11.

windows host        linux(wsl)

ok 127.0.0.1 -> 127.0.0.0/8 ng 127.0.0.0/8 <- 127.0.0.0/8

but by tweaking the routing table, the windows host was also able to access the entire 127.0.0.0/8.

ip r add 127.0.0.0/8 via 169.254.73.152 dev loopback0 table 127 proto kernel src 127.0.0.1 onlink
ip r del 127.0.0.1 table 127
CatalinFetoiu commented 4 months ago

hello. thanks for reporting the issue

this is currently by design - only 127.0.0.1 can be used for communicating between Windows and Linux.

one of the reasons is that systemd uses IP 127.0.0.53 as its DNS resolver. it's preferred for traffic to this IP to stay inside Linux instead of going to Windows over the loopback0 interface and back to Linux on the loopback0 interface, as this can risk something on Windows blocking the traffic and breaking systemd

GingerGeek commented 4 months ago

It would be good if we could at least get some support or documentation on how we could expand even parts of the local range.