DNS resolving doesn't work for local resources when connected to VPN

[legigor]

A brief description

Can't get connected to the servers using the host names in the *.mydomain.local domain when machine is connected to VPN. When using the IP addresses everything works fine. When changing order of DNS servers in /etc/resolv.conf it works fine as well.

Expected results

I'm expecting I can connect to remote servers using the host names like server1.mydomain.local or just server1. I.e. ping server1.mydomain.local should send the pings to the server.

Actual results (with terminal output if applicable)

$ ping myserver1.mydomain.local
ping: unknown host myserver1.mydomain.local

Your Windows build number

Version 1703 (OS Build 15063.13)

Steps / All commands required to reproduce the error from a brand new installation

1. Open bash and try to ping something

$ ping myserver1.mydomain.local
ping: unknown host myserver1.mydomain.local

2. Everything works in cmd

$ cmd /c ping myserver1.mydomain.local

Pinging myserver1.mydomain.local [192.168.61.26] with 32 bytes of data:
Reply from 192.168.61.26: bytes=32 time=76ms TTL=61
Reply from 192.168.61.26: bytes=32 time=91ms TTL=61
Reply from 192.168.61.26: bytes=32 time=72ms TTL=61
Reply from 192.168.61.26: bytes=32 time=76ms TTL=61

Ping statistics for 192.168.61.26:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 72ms, Maximum = 91ms, Average = 78ms

3. Everything work in BASH when using the IP Address

$ bash -c 'ping 192.168.61.26'
PING 192.168.61.26 (192.168.61.26) 56(84) bytes of data.
64 bytes from 192.168.61.26: icmp_seq=1 ttl=61 time=72.1 ms
64 bytes from 192.168.61.26: icmp_seq=2 ttl=61 time=76.8 ms
64 bytes from 192.168.61.26: icmp_seq=3 ttl=61 time=74.7 ms
64 bytes from 192.168.61.26: icmp_seq=4 ttl=61 time=80.4 ms
64 bytes from 192.168.61.26: icmp_seq=5 ttl=61 time=74.2 ms
^C
--- 192.168.61.26 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4003ms
rtt min/avg/max/mdev = 72.138/75.675/80.431/2.806 ms

4. Autogenerated /etc/resolv.conf looks like this

# This file was automatically generated by WSL. To stop automatic generation of this file, remove this line.
nameserver 192.168.1.1
nameserver 10.61.1.61
nameserver 192.168.101.101
search mydomain.local

where the first line is my local router's IP address and next 2 addresses are ones propagated from VPN
5. Disable the local DNS like this:

# nameserver 192.168.1.1
nameserver 10.61.1.61
nameserver 192.168.101.101
search mydomain.local

6. Try to ping the server again and make sure it works!

igor@TARDIS:~$ ping server1.mydomain.local
PING server1.mydomain.local (192.168.61.26) 56(84) bytes of data.
64 bytes from server1.mydomain.local (192.168.61.26): icmp_seq=1 ttl=61 time=72.6 ms
64 bytes from server1.mydomain.local (192.168.61.26): icmp_seq=2 ttl=61 time=71.8 ms
64 bytes from server1.mydomain.local (192.168.61.26): icmp_seq=3 ttl=61 time=73.4 ms
64 bytes from server1.mydomain.local (192.168.61.26): icmp_seq=4 ttl=61 time=88.4 ms
64 bytes from server1.mydomain.local (192.168.61.26): icmp_seq=5 ttl=61 time=73.6 ms

Required packages and commands to install

Just default Bash installation. Nothing special.

[legigor]

The problem I see now is that on the Windows host the default DNS server is one from VPN (10.61.1.61).

This is what I see then I run nslookup on windows:

c:\>nslookup
Default Server:  dc-az61.mydomain.local
Address:  10.61.1.61

> google.com
Server:  dc-az61.mydomain.local
Address:  10.61.1.61

Non-authoritative answer:
Name:    google.com
Addresses:  2a00:1450:4009:806::200e
          216.58.212.78

> server1.mydomain.local
Server:  dc-az61.mydomain.local
Address:  10.61.1.61

Name:    server1.mydomain.local
Address:  192.168.61.26

>

This is what I see when I run nslookup in Bash

nslookup
> google.com
Server:         192.168.1.1
Address:        192.168.1.1#53

Non-authoritative answer:
Name:   google.com
Address: 216.58.209.46
> server1.mydomain.local
Server:         192.168.1.1
Address:        192.168.1.1#53

** server can't find server1.mydomain.local: NXDOMAIN
>

[aseering]

For what it's worth, I frequently see similar problems with VPNs on native Ubuntu... It's possible to get this right on Linux, but it's not simple.

[legigor]

@aseering you are right. It's possible to fix it on Linux with a kind of local proxying DNS.
But as I can see here it's just enough to use in Linux same 'default' DNS server as Windows uses (see my nslookup probes). Or just keep the order of DNS records when propagating from Windows to Linux

[valeryan]

The dns resolution is a little weird in WSL. I tried for a while to get dnsmasq to work and get windows to actually use wsl>dnsmasq as a dns server for my windows system so that I could proxy wild card domains like *.dev but I can never seem to get windows to be able to reach dnsmasq get dns resolution to work. It definitely seems to me that how dns works between windows and wsl may have some weird issues.

[sunilmut]

If you are connected to a VPN and lose connectivity within bash, please try the workaround posted here. It should work for Creators Update and above. Post Fall Creators Update, we will be looking at a better support for other VPN solutions.

Thanks to @bradley101, who first pointed out the workaround. Also, marking this duplicate of #1350

[macmiranda]

why can't wsl (or bash.exe for that matter) generate resolv.conf in the same order as they appear for Windows apps?

[legigor]

@macmiranda I think the problem is to keep it up to date when it changes in Windows when WLS session is already launched

[goyzhang]

I don't think that workaround is available for this issue. I had the same issue using DirectAccess. The WSL just cannot resolve for remote resources at the VPN endpoint. My temporary solution is to look up IP in windows and then hack the WSL host.

[sgarcia-dev]

@sunilmut , the workaround doesn't work for everyone. Me included, any chance this can be prioritized given the issue has been open for +2 years now?

[moonrockfamily]

https://gist.github.com/coltenkrauter/608cfe02319ce60facd76373249b8ca6#gistcomment-3505963