IPv4 loopback (127.0.0.1) port forwarding fails after wsl --shutdown while IPv6 (::1) continues to work

[DragonBishop]

Windows Version

Microsoft Windows [Version 10.0.26200.8875]

WSL Version

2.7.10.0

Are you using WSL 1 or WSL 2?

• WSL 2
• WSL 1

Kernel Version

6.18.33.2-2

Distro Version

Ubuntu 26.04 LTS

Other Software

k3s version v1.36.2+k3s1 (01b6f04a)
go version go1.26.4

.wslconfig settings:

[wsl2]
dnsTunneling=true
autoProxy=true

[experimental]
autoMemoryReclaim=gradual
sparseVhd=true

I don't use mirrored networking because it clashes with cilium in my k3s cluster.

Repro Steps

1. From WSL, cleanly stop any services listening on the port in question. I was running a k3s cluster with port 6443.
2. Run Powershell as Admin: wsl --shutdown
3. Reopen a WSL terminal (fresh VM boot).
4. WSL: start the service back up (I use a .sh script to manually wind up or down my cluster safely)
5. WSL: confirm the API server is listening: sudo ss -tlnp | grep 6443
6. WSL: confirm the cluster is healthy: kubectl get nodes
7. Windows PowerShell: Test-NetConnection -ComputerName localhost -Port 6443
8. Windows PowerShell: Test-NetConnection -ComputerName 127.0.0.1 -Port 6443

Expected Behavior

Both localhost and 127.0.0.1 should reach the service listening inside the fresh WSL2 VM, since WSL2's default NAT networking mode forwards both.

Actual Behavior

localhost (resolves to ::1, IPv6) connects successfully. 127.0.0.1 (IPv4) fails to connect, even though step 5 confirms the target process is listening on the port.

Diagnostic Logs

Evidence

Step 5 confirms the process is listening:

$ sudo ss -tlnp | grep 6443
LISTEN 0 4096 *:6443 : users:(("k3s-server",pid=449,fd=12))

Step 6 confirms the cluster/node is healthy:

$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
portis Ready control-plane 9d v1.36.2+k3s1

Step 7 localhost (IPv6) succeeds:

PS C:\Users\dragonbishop> Test-NetConnection -ComputerName localhost -Port 6443
ComputerName : localhost
RemoteAddress : ::1
RemotePort : 6443
InterfaceAlias : Loopback Pseudo-Interface 1
SourceAddress : ::1
TcpTestSucceeded : True

Step 8 127.0.0.1 (IPv4) fails:

PS C:\Users\dragonbishop> Test-NetConnection -ComputerName 127.0.0.1 -Port 6443
WARNING: TCP connect to (127.0.0.1 : 6443) failed
ComputerName : 127.0.0.1
RemoteAddress : 127.0.0.1
RemotePort : 6443
InterfaceAlias : Loopback Pseudo-Interface 1
SourceAddress : 127.0.0.1
PingSucceeded : True
PingReplyDetails (RTT) : 0 ms
TcpTestSucceeded : False

In addition, Windows Headlamp fails to connect to the cluster despite having access to the same .kubeconfig that I use to mount my devcontainer in WSL, which I can confirm works for applications within WSL2.

I experimented with a full computer restart, and checking to see if a VPN was causing the problem, neither of which had any impact.

[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-wsl-logs.ps1 -LogProfile networking instead, following the instructions in Collect WSL logs for networking issues

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

See Collect WSL logs (recommended method).

If you choose to email these logs instead of attaching them to the bug, please send them to wsl-gh-logs@microsoft.com with the GitHub issue number in the subject, and include a link to your GitHub issue comment in the message body, and reply with '/emailed-logs'.

[shuaiyuanxx]

@DragonBishop Thanks for reporting this issue. this looks similar to #4851, but we need more information to confirm. Could you please share the output of:

ss -4lntp '( sport = :6443 )'
ss -6lntp '( sport = :6443 )'
ss --inet-sockopt -lntp '( sport = :6443 )'

And from Windows:

Get-NetTCPConnection -State Listen -LocalPort 6443

[DragonBishop]

Thanks for the quick response! I saw the similarities with #4851 but didn't see this specific wrinkle, and wanted to make sure it got documented before I moved my computer to a linux distro with a windows VM vs. WSL2, as I'm encountering some networking issues that would just be easier to handle in linux.

PS C:\Users\dragon_bishop> Get-NetTCPConnection -State Listen -LocalPort 6443

LocalAddress                        LocalPort RemoteAddress                       RemotePort State       AppliedSetting
------------                        --------- -------------                       ---------- -----       --------------
::1                                 6443      ::                                  0          Listen

dragonbishop@Portis:~$ ss -4lntp '( sport = :6443 )'
State        Recv-Q        Send-Q               Local Address:Port               Peer Address:Port       Process
dragonbishop@Portis:~$ ss -6lntp '( sport = :6443 )'
State         Recv-Q        Send-Q               Local Address:Port               Peer Address:Port       Process
LISTEN        0             4096                             *:6443                          *:*
dragonbishop@Portis:~$ ss --inet-sockopt -lntp '( sport = :6443 )'
State         Recv-Q        Send-Q               Local Address:Port               Peer Address:Port       Process
LISTEN        0             4096                             *:6443                          *:*
        inet-sockopt: ( is_icsk mc_loop)

[shuaiyuanxx]

Thanks @DragonBishop

This matches #4851: k3s only has an IPv6 listener, so WSL creates ::1:6443 but not 127.0.0.1:6443.

Could you confirm whether the socket is dual-stack?

sudo ss -6lntpe '( sport = :6443 )'
nc -vz -4 127.0.0.1 6443
nc -vz -6 ::1 6443

If both connections succeed inside WSL, this confirms the known localhost relay limitation. As a workaround, configure k3s to listen explicitly on IPv4.