WSL2 lost DNS after the VPN connected? Two causes

Ping by address works inside the distribution, package installs and git fetches do not, and the failure appeared right after the tunnel came up. Only names stopped resolving, which points at DNS rather than at connectivity. Reinstalling packages is the most popular wrong first move here. WSL2 has two independent ways to produce exactly that symptom, and they need different repairs.

Why the distribution keeps its own resolver

The Windows DNS client is not used inside the distribution. WSL2 builds its own resolver file at start, pointing at a stub address that Windows publishes on the virtual switch for the utility VM.

That arrangement is stable across ordinary network changes because it is written once and reused. The arrangement stops being correct when a tunnel client rewrites the host adapter list after the utility VM has already started.

Nothing inside the distribution watches for the change, so the file keeps pointing at an address that may no longer be on the path. The next lookup then waits, times out, or gets an answer from a server that has never heard of the internal zone. From inside, the resolver simply stops answering, and every name fails at once.

Collect evidence on both sides first

Record what the distribution sees, then what Windows sees, before changing either. The two views together are what distinguish the failure modes.

Inside the distribution, print the resolver file, the routing table and one internal and one public lookup:

ip -4 route
cat /etc/resolv.conf
getent hosts intranet.corp.example
getent hosts example.com

On Windows, list the DNS servers per adapter and the IPv4 table with metrics. A VPN client commonly installs a route for the WSL2 subnet, and its metric decides whether that traffic leaves through the tunnel or stays local.

Get-NetAdapter | Get-DnsClientServerAddress
route print -4

Route metric or stale file

The first failure is the stale file. The resolver was written for the adapter state at startup, and the tunnel changed that state. Its stub address may now be unreachable, or it may name a server that knows nothing about the internal zone.

The second is a routing problem. When the VPN adds a route covering the WSL2 subnet with a metric lower than the host link route, packets addressed to the utility VM enter the tunnel. Then every WSL2 service times out, not only DNS.

The distinguishing test costs one line. If a numeric address such as a public resolver still answers with ping while names fail, the path is intact and DNS is the problem. That is the case where a resolver change is justified, and the case where it is not becomes obvious too. If the numeric test also fails, the utility VM has lost its route and no resolver file will fix that.

For the routing case, drop the automatic metric on the tunnel adapter and give it a number above the WSL2 link route:

Get-NetAdapter | Where-Object InterfaceDescription -Match VPN | Set-NetIPInterface -InterfaceMetric 5500
wsl.exe --shutdown

The shutdown matters. Changing the metric does not rewrite the running utility VM, so the distribution has to be rebuilt before the change is visible.

Take the file over, deliberately

If routing is correct and only internal names fail, the resolver is the fault and you can stop the generator. That is a deliberate change with a maintenance cost, not a workaround to apply casually.

Create /etc/wsl.conf inside the distribution with the network section that disables generation, then write the resolver file yourself, corporate server first and a public fallback second:

[network]
generateResolvConf = false

search corp.example
nameserver 10.88.4.53
nameserver 9.9.9.9

Order matters. A public resolver cannot answer an internal name, and the fallback exists only for internet lookups. Once the file is yours, nothing regenerates it, so a corporate resolver that moves becomes an outage you have to notice yourself.

Check names, then check packages

Verify one internal and one public name with the system resolver, then repeat the operation that failed. Package managers sometimes use a resolver of their own, which is why a working getent can coexist with a broken install.

If you automate the rewrite, make it idempotent: with no tunnel present, keep the file that already exists instead of writing an empty server list.

getent hosts intranet.corp.example
resolvectl status | head -20
getent hosts example.com

A working internal lookup and a working public lookup, from inside the distribution, is the result worth recording. A green VPN icon on the host proves neither.