Name resolution fails with VPN & dnsTunneling

[shigenobuokamoto]

Windows Version

Windows11 22H2 22621.2359

WSL Version

2.0.0

Are you using WSL 1 or WSL 2?

• WSL 2
• WSL 1

Kernel Version

5.15.123.1

Distro Version

Ubuntu 22.04

Other Software

No response

Repro Steps

conditions

• VPN connected
  • route to the DNS server is included in the tunnel route
    • there are narrow routes such as link local, which do not actually go through the VPN
• dnsTunneling=true

[experimental]
networkingMode=mirrored
dnsTunneling=true

$ host host.domain 192.168.1.1
Using domain server:
Name: 192.168.1.1
Address: 192.168.1.1#53
Aliases:

host.domain has address 10.1.1.1

access the DNS server directly, can receive a response.

but

$ host host.domain
;; communications error to 127.0.0.42#53: timed out
;; communications error to 127.0.0.42#53: timed out
;; no servers could be reached

inquiry to 127.0.0.42 times out.
such as those that return NXDOMAIN wait for a timeout and take a long time to respond.
no problem if VPN is disconnected.

Expected Behavior

• names can be resolved via dnsTunnelring

$ host host.domain
Using domain server:
Name: 127.0.0.42
Address: 127.0.0.42#53
Aliases:

host.domain has address 10.1.1.1

Actual Behavior

• can not refer to DNS

$ host host.domain
;; communications error to 127.0.0.42#53: timed out
;; communications error to 127.0.0.42#53: timed out
;; no servers could be reached

Diagnostic Logs

No response

[keith-horton]

Mirroring and DNS Tunneling are not yet enabled on that version of Windows (22H2). There should be an OS update in the coming weeks to enable that support.

Currently, these new features are only enabled on Windows Insiders Canary builds.

Thanks!

[shigenobuokamoto]

Please note this feature is currently only available to Windows Insiders canary and Release Preview Channel with the latest Windows 11, version 22H2 update.

it seems to be enabled in Release Preview.
and dnsTunneling works fine without VPN .

[CatalinFetoiu]

/logs

[shigenobuokamoto]

here you are.
WslLogs-2023-09-27_08-58-53.zip

[CatalinFetoiu]

@shigenobuokamoto it seems many logs are missing

can you please run "wsl --shutdown"
then start the log collection script
then start WSL and repro the issue
then stop the log collection script

[shigenobuokamoto]

Is this okay?
WslLogs-2023-09-27_10-57-41.zip

[CatalinFetoiu]

@shigenobuokamoto thanks for the quick response, those traces were good

we need some additional traces. Can you please do the following?

run "wsl --shutdown"
in admin cmd, run "Netsh trace start scenario=InternetClient_dbg tracefile=nettrace.etl capture=yes"
start WSL and repro the issue
run "netsh trace stop"
collect "nettrace.etl" and attach it to this issue

[shigenobuokamoto]

@CatalinFetoiu
i appreciate your support.
nettrace.zip

[CatalinFetoiu]

@shigenobuokamoto thanks. for the names that you try to resolve from WSL, does it work to to resolve them from Windows?

Can you try running nslookup <name you want to resolve from WSL" in an admin powershell window?

from the logs, we see that Windows receives the DNS request from Linux, but when Windows tries to resolve it on behalf of Linux, it fails.

[shigenobuokamoto]

@CatalinFetoiu
yes, it was successful from widnows.

i think....

DNS server when disconnected VPN: 192.168.101.1
DNS server when connected VPN: 192.168.1.1 (by the VPN setting)
default route to the VPN when connected VPN.

at this time, windows queries 192.168.1.1 and successfully, but is it possible that dnsTunneling queries 192.168.101.1 and fails?

[CatalinFetoiu]

@shigenobuokamoto
from the logs, we see that name “ntp.ubuntu.com” is resolved using DNS servers 192.168.1.1 and 192.168.101.1, and resolving using 192.168.1.1 works.

but name “setup.wsk” is resolved using DNS servers 10.22.0.54 and 10.3.0.252 and the requests to those DNS servers time out (likely the VPN drops the requests). "setup.wsk" is resolved using different DNS servers because of a Windows NRPT rule that forces those servers to be used when resolving names ending in ".wsk"

from an admin windows powershell, can you please run "nslookup ntp.ubuntu.com", then run "nslookup setup.wsk" and let us know if nslookup works?

if nslookup works, can you please do the following?

run "wsl --shutdown"
in admin cmd, run "Netsh trace start scenario=InternetClient_dbg tracefile=nettrace.etl capture=yes"
start WSL
in WSL, run "host ntp.ubuntu.com"
in WSL, run "host setup.wsk"
in Windows admin powershell, run "nslookup ntp.ubuntu.com"
in Windows admin powershell, run "nslookup setup.wsk"
run "netsh trace stop"
collect "nettrace.etl" and attach it to this issue

[shigenobuokamoto]

@CatalinFetoiu

i see, thank you very much.

from windows, nslookup works for both ntp.ubuntu.com and setup.wsk.
there is nettrace.etl
nettrace.zip

[CatalinFetoiu]

@shigenobuokamoto thanks

it seems nslookup is not using the DNS servers configured in NRPT policies

the issue is that DNS requests from WSL are using the DNS servers configured in the Windows NRPT policies, and the VPN appears to block those DNS servers.

to confirm, can you please do the following?

With the VPN disconnected (we expect nslookup commands below to work):

In admin powershell, run "Get-DnsClientNrptRule > nrpt_no_vpn.txt" and share nrpt_no_vpn.txt
In admin powershell, run "nslookup setup.wsk 10.22.0.54"
In admin powershell, run "nslookup setup.wsk 10.3.0.252"

With the VPN connected (we expect nslookup commands below to fail):
In admin powershell, run "Get-DnsClientNrptRule > nrpt_with_vpn.txt" and share nrpt_with_vpn.txt
In admin powershell, run "nslookup setup.wsk 10.22.0.54"
In admin powershell, run "nslookup setup.wsk 10.3.0.252"

[shigenobuokamoto]

@CatalinFetoiu
oh, i am terribly sorry.

i forgot that i had specified the DNS server in Add-DnsClientNrptRule.
furthermore, because the connected LAN was distributing the 10.0.0.0/8 route using DHCP, the route to the DNS server was lost.

i deleted 10.0.0.0/8 route and the problem went away.
also, resolved the issue by removing the nrpt rule.

i apologize for the trouble.
thank you for your support.

[CatalinFetoiu]

@shigenobuokamoto good to hear that the problem was resolved

I will close the issue. Let us know if you run into any other problems