After converting to WSL2 no longer able to route traffic to other VSwitches on the same host. #4288
Comments
|
i tried using bridged adaptor, instead of nat, but it appears to fail with the same issue. any news on how to work-around or fix? |
|
I am seeing the exact same issue today, after getting the 19008.1 build. Unable to ping or ssh through to other hyper-v machines on the same host. In my instance I used the builtin hyper-v "Default Switch" for my other hyperv guests. This worked for me on the previous flight build 18999. But now it seems to be broken. It works fine if I set the WSL version back to 0. Then I can access other hyperv guests just fine. Also ... the WSL2 can access other resources on my network and over the internet just fine. As in doing ping, curl and ssh requests. Problem is only to other machines on the same host. |
|
I just discovered this issue today. Running multiple Hyper-V VM's and not being able to connect in any way from wsl2 to any of them. Tried various ways of adding routes, changing switches around in hyper-v, bridged mode, static ip's. It'd be awfully nice to have either a workaround or a permanent fix. |
|
I've been experiencing this issue. I was playing about with things and noticed that i can ssh in from WSL2 if i go via Powershell. I've got
This isn't really a solution to anything other than just opening up an SSH session. I'd be interested if anyone knows of a way to route all traffic for an ip through this. Since connection is fine from the host is there a way to route traffic via the host ip? Some kind of proxy or ssh tunnel maybe? |
|
Bumping. Running minikube on Hyper-V, can't reach it from WSL, even with netsh portfwd. |
|
I don't know if something has changed but I've been able to get this working a bit now. I have an Ubuntu hyperv vm connected to an internal virtual switch I created and I can ssh to it from wsl2. I've set up the switch for NAT as I have virtualbox running on the hyperv vm and I am able to access the various nested vms through that as well. I can't get back to wsl2 from any of those things though. I thought it'd be neat to serve files from wsl2 to them via nfs but that is a non-starter. |
|
@very-random-man that is awesome. Can you tell us how you did this? Let's say WSL is 172.24.245.108/20 and the VM is 172.23.108.50/20. I'm assuming you set up the NAT on the switch of the VM. How did you write the rules? Thanks! |
|
Thanks. I'm wrapping it all up in a single-command deploy. I'll link the project on here when it's done. I'm using win vagrant to build the vm. I had hoped to keep it all in the WSL2 domain but hyper-v vms need to be built in an elevated powershell. Basically creating and assigning an internal switch on its own isn't enough and you need to make sure the networking config on the vm is in place. Any nested VMs also need to use the same hyper-v virtual switch. I'm hoping to get something out there in the next week or two. Will be looking for guinea pigs to test it out. ;-) |
|
I was able to work around this by attaching my Hyper-V server VM to the WSL network and adding a static IP with the following. IP Address: 172.24.128.10/20 (You could use anything on the 172.24.128.0/20 subnet, except (.1 of course)) Double check your WSL subnet by running an ipconfig in a windows CMD prompt. As always: YYMV |
Guinea pigs still waiting here... Thanks! |
This is broken now. I'm trying to figure out why. |
|
Any luck @jshmlr or @very-random-man? Tried upgrading yesterday and all my workflows are totally destroyed by WSL2 and this networking problem. |
|
Having this same issue here. Could only use the Internal Network switch to communicate with my host via networking, all other switches were failing. Ended up going back to WSLv1, its impossible to do network testing with this WSLv2 error. |
|
This is a must fix in order for many to use WSL2. Thank you for making rollback to WSL1 easy. |
|
I had a similar issue (Win10 2004 19041.329) - and noticed the After issuing I'm now able to access Hyper-V VMs via WSL2 tools (ping/ssh/etc). Strangely, undoing my change via PowerShell disabling of forwarding on the interface seems to then show as disabled via Could be related - hope it helps. |
|
Briljant, I've tested this on my machine (same Windows build number) and it works like a charm |
@ivan-section-io |
|
Thanks @ivan-section-io this also worked for me, running very smoothly now :) |
|
Does this look right? If so, is there anything else I should check/do because I still have no access from WSL2 to other VMs (multipass VMs that can only use the Default Switch)? Was I only supposed to enable these and the forwarding should work? Thanks! |
|
@AntonOfTheWoods I only have the 2 vSwitches: "WSL" and "Default". It looks like you've got another - "Wifi". If that is where your VMs are - it would make sense that you should enable forwarding for that adapter. I have not tried anything beyond the system installed vSwitches. I did read that "Default Switch" has some special properties (e.g. NAT?) - but I'm not sure how/if they would come into play in a simple routing scenario. For reference, my (simple) setup: |
|
@ivan-section-io , I have been using Linux for too long... It was McAfee Firewall blocking the connections. Thanks for your help! EDIT: Would a |
|
Actually this has a REALLY big hole in it for some users (like me). Hyper-V for some reason that I can't work out changes the IP ranges for both the Default and WSL virtual switches. That means I either have to add a big "allow everything" for 172.16.0.0/12 (and hope it doesn't switch to 192.168, which it used to previously but maybe not anymore) or somehow query to see what has been assigned and then reconfigure the firewall every boot. Wow, that's really annoying. |
|
@AntonOfTheWoods My first guess would be to stick it in a .ps1 script and create a task to run it on login with admin privileges, you can do this really easy with the Windows Task Scheduler. I have a PowerShell Script that runs on my personal laptop that way. Personally I am testing these commands right now to see if it fixes my issue: I am on Win10 2004 running a CodeReady Containers instance (Hyper-V) and my WSL2 instance is not able to connect to the VM. If it works I would then need to see if the settings persist across reboots, if not I will have to stick it in the Task Scheduler |
|
The commands worked perfectly for my issue, thanks @ivan-section-io !!! Now I have to see if it persists and if it helps my connection when I connect to a VPN on Windows but this is a great start for me |
Since the indices seem to change between reboots I'm now using the following command instead, which gets both the default switch and the WSL one by their alias and enables forwarding: Get-NetIPInterface | where {$_.InterfaceAlias -eq 'vEthernet (WSL)' -or $_.InterfaceAlias -eq 'vEthernet (Default Switch)'} | Set-NetIPInterface -Forwarding EnabledI've also tried running this script on every start using Task Scheduler, however this way forwarding is only enabled for Instead, I've now added the script to a function in my PowerShell profile so I only have to run |
|
Is there anyway to set the forwarding permanently or at least without the requirement of admin privilege? |
No need for IDs, use the alias instead: PS> Set-NetIPInterface -ifAlias "vEthernet (WSL)" -Forwarding Enabled
PS> Set-NetIPInterface -ifAlias "vEthernet (Default Switch)" -Forwarding EnabledNote: these can be localized, so this would work on an English (international) system only. |
I'm not sure if this is happening now. I just upgraded to the Insider Preview build 21354.1 today and suddenly WSL2 has IP address 192.168.XXX.1 (previously it's 172.16.0.0/12). This seems to be a big change but is not mentioned in the release announcement. I cannot
|
I'm pretty sure this is just the typical behaviour. HyperV based solutions have a certain number of gotchas that you can't work around. As I have said many times, it is an amazing tool for virtualizing Windows in enterprise/domain environments. It is highly inferior to even basic open source options in some other environments. But they broke virtualization for all competitors a while back, so many of us had to adapt. |
|
I tried to use this to setup some communication between a WSL2 Ubuntu 18.04 and a Windows guest VM where the two would need to communicate between each other with through multicast. However, despite normal pings working after the Forwarding Enabled -setting, multicast communication seemed to still not work (or at least the two apps on either side of the WSL2 <-> Hyper-V VM gap couldn't see each other). Any idea as to whether this is expected or not? |
|
Wow, I've been working on this for like a week now and I've made no progress... Can we just fix this and have it work? Edit: I actually think it is my company that has this locked down for one reason or another. Edit: Actually, WSL1 has network connectivity so I think it has something to do with Hyper-V... FIX IT! |
|
@bennettnw2 this is from July 2019 and hasn't been fixed for 2.5 years, as it pretty much doesn't resonate with MS team that says it's "not a bug but a feature". So don't expect it to be "fixed". Best way to use WSL (1 or 2) is not to use it, and use Hyper-V (or some other hypervisor) with small friendly Linux distro (like Ubuntu, that's pretty much "default" for most of WSL users anyway). It's even worth the small upgrade price from Home to Pro to get proper Hyper-V and proper virtualized networking stack, without hand holding and crutches. I tried WSL 1/2 over and over again, and every time I lose more time trying to make it work, instead just downloading Ubuntu ISO and starting a normal proper VM. I gave up on WSL a year ago, and I'm waiting if WSL 3/4/5 maybe fix the way of thinking in MS team. Hyper-V VM + Ubuntu server works like a charm though, and has been working awesome for me for years, through all the W10 minor/major updates, and from Ubuntu 16.04 till the latest ones, for good 5-6 years now, no flaws, no issues, on hundreds of VMs, tests, production, development, whatever. Takes 10-15 minutes to download, install, and setup, and most of that time is due to download speeds and hard drive speeds (downloading large ISO, waiting for installation, and updates during/after installation). |
|
I love using WSL2, but this bug is annoying (as are the blue screen of death's when opening large database backup files). But everything is annoying at some level if you push far enough and wsl2 + vscode has been a great productivity boon for me and my team overall using a custom wsl2 distribution we've built to match our deployment platform. For this particular bug I've added a command to our python build framework that looks like: This is using some other utility methods to run powershell commands, but the idea is just that Set-NetIPInterface command can fix things. I run that after a reboot when I'm using a hyper-v vm + wsl2 and realize my connectivity between the two is broken. Thanks to jonaskuske for posting the original script solution. |
|
As of a recent Windows 10 Pro patch I'm no longer able to SSH from WSL 2 into a separate Hyper-V Ubuntu 22.04 VM that I created. This set up was working great for years previously. I never had to run any PowerShell commands to enable forwarding but as per a few comments in this thread I ran this: And now I see this: But when I try to SSH into my Hyper-V VM (IP: The IP address and hostname are correct (I'm able to SSH into it from PowerShell). SSH is running on that VM and iptables isn't blocking any ports. I was able to successfully SSH into this VM in the past before whatever Windows patch broke things. This is a real bummer because I want to run Ansible against the VM but I can only do that from WSL 2. Any suggestions on where to go from here? My Hyper-V switches look like this:
And my VM is configured like this:
Basically all I did was create an external switch so the VM has public internet access. I also went as far as deleting all of the switches and making new ones, then I created both a fresh WSL 2 instance and a fresh Hyper-V VM. The result was the same. Unable to SSH into the VM from WSL 2. |
Thanks a lot. You are great. This absolutely fixed the communication issue between Kali on WSL and windows 10 on HyperV. (5tupid virtual switches!!!) |
|
Since I just got bumped on 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". You do need W11 Pro, which shouldn't be an issue. I've compiled a nice big tutorial couple of days ago as a comment in main networking thread: Likewise added it to my GitHub: I went through W10 to W11 upgrade (linked instructions for those with "unsupported" hardware), WSL2 Preview, creation of vSwitch, configuration of a bridge, and as a bonus systemd configuration on Ubuntu with complete systemd based networking setup. It should be doable for both newbies and experienced users. Btw, I can now tear up and setup new WSL2 instance with proper networking and full apt upgrades and all in less than 10 minutes, easy-peasy. |
|
Hello, How to switch back from the bridged network for WSL2 to Nat network ? I did not have access anymore to the Internet. |
|
@ghecko removing config from .wslconfig should revert to default NAT. But here is a more complete "cleanup" procedure. This is what you need: This would remove all modifications made by my guides. But I have to say that following my guide step by step should 100% work for Ubuntu. I have also tried ArchWSL and works fine (with minor modifications due to Are you using some other distro? I'd be happier solving the issue than giving up. In past 2 days I've had someone with OpenVPN, we solved that easily. Also in process I've tested networking in Ubuntu with NetPlan and NetworkManager. I'd be happy to test your case and solve it with you, it's a learning process for the whole community, if you have time. EDIT: Also, note that I used clean distros and systems that had all previous workarounds removed. I can't vouch for what happens if you have few powershell or bash scripts changing networking as old workarounds, then trying to use bridged network. Any previous workarounds need to be removed for bridged option to work properly. EDIT 2: Added separate guide for reverting settings: EDIT 3: Tested Debian, works exactly as Ubuntu, to the letter. |
added Removing_network_bridge_and_systemd_settings.md due to request from community member: microsoft/WSL#4288 (comment)
|
@luxzg, thank you for your very detailed response! I will try to implement your solution to switch back to NAT. It's probably due to the networkd and resolvd systemd services that are still running after the config modification. Let me try this ASAP and tell you if your instruction solves my issue :) EDIT: I just tried your solution and still not having Internet access. The DNS resolution does not work, and when I try accessing an Internet service, I obtain the following error: DNS resolution failed with the following error: However, the default route seems correct. the IP configuration: And finally, the following systems services are enabled: EDIT2: I've restarted the WSL NAT adapter as described here: https://gist.github.com/danvy/9486bf730371436131cb888ff4c2ceb6 and now everything seems working as expected. |
|
I'm glad you've got it working. Well, some of it at least. I finally got some time to test with kali few minutes ago, and it's been exactly same experience as Ubuntu and Debian. I'll document the bridge mode here again, in very short, and post same info you did so you can compare if you decide to try again with a bridge. Actually, I'll start with the very basic base of everything. Did you try running this command? It should return something like this: If it throws error you have wrong and/or older version of WSL !!! Please install latest version from Microsoft Store ! Since I keep reusing same vSwitch for all distros (and few Hyper-V VMs) I don't touch my vSwitch, but here is my network setup (laptop with just the WiFi adapter being connected right now): And this: So, my Physical WiFi (Killer WiFi 6) adapter is used for vSwitch If I want WSL to have working network, I need to use same settings as my PC, so let's get that: OK, so if my host IP is Same with my Contents of the file:
Then I had to install kali, obviously. It downloads, installs, boots, and I go through setting my new user and password. In the same window with new user I do these: I wait for it to exit, or kill it: Here you'd usually edit Then I start it again, with new Note that we didn't touch Anyway, inside kali WSL I finish the configurations as root (sudo): Exiting distro, shutting it down, even restarting PC, then going back in, should keep you on same IP, same working settings, Apache accessible from outside, WSLg working. It does for me. My system & network info from kali WSL running with working systemd, networkd, resolved, static IP, on network bridge and Hyper-V vSwitch: I'll understand if you've had enough testing, but I'd be glad if you tried again, or even if you just do the Cheers! |
This worked for me 👍 |
|
This issue has been automatically closed since it has not had any activity for the past year. If you're still experiencing this issue please re-file this as a new issue or feature request. Thank you! |
and others
Issue
WSL2 on the same system (laptop) as other hyper-V systems and vswitches. Not able to reach other hyper-v systems from within WSL2 like I am from the host command prompt. This boils down to a routing issue with no clear way of resolving it.
Issue Details
Windows Version: 1903
Build: 18922.1000
Originally WSL 1 was working along side other Hyper-V VMs. I had set up a dedicated switch for hyper-v, config details from netsh below for "NAT-Switch". The WSL 1 was able to connect to the other Hyper-V VMs through various networking protocols like, ssh, ping, etc
After upgrading the WSL instance to WSL 2 the routing from WSL 2 to the other hyper-V VMs appears to be broken.
From within WSL1 instance, pinging a VM in Hyper-V.
After converting to WSL2 instance,
From the host,
Expected Behavior
I would expect that from within WSL2 network traffic should be routed correctly to other VSwitches within the same physical host. Maybe additional configuration instructions are required for my above scenario but I suspect since the WSL2 network properties seem to be reconfigured on every reboot it won't help. Greater control over WSL2 networking would help, like setting static IP or subnet ranges or being able to change the vswitch that WSL2 uses.
Attempted Workarounds
Attempted to switch my Hyper-V VMs over to the WSL vswitch. This worked however the second problem discovered is every time I reboot my laptop WSL vswitch has a different IP and subnet. This makes accessing the hyper-V's using a consistent IP impossible and requires configuring IPs and hostnames, etc after every reboot. Because the subnet changes I am unable to set static IP's for the hyper-v instances.
I also attempted scripting the reconfiguration of the WSL adapter after every reboot so that it always uses the same subnet. This somewhat worked, if WSL and hyper-V VMs were on the same "WSL" virtual switch they could talk to each other. The problem with this approach is that the WSL 2 instance and hyper-V VMs are no longer able to reach outside IPs. So the routing somewhere in the "WSL" VSwitch is broken when I manually configure the "WSL VSwitch". Rebooting the host restores the routing to external IPs but results in the first problem of constantly changing subnets and IPs.
Additional Details
netsh dump
The text was updated successfully, but these errors were encountered: