WSL Internet Fails on VPN: DNS or Routing?

Windows and WSL can follow different network paths and DNS behavior. First distinguish name resolution from routing and HTTPS trust. Replacing the DNS server blindly can break private company names even if public websites begin to work.

Record the environment

Capture Windows build, WSL version, distribution and networking mode. Record whether the failure affects public domains, private company domains or both.

Microsoft's WSL networking guide describes networking modes and DNS tunneling. Available behavior depends on the Windows and WSL versions. An upstream VPN/DNS report illustrates that a configuration label alone does not prove a working path.

Keep organization-managed VPN and firewall requirements in place during diagnosis.

Compare the same destination

Choose one harmless public endpoint and one permitted internal endpoint. Test name resolution from Windows and WSL, then test the intended HTTPS request.

Observation	Investigation
Name fails only in WSL	Resolver path or DNS policy
Name resolves, connection times out	Route, firewall or VPN tunnel
Connection reaches server, certificate fails	Trust store, hostname or interception
Public names work, private names fail	Split DNS and company resolver policy

Do not use a raw IP for HTTPS and interpret a certificate-name error as proof that TLS is broken. The hostname is part of certificate validation and often routing.

Check supported DNS behavior

Review the settings documented for your installed WSL release. Microsoft also documents DNS-tunneling considerations, including VPN policy interactions.

If a previous workaround manually replaced resolver files, document it before changing anything. Old workarounds can conflict with newer supported behavior.

Apply one change at a time and follow the documented restart requirement. Warn affected users before restarting a distribution containing active work.

Avoid attractive but misleading fixes

A public DNS server may resolve public sites while bypassing the resolver that knows internal names. Disabling certificate validation can hide a trust issue without fixing it. Disabling the firewall broadly removes evidence and protection together.

Instead, keep the exact failed hostname, resolved address, error category and comparison result. Those details give an administrator a much more useful report.

Confirm the actual workflow

Retest after reconnecting the VPN and after a normal WSL restart. Confirm both public and required private endpoints, not just a search homepage.

For local AI workflows, test model downloads separately from local inference. A working local model does not prove that the environment can reach a model registry or an external tool service.

Related troubleshooting

• Docker Cannot Reach an API on Your Laptop
• Check Whether Your Local AI Works Offline

This guide draws on the linked documentation. Examples are illustrative unless explicitly identified as measured results.