Open jpsenior opened 4 years ago
I use strategy here, in this comment, to create the blacklist of subnets that WSL2 will not use. It is ugly, but it works.
My strategy is to play ipconfig roulette. If it hits on a forbidden subnet, REBOOT.
Having this issue as well.
After spending enough time banging my head against the wall with debugging why WSL can't ping a DNS server after connecting to VPN via Cisco AnyConnect.
I noticed that Docker WSL vs Ubuntu WSL used different subnet configurations?
Would love a solution to this that doesn't require administrator access for the developers like myself who work in a corporate environment.
Since I just got bumped on the email about this issue, I'd like to point everyone to the fact that vSwitch can now be used to directly connect WSL2 distro, officially, no hacks, using networkingMode=bridged
option. You do need W11 Pro, which shouldn't be an issue. I've compiled a nice big guide / tutorial couple of weeks ago as a comment in the main networking thread:
https://github.com/microsoft/WSL/issues/4150#issuecomment-1288152162
Likewise, I've added it to my GitHub, with some more polish, comments and tweaks added over time: https://github.com/luxzg/WSL2-fixes
I went through W10 to W11 upgrade (linked instructions for those with "unsupported" hardware), latest WSL2, creation of vSwitch, configuration of the network bridge, and as a bonus systemd configuration on Ubuntu with complete systemd based networking setup (networkd, resolved). I even threw in tests with web server and GUI apps. It should be doable for both newbies and experienced users alike. Btw, I can now tear down and setup new WSL2 instance with proper networking and full apt upgrades and all in just a few minutes, easy-peasy. I've even added two shorter guides / references for those that (re)install distros all the time - all in that same GitHub repo linked above.
Hope this information helps someone!
@luxzg
The problem with the bridged solution is that if you connect to your company VPN in WSL2 then your windows host doesn't have access to the company network. Same issue, but other way around, if you connect to the VPN from the Windows side.
The easy fix is to have an option subnet option in .wslconfig (or whatever that file is). But that requires dev work an Microsoft seem to be ignoring this issue.
The main draw for WSL2, for me atleast, is the great integration with the host windows resources. GPU acceleration, CPU allocation, memory ballooning, etc.. Also the really nice auto shutdown feature when WSL is inactive. This is really hard to reproduce even with tools like Vagrant. Things like GPU acceleration and Cuda don't work in Hyper-V at all without WSL2.
@nlvw Agree, both with the VPN issues and the benefits of better integration. There's an issue open to get MS to allow use of Internal/Private switching, in addition to bridging. There's also one to allow multiple adapters. If we could get those, then we could keep all benefits without major issues. Likewise, having both host OS and WSL instance connect to VPN is still a possibility even with current situation, but I admit it's just a step away from becoming a burden in itself.
I guess we will never have it all.
Btw, once I stopped "playing" with WSL stuff that I never use for real (GUI apps and the likes), I was back to classic VMs in a matter of days. Sure, everyone has their own needs, I won't (and can't) judge. Luckily I don't need CUDA in Linux :-)
If anyone would need help with bridging, I'll keep following these threads, as for MS, I'll keep fingers crossed that new features keep on coming!
@luxzg I did end up putting together a decent workaround based on others recommendations. wsl-vpnkit with schedule tasks to start/stop the wsl-vpnkit distro when Cisco AnyConnect connects/disconnects. Since all running distros share the same kernel and networking this should work with things like Rancher/Docker Desktop aswell.
I put together a powershell script that installs wsl-vpnkit and the scheduled tasks.
https://gist.github.com/nlvw/5a563242651c0aaaeb078c860d70a0a5
The only thing this workaround doesn't solve is if your WSL network conflicts with a 172 network elsewhere on your LAN (because multi-subnet routed networks are a thing Microsoft).
Hi folks, we have put out a new update that aims to address networking issues in WSL. In your .wslconfig
file you can set experimental.networkingMode=mirrored
, as well as some other key settings that should improve your network compatibility, and add support for IPv6 and a consistent IP address! Please try them out and let us know what you think.
More info on this release and the changes can be found here in the blog post.
Please note: You need to be on a Windows Insiders version to use the new networking settings (Only canary or release preview channels). If you see the "These are not supported" messages it means that your current Windows version doesn't have support, and you will need to upgrade. These features will eventually be coming to Windows 11 22H2.
In your .wslconfig file you can set
experimental.networkingMode=mirrored
These features will eventually be coming to Windows 11 22H2.
Hey @craigloewen-msft, thank you for putting out this change, this will really help. Is there any chance of this being backported to Windows 10? Updating WSL is in my own hands (e.g. wsl --update; wsl --update --pre-release
), but as for switching to Windows 11, that's in the control of my employer, so I don't know how long it'll be until I'm able to use this feature (which will really help me in my day-to-day).
Currently these features are Windows 11 only, and we aren't considering a backport. We are looking at alternative ways that we could help get these features to Windows 10 users, and also into helping Enterprises upgrade to Win11.
Other options with recent versions :
WSLAttachSwitch :
networkingMode=mirrored
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Lxss\NatGatewayIpAddress Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Lxss\NatNetwork Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Lxss
Please use the following bug reporting template to help produce issues which are actionable and reproducible, including all command-line steps necessary to induce the failure condition. Please fill out all the fields! Issues with missing or incomplete issue templates will be closed.
If you have a feature request, please post to the UserVoice.
If this is a console issue (a problem with layout, rendering, colors, etc.), please post to the console issue tracker.
Important: Do not open GitHub issues for Windows crashes (BSODs) or security issues. Please direct all Windows crashes and security issues to secure@microsoft.com. Ideally, please configure your machine to capture minidumps, repro the issue, and send the minidump from "C:\Windows\minidump\".
Please fill out the below information:
Your Windows build number: Microsoft Windows [Version 10.0.18965.1005]
What you're doing and what's happening:
Upon reboot of Windows/WSL container, the allocated hyperv switch/NAT gateway IP addresses are constantly changing, particularly between subnets (multiple /16s randomly between reboots)
What's wrong / what should be happening instead: Because I can a) not control the subnet and b) it is not deterministic, I cannot script against WSL Allocated IP addresses from windows host, and it will occasionally overlap with internal network routes in my corporate network (eg, 172.20.0.0/16 represents a specific part of my internal network, and now it is unreachable from within WSL).
This (subnet overlap) makes WSL unusable, and the only 'fix' i have is reboot windows a few times until I get 172.17.0.0/16 instead or something.
I did not see any way of controlling the subnet allocation at all from either Windows or WSL container itself. Ideally, I could configure static IP addresses, and have WSL never touch resolv.conf or network interfaces, and treat it as a normal virtual machine with normal IP networking set up as how I see fit. I am a networking professional, and the network stack for WSL/HyperV here seems invisible and uncontrollable with no configuration options, things happen in mysteriously undocumented ways.
See our contributing instructions for assistance.