Why does WSL lose the work hostname when the VPN connects?

Windows resolves the internal host without complaint, and the same name fails inside WSL the moment the tunnel comes up. The usual repair is to write a public resolver into the distribution, which restores ordinary browsing and makes the work hostname impossible to resolve. That trades one failure for another, and it hides the layer that actually broke. Before adding or removing any resolver line, work out which of the three layers is failing.

Rule out a routing failure first

Query the identical fully qualified name on both sides, not two names that look alike. A Windows success and a WSL failure for the same string is the signature of two resolution paths, and little else produces that pattern as cleanly. If WSL also cannot reach the service at its known numeric address, a routing or filtering problem is present as well. In that case DNS work will not reveal it, and the afternoon goes to the wrong layer.

Three symptoms cover most of these cases, and each one points somewhere different. Read the row that matches before opening a configuration file:

The middle row is the one people misread, because the change that broke it was made weeks earlier and looked successful at the time. The third row is the one people misdiagnose, because a name that resolves feels like proof that the network is healthy. Both rows send you to a different section below.

DNS tunneling has a version floor

Microsoft documents a WSL networking mode that tunnels DNS requests to the Windows resolver across a virtualization channel. On supported Windows 11 builds it is enabled by default, which is why two machines on the same corporate network behave differently. The build number is the variable, not the corporate policy.

The WSL networking guide describes that mode and the versions that support it. The feature matters because corporate DNS policy usually lives in the Windows resolver, and a distribution that inherits the Windows path inherits the policy with it. A distribution querying a public resolver has no route to a private name, however tidy its own configuration looks. That mechanism explains the whole symptom, and it explains why the public-resolver workaround fails.

Read the build before editing anything. A setting copied from a newer installation is not evidence that an older one implements it. Record the build next to the change, because the difference between two machines is nearly always a version rather than a policy.

Old overrides outlive the problem they solved

Older recipes disabled generated resolver files, hard-coded a nameserver, or locked the file with an immutable attribute. Those changes stay in place long after the connectivity issue that prompted them disappeared, and they are usually why a newer setting appears to do nothing. They also survive a distribution reinstall in the form of a shell profile that rewrites the file at every login. That last one is the hardest to find, because it is invisible from the file everyone inspects.

Look for a hand-written resolver file, an immutable attribute on it, and a startup script that rewrites it. Check the immutable flag before editing, because a write to a locked file fails in a way that reads like a permissions problem. Check the shell profile afterwards, because a script there restores the old content within seconds of your fix.

Removing an override has consequences, so record what you removed and why. A distribution that genuinely needs a static resolver for another purpose will break when the generated file returns.

Two files, two different roles

The two configuration files live in different places and control different things, and confusing them produces edits applied to the wrong layer. The Windows-side file sets properties of the virtual machine, while the distribution-side file sets how that distribution builds its own resolver configuration. Neither one overrides the other, which is why both have to agree.

For an installation that supports the feature, the Windows-side fragment is short. It is the whole change on that side:

[wsl2]
dnsTunneling=true

That fragment belongs in the Windows user profile and applies to the virtual machine rather than to a single distribution. Tunneling also requires that the distribution has not disabled resolver generation, so the distribution-side file has to leave that behaviour alone. Change one without the other and the mode silently does nothing, which is the most common way this repair gets reported as broken. Check both files in the same session, because two edits made weeks apart are two edits nobody can attribute.

Restart, then query from both sides

These settings are read when the environment starts, so a new shell inside a running distribution will not reload them. Shut the environment down instead of restarting the shell, and save any running work first because every distribution stops with it. That omission alone explains most reports of a change having no effect.

Then ask the same question from both sides. The output also shows which resolver the distribution actually ended up with:

wsl.exe --shutdown
wsl.exe -e sh -c 'cat /etc/resolv.conf'
wsl.exe -e sh -c 'getent hosts files.corp.example'
wsl.exe -e powershell -Command 'Resolve-DnsName files.corp.example'

The first command ends the environment, the second shows which resolver the distribution now uses, and the last two put the same question to each side. Compare the answers rather than the status of the setting. A query that still fails after a clean restart with both files correct points at the corporate resolver policy, and that conversation has a different owner.