Skip to content

Instantly share code, notes, and snippets.

@mikegerber

mikegerber/Fix WSL2 vs VPN networking.md

Last active September 15, 2024 07:23
Show Gist options
  • Save mikegerber/91fcea262028e09b2fd0969193c6c260 to your computer and use it in GitHub Desktop.
Save mikegerber/91fcea262028e09b2fd0969193c6c260 to your computer and use it in GitHub Desktop.
Download ZIP
Fix WSL2 vs VPN networking
Raw
Fix WSL2 vs VPN networking.md

The problem

WSL2 uses a random network from the 172.16.0.0/12 RFC1918 private IP address block. And our VPN uses that address block, too, with a route metric of 1 (= most preferred.)

This breaks networking for WSL2. Meh!

The solution

While messing around with the interface/route metric of the VPN network may work around the problem, it also reduces the priority of the VPN. We do not really want this. Additionally, changing the interface metric does not seem to be permanent, so it requires more work when it breaks again.

A better solution is configuring WSL2 to not use a network in the VPN network space at all. However, in our case, the VPN routed all the available RFC1918 address space... (Isn't IPv4 great!)

But we can use the link-local address space from 169.254.0.0/16 and so have at least a semi-elegant and permanent solution!

  1. These PowerShell commands set the NAT network used by WSL2 to a subnet of 169.254.0.0/16 - I chose 169.254.214.0/24 here - and need to be run as a Windows administrator:
Set-ItemProperty `
  -Path Registry::HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Lxss `
  -Name NatNetwork `
  -Value "169.254.214.0/24"
Set-ItemProperty `
  -Path Registry::HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Lxss `
  -Name NatGatewayIpAddress `
  -Value "169.254.214.1"

  1. Reboot (I couldn't be bothered to check if restarting some service suffices.)

  2. After the reboot, you a. should get an error message the first time you start your WSL2 (because it can't use the IP it used before the change) and b. networking should work, now with shiny new 169.254.x.y addresses.

Notes

  • The only thing that makes this "semi-elegant" is that I would prefer using a network from RFC1918.
  • To check the current values, run Get-Item -Path Registry::HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Lxss.
  • I've also seen DNS break a lot and would recommend checking IPv4 connectivity through the WSL2 NAT without DNS first (e.g. ping -n 8.8.8.8 or similar), then fixing DNS, if needed. My WSL just auto-configured 169.254.x.1 in /etc/resolv.conf, and that worked here. So WSL2 seems to have a built-in DNS proxy, but I couldn't find any documentation on it.
  • Our VPN set up does not route all traffic through it, so this might be not be a complete solution in that case. It would be interesting to see how a Cisco AnyConnect VPN with default route to the VPN sets this default route - what metric does the route have?
@lawndoc
Copy link

lawndoc commented Jun 14, 2024

This has been a pain point at my job for a couple of years now, and this is by far the best solution I have found. Thank you for sharing this!

@mathurk29
Copy link

mathurk29 commented Jun 18, 2024 •
edited
Loading

it broke my normal internet connectivity of wsl - how to revert :(

@mikegerber
Copy link
Author

mikegerber commented Jul 9, 2024 •
edited
Loading

it broke my normal internet connectivity of wsl - how to revert :(

Weird, maybe check if there's networks overlapping. Or maybe it's DNS. Hard to say without more info.

To revert, just remove the mentioned registry keys.

@manwithaplandy
Copy link

Did a bunch of digging and didn't think this was my issue. Ran out of other ideas and gave it a shot and it looks like it's working great now. Thank you for this, hopefully Microsoft gets around to fixing this issue.

@wilbfcpl
Copy link

wilbfcpl commented Jul 30, 2024 •
edited
Loading

Thanks for this, MikeGerber

@lowsound42
Copy link

Thank you so much for this gist! This whole thing has been a ridiculous saga for us at work and not that many people online are talking about this specific solution.

@mikegerber
Copy link
Author

mikegerber commented Aug 20, 2024 •
edited
Loading 

* How do I determine the route metric for my employer's Absolute/Netmotion VPN? It also uses a 172.  RFC1918 private IP address block.

Check ROUTE PRINT -4. But the point of this gist that you should use a network for WSL that is not covered by your VPN to avoid the issues (and the route metrics become irrelevant because you have a clean solution with no overlapping networks).

* Does this solution remain an alternative to the new WSL2 Mirrored Mode Networking?
  https://learn.microsoft.com/en-us/windows/wsl/networking#mirrored-mode-networking

I haven't worked with that yet.

@wilbfcpl
Copy link

wilbfcpl commented Aug 21, 2024 via email

@manwithaplandy
Copy link

Thanks for this, MikeGerber

* How do I determine the route metric for my employer's Absolute/Netmotion VPN? It also uses a 172.  RFC1918 private IP address block.

* Does this solution remain an alternative to the new WSL2 Mirrored Mode Networking?
  https://learn.microsoft.com/en-us/windows/wsl/networking#mirrored-mode-networking

I have found that Mirrored Mode networking is the best solution for this issue. It makes the network on WSL work exactly like it does on a regular cmd prompt. No need to mess around with routing, and persists on restarts.

@mikegerber
Copy link
Author

Thanks for your reply. When using the VPN remotely, I need for WSL applications to communicate with servers only available via the VPN.

Yeah, that works, I can access everything. WSL2 does NAT ("masquerading") and the WSL VM appears as the host machine to the network.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment