Ubuntu App for Windows sporadically gets a “Temporary Failure in Name Resolution” error

I have the Ubuntu app for Windows (downloaded from the Microsoft store) and I keep getting a temporary failure in name resolution error.

ping: google.com: Temporary failure in name resolution

This happens both when I am connected to a VPN and when I am not connected to a VPN. However, if I run the command:

echo "nameserver 8.8.8.8" | sudo tee /etc/resolv.conf

Then it solves the issue when not connected to the VPN. However, even after running the command it still does not work if I am connected to the VPN.

I need to connect to a remote server through ssh which requires me to be on the VPN to gain access. Therefore, I need to determine why when connected to the VPN name resolution does not occur. It would also be preferred to solve the issue permanently even when not connected to the VPN so I do not have to run the above command each time.

This is what the /etc/resolv.conf file looks like (before running the above command):

# This file was automatically generated by WSL. To stop automatic generation of this file, add the following entry to /etc/wsl.conf:
# [network]
# generateResolvConf = false
nameserver 172.22.96.1

I appreciate any ideas!

2 Answers

I need to connect to a remote server through ssh which requires me to be on the VPN to gain access.

For that particular use-case, at least, the solution should (hopefully) be fairly straightforward -- Create a WSL1 instance instead of WSL2.

WSL2's network is virtualized and NAT'd behind (inside) the Windows machine. Normally, when WSL2 starts up, the /init process creates a resolv.conf that points to an IP address on the Windows machine, and a process on the Windows machine acts as a proxy resolver.

While I don't know for sure why yours is failing when not connected to the VPN, I do know that WSL2 has significant issues when connected through many types of VPNs. Some VPNs (especially corporate) will block all local traffic when connected. For instance, if you have another computer or printer on your local network, you probably aren't able to access it either when connected to the VPN. And since WSL2 appears to Windows to be "another computer" (of sorts), it blocks access to it as well. For this reason, the resolver isn't going to work when connected to many VPNs.

WSL1, on the other hand, doesn't have this problem. It shares (a "bridge" of sorts) the network interface with Windows.

And since ssh runs just fine under WSL1, that's probably your best option.

You can either convert or copy the existing WSL2 distribution to WSL1. Either way, start with a backup. From PowerShell:

wsl -l -v
# Confirm the distribution name and
# adjust the following commands as needed
wsl --export <distro> ubuntu_backup.tar

To convert:

wsl --set-version <distro> 1

To copy:

mkdir <location>
wsl --import Ubuntu_WSL1 <location> <path_to>/ubuntu.tar --version 1

Other possibilities

I haven't tested this myself, but if you are on Windows 11 Professional (or Education) or higher, there is a Preview version of WSL available in the Microsoft Store. This version currently has a new feature that allows you to create a bridged Hyper-V network switch and use it in WSL2.

This may allow you to use WSL2 while connected to the VPN.

See this Reddit post for details.

But really, I'd go with WSL1 in this case. I keep both WSL2 and WSL1 instances around for exactly this reason (and some others where WSL1 still has advantages over WSL2).

Using WSL1 as @NotTheDr01ds suggests is probably the simplest if that's an option for you.

Your issue might be due to WSL2's network implementation causing its traffic to look like local network rather than local host to the VPN adapter:

[...] We want all the traffic to go through the VPN when the VPN is on. The only problem is.. the VPN will only forward traffic from the LOCAL COMPUTER, and the traffic coming from WSL 2 IS NOT considered your local computer. The VPN driver considers it as local network instead. Go figure!

So this is our problem in a nutshell: every time you VPN connects, it adds a high priority rule to the routing table for WSL 2. This route will route all WSL 2 traffic directly to the virtual adapter of the VPN. The adapter happily accepts and then drops it all into a black hole, effectively killing all network traffic.

The solution ranges from quite involved to very involved (I haven't solved it myself yet).

The starting point is:

Great! What’s the fix? Easy. We drop the priority route the VPN adds.

Once dropped, the routing will fall back on the other two lower-priority rules and route all the WSL 2 traffic to the Windows host. Once there, it will flow through the VPN as usual.

Detailed steps on how the author achieved that. Note they have 3 articles on the issue.