microsoft / microsoft/WSL

DNS tunneling endpoint 10.255.255.254 intermittently starts refusing connections with mirrored networking

Open
#41,595 3 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

network
Dominant language
C++
Stars
33.7k
Forks
1.8k
Avg merge
3d 17h
Merged PRs (30d)
116

Description

### Windows Version

Microsoft Windows [Version 10.0.26200.9168]

### WSL Version

2.9.11.0

### Are you using WSL 1 or WSL 2?

- [x] WSL 2
- [ ] WSL 1

### Kernel Version

6.18.40.1-microsoft-standard-WSL2

### Distro Version

Ubuntu-22.04

### Other Software

Windows host has multiple active network adapters/tunnels:

Tailscale
WireGuard tunnel used for remote WSL access
Another WireGuard VPN
Physical Ethernet

WSL configuration:

[wsl2]
networkingMode=mirrored
dnsTunneling=true

[experimental]
bestEffortDnsParsing=true

Environment:

Windows: 10.0.26200.9168
WSL: 2.9.11
Kernel: 6.18.40.1-microsoft-standard-WSL2
Distribution: Ubuntu 22.04

The same issue was also reproduced previously on WSL 2.7.14 with kernel 6.18.33.2-microsoft-standard-WSL2.

### Repro Steps

The failure is intermittent rather than immediately reproducible.

Start WSL with networkingMode=mirrored and dnsTunneling=true.
Use WSL normally for several hours.
Eventually applications begin failing DNS lookups with errors such as:
getaddrinfo ETIMEOUT
getaddrinfo EAI_AGAIN
Test the WSL DNS tunneling endpoint:
nslookup google.com 10.255.255.254

Result:

;; communications error to 10.255.255.254#53: connection refused
;; communications error to 10.255.255.254#53: connection refused
;; communications error to 10.255.255.254#53: connection refused
;; no servers could be reached
At the same time, direct IP connectivity still works:
ping -c 2 1.1.1.1

Result: successful, 0% packet loss.

Direct DNS also still works:
dig @1.1.1.1 google.com
dig @192.168.8.1 google.com

Both return valid responses.

Windows DNS also works at the same time:
Resolve-DnsName google.com -Type A
Resolve-DnsName mcp.context7.com -Type A

Both return valid responses.

WSL journal repeatedly contains errors such as:
WSL (108) ERROR: Exception thrown by void DnsServer::HandleNewTcpData(TcpConnectionContext *) in DnsServer.cpp:223:
recv(...) failed with errno=104 (Connection reset by peer)

and sometimes:

WSL (108) ERROR: CheckConnection: getaddrinfo() failed: -5

A networking diagnostic capture was collected while the failure was active using:

.\collect-wsl-logs.ps1 -LogProfile networking

The archive contains logs.etl and wfpdiag.cab.

### Expected Behavior

The WSL DNS tunneling endpoint at 10.255.255.254 should remain available for the lifetime of the WSL instance.

Network adapter or VPN state changes should not leave /etc/resolv.conf pointing to a DNS tunneling endpoint that is no longer accepting queries.

### Actual Behavior

After WSL has been running for some time, the DNS tunneling endpoint at 10.255.255.254:53 stops accepting connections.

At that point:

/etc/resolv.conf still points to 10.255.255.254
DNS queries to 10.255.255.254:53 return connection refused
WSL itself remains running
direct IP networking still works
direct DNS to external/LAN/VPN resolvers still works
Windows DNS still works
applications inside WSL fail with EAI_AGAIN or ETIMEOUT

The issue reproduces on both WSL 2.7.14 and WSL 2.9.11.

### Diagnostic Logs

[WslLogs-2026-09-13_15-00-48.tar.gz](https://github.com/user-attachments/files/32160339/WslLogs-2026-09-13_15-00-48.tar.gz)

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the networking diagnostic archive from collect-wsl-logs.ps1 -LogProfile networking and the DnsServer.cpp:223 error cited in the WSL journal. Reproduce or correlate the intermittent failure with mirrored networking, DNS tunneling, and adapter or VPN changes. Done means the 10.255.255.254:53 endpoint remains available and /etc/resolv.conf continues to provide working DNS.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp
Domain
networking, operating-systems
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
38/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.