mikegerber/Fix WSL2 vs VPN networking.md

## Fix WSL2 vs VPN networking.md

      
    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!

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"


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


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?