search

microsoft / WSL

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

DNS resolution for Internal Sites doesn't work when using Proton VPN. #11829

Open AmazingMrX opened 2 months ago

AmazingMrX commented 2 months ago

Windows Version

Microsoft Windows [Version 10.0.22631.3880]

WSL Version

2.3.11.0

Are you using WSL 1 or WSL 2?

Kernel Version

6.6.36.3-1

Distro Version

Ubuntu 22.04

Other Software

ProtonVPN v3.2.12

Repro Steps

  1. Configure WSL2 for Mirrored Networking and DNS Tunneling in WSL Settings App.
  2. Install ProtonVPN software.
  3. Connect to a server.
  4. Open a WSL2 distro terminal.
  5. Run nslookup with a site on your internal network. E.g.: router.local
  6. Ping a site on your internal network. E.g.: router.local
  7. Run nslookup with a site on the internet. E.g.: www.google.com
  8. Ping a site on the internet. E.g.: www.google.com
  9. Disconnect from your ProtonVPN.
  10. Repeat steps 5 through 8.

Expected Behavior

nslookup router.local should return an output similar to what it does for www.google.com for router.local, with at least one Name and Address pair:

Server: 10.255.255.254 Address: 10.255.255.254#53

Non-authoritative answer: Name: google.com Address: 142.251.116.138 Name: google.com Address: 142.251.116.101 Name: google.com Address: 142.251.116.102 Name: google.com Address: 142.251.116.113 Name: google.com Address: 142.251.116.139 Name: google.com Address: 142.251.116.100 Name: google.com Address: 2607:f8b0:4023:1004::8a Name: google.com Address: 2607:f8b0:4023:1004::66 Name: google.com Address: 2607:f8b0:4023:1004::71 Name: google.com Address: 2607:f8b0:4023:1004::65

ping -c 5 router.local should return an output similar to what it does for www.google.com for router.local, with at least one successful ping attempt even if all packets are lost:

PING www.google.com (173.194.219.106) 56(84) bytes of data. 64 bytes from ya-in-f106.1e100.net (173.194.219.106): icmp_seq=1 ttl=59 time=35.5 ms 64 bytes from ya-in-f106.1e100.net (173.194.219.106): icmp_seq=2 ttl=59 time=37.0 ms 64 bytes from ya-in-f106.1e100.net (173.194.219.106): icmp_seq=4 ttl=59 time=37.0 ms 64 bytes from ya-in-f106.1e100.net (173.194.219.106): icmp_seq=5 ttl=59 time=43.4 ms

--- www.google.com ping statistics --- 5 packets transmitted, 4 received, 20% packet loss, time 4029ms rtt min/avg/max/mdev = 35.545/38.249/43.435/3.052 ms

Actual Behavior

nslookup router.local returns the following output for router.local when the VPN connection is enabled:

Server: 10.255.255.254 Address: 10.255.255.254#53

** server can't find router.local: NXDOMAIN

ping -c 5 router.local returns the following output for router.local when the VPN connection is enabled:

ping: router.local: Name or service not known

These commands provide expected output only when the VPN is disconnected or when a site from the internet is chosen.

Diagnostic Logs

WslLogs-2024-07-23_22-35-56.zip WslNetworkingLogs-2024-07-23_22-35-25.zip

github-actions[bot] commented 2 months ago

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!

Closed similar issues:

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

Diagnostic information 
Multiple log files found, using: https://github.com/user-attachments/files/16357003/WslLogs-2024-07-23_22-35-56.zip
.wslconfig found
Detected appx version: 2.3.11.0

CatalinFetoiu commented 2 months ago

@AmazingMrX thanks for reporting the issue

this might be a duplicate of https://github.com/microsoft/WSL/issues/11022

if you disconnect from the VPN, are you able to resolve names ending in ".local" ?

AmazingMrX commented 2 months ago

@AmazingMrX thanks for reporting the issue

this might be a duplicate of #11022

if you disconnect from the VPN, are you able to resolve names ending in ".local" ?

Yes a disconnected VPN resolves the host names successfully.

However, my configuration does not utilize mDNS. This is a local nameserver built into an AsusWRT Router. Also, the proposed dnsTunneling=false solution does not work in this case. I am only able to resolve some hosts in this configuration, not all names function under these conditions.

CatalinFetoiu commented 2 months ago

we have updated the docs to include details about how to resolve .local names in WSL. Please refer to https://learn.microsoft.com/en-us/windows/wsl/troubleshooting#resolve-local-names-in-wsl

let us know if you have any questions

AmazingMrX commented 2 months ago

we have updated the docs to include details about how to resolve .local names in WSL. Please refer to https://learn.microsoft.com/en-us/windows/wsl/troubleshooting#resolve-local-names-in-wsl

let us know if you have any questions

This information only applies to multicast DNS (mDNS) configurations. As was previously indicated, this network does not use multicast DNS. I have a single domain name server operating in a traditional unicast DNS configuration. To reiterate, there is an actual domain name server providing name resolution for these local IPs.

This is why name resolution works when the VPN is disabled.

The .local domain was arbitrarily selected for my use case as it's a common choice for Local Networks. The mDNS protocol likely makes this selection for similar reasons.

To further clarify: This name resolution issue is unique to WSL2 and only occurs when Proton VPN is connected. During this time, Command Prompt and Powershell terminals (on the same Windows Machine as the WSL2 instance) can and will correctly resolve these names. When the VPN connection is disabled, as described in the original post (above), WSL2 regains the ability to resolve these names as well.

Upgrading to WSL 2.3.17.0 provides no change in the originally described behavior. The 10 Repro Steps still work as described.

CatalinFetoiu commented 1 month ago

@AmazingMrX thanks for following up and clarifying the deployment you are using

could you please collect separate WslNetworkingLogs for both the working and non-working cases?

With Proton VPN connected: start networking logs in Linux, run ping router.local confirm ping does not work stop networking logs

With Proton VPN disconnected: start networking logs in Linux, run ping router.local confirm ping works stop networking logs

thanks!

AmazingMrX commented 1 month ago

Is there some problem with the combined log provided? The provided steps were followed in order.

CatalinFetoiu commented 1 month ago

it looks like the WslNetworkingLogs zip you attached in the initial comment is missing the "logs.etl" file, which is needed to investigate

could you please try collecting networking logs again and double check if the zip has a "logs.etl" inside it?

thanks