WSL IP address & Subnet is never deterministic (Constantly changing) #4467
Comments
|
Duplicate of this issue #4210. |
|
I'm marking this as a duplicate of #4210 as that is our landing page for adding Static IP configuration to WSL. Thank you for submitting, we can always continue the discussion on 4210. |
|
@craigloewen-msft I disagree that this issue is in relation to static IP address -- my request is determinism, similar to how a normal dhcp pool client will request a renew and re-obtain a previous lease, rather than a separate one. On every boot, the WSL network completely changes an entire /16, and the VM within the /16 gets a completely different IP. The IPs are completely unpredictable. If I want a static IP, I want the ability to configure something (Issue #4210). This issue is about whatever IP address that is random, in lieu of static, needs to be deterministic and effectively not completely change semantics on every reboot. |
|
Fair point! Thank you for the additional context. I've reopened this and labeled it as a feature to add determinism to the IP of the WSL 2 VM. |
|
Was brought up that the non-determinism is a feature not a bug in the present model #4601, insofar as you can roll the dice and get a subnet that doesn't conflict with your VPN. So if this were ever implemented in isolation, it would require a (paraphrasing) " [Ideal solution remains using DHCP with a random but permenant (persisted) ethernet address for the WSL vEth.] |
|
As I wrote in #4601 as well, deterministic behavior is logically expected due to how all other past networking systems in use today work. Most closely being the classical DHCP server giving IP with a set lease time. Even if lease is 30 minutes, it would still be preserved on host or guest reboot. Having IP change on each reboot is a nightmare (to be kind). All these bug reports / feature requests are coming down to same issue - predictable and stable IPs. |
|
If possible, please raise the priority of this and/or #4601. There are many open issues currently that are basically just variant of this - VPN not working, losing network connectivity, Internet not working, command X not working all of a sudden, can't connect to/from Windows, etc. I appreciate WSL2 chose Hyper-V, and I actually also like the Default Switch. However, without some sort of configurability described in this and other tickets, we worker bees are at the mercy of corporate VPN rules that are just not compatible with the default Class B network arrangement done in the Default Switch. Thank you! |
|
+1 to what daveshih01 wrote, seems as if MS is just waiting for issue to go away by itself, and it won't. There had been zero information about improvements / changes to WSL2 networking past couple months, despite related issues flooding Github. If people go silent in individual threads that doesn't mean issue is gone, only that people are "polite" and don't want to nag developers. But issue is still there, and pretty much a show-stopper for many situations. Please, at least give us some feedback or thoughts from the team regarding these issues. Thanks! |
|
Until this feature is fixed, there aren't many use cases for WSL2. Please, please fix it. |
|
This is a blocker for a lot of "it would just work if the IP were predictable" workflows. |
|
Preventing me from using WSL2 as well. |
|
if this gets implemented does it mean i could keep my wsl/2 instances in the 172.16/10 subnet and never in the 192.168? |
|
my issue got marked a duplicate of this #5835 i'm not sure that makes sense especially since i specifically called this issue out and described why it's different since mine was about a specific feature request that would just be 1 way to solve this problem. but my request to reopen was not addressed and i'm at the mercy of the mods so i guess i'll just post here. tl;dr; if you let us specify the virtual network switch/adapter to use for WSL ala Is your feature request related to a problem? Please describe. Describe the solution you'd like this would be after i do something like: then any WSL instances after launch would use that network and get an ip from 172.18.5.0/24 Describe alternatives you've considered
Additional context |
|
It seems every time I chase this exact issue - Microsft is marking issues as a duplicate of Issue X, and then marking Issue X as a duplicate of THIS issue - and closing both. @drdamour hit the nail on the head here. I've spent the last hour even attempting some of the workarounds which are not working with the latest Cisco any connect. The only permanent sustainable solution is to allow us to specify what the internal network is. Currently, my company allows 172.16.0.0/16 to be ignored and not take over that route on VPN. |
Indeed, I even tried attaching the WSL switch to an existing OpenWrt installation. However it is giving me a ridiculous error:
Edit: Welp it works! You could workaround this by connecting the WSL switch to an external OpenWrt installed in Hyper-V. But you need to Assign WSL2 machine a static IP with OpenWrt running in Hyper-VFirst thing first, the WSL switch should be set as "internal" in Hyper-V manager ( Now we have a working OpenWrt installation in Hyper-V, with two adapters attached to it ---- One is binded to physical adapter and the other one (LAN) is for WSL. I suggest using IANA reserved "TEST-NET" IP ranges (192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24), otherwise you might experience IP conflict in an enterprise/school environment behind a NAT. I took Debian as example. You have to write Remember to run
And you need to run So why not just bridge WSL switch to an existing physical adapter?If you connect to a network requiring portal login, it would be tricky to set up the WSL2 machine's network... And this wouldn't offer the static IP address you wish after network changes. |
well, I've got 192.168.255.0/24 assigned as the network to do whatever with on my local network, which means host-local and NATted networking, having to configure the reverse of that network and possibly having my IP address changed every reboot is simply absurd. |
|
My approach to automating this, inspired by @jgregmac https://github.com/jgregmac/hyperv-fix-for-devs : https://selivan.github.io/2021/07/12/wsl-set-static-subnet-hack.html |
|
Subnet can be deterministic with this workaround #7395 |
|
After all the hype I've been hearing, I finally thought I'd give WSL (and HyperV) a try in our organization. I spent hours googling around on how-to resolve this seemingly simple networking issue - and then I came up with this. I am absolutely flabbergasted. This issue has been open for well over a year and it seems to be a blocker for many (if not most) organizations. Random network range is just a no-go in any large enterprise. ps. I know that this post doesn't add any value to those in community that are trying to fix the issue. I just can't up-vote this issue enough |
|
Here's an adaption of @Biswa96's solution in Powershell. The key point is that WSL2 manages networks using Host Compute Network API. API is extremely poorly documented (yes there's documentation, but it's not up to date or cover all use-cases... so typical from certain vendor) Resources created using the API do not persist over reboots and it does not provide functionality to use static IPs (at-least it's not documented anywhere) Note: This solution does not require creating dummy network adapters. It allows you to specify exactly which subnet you want to use. And if you need to use static ip, you can adjust netmask to limit dhcp range to just one free address. |
|
As a kubernetes developer AND someone who refuses to wear a Mac, the best environment for me to work in is WSL2's linux. Docker daemon also requires a large subnet that WSL2's networking occasionally steps on. So as you can imagine, linux docker developers that have to VPN into large corporations have double the pain with this issue. |
|
WSL-IpHandler is an alternative solution which puts together some of the approaches posted here in a single Powershell module. It allows to control both a deterministic SubNet and a static IP addresses for WSL instances. |
|
@Biswa96 thanks for hint on the fields in JSON - I realized that after a few trials and last version only sets the very minimum of fields that replicated the built-in WSL configuration: {
"Name": "WSL",
"Type": "ICS",
"Flags": 9,
"DNSServerList": "192.168.0.1",
"Subnets": [
{
"IpSubnets": [
{
"Flags": 3,
"IpAddressPrefix": "192.168.0.1/24"
}
],
"AddressPrefix": "24"
}
]
}My apologies if I failed to track the origins of the idea to you - I have been using @skorhone's script as a source. Well that's easy to fix. Thank you for bringing this up. |
@Biswa96 Attribution added to my repo. My apologies, I did catch the source citation at @skorhone's project. I am hoping for an MS update that makes all this work obsolete, but I am not holding my breath for it. |
|
Update - It looks like Cisco is "fixing" it from their end. I was just notified by our IT dept. that the new AnyConnect client will have a fix for host local networks. |
|
Who in the world thought it was smart to have
Guys, even if WSL actually needs a /16 (which I'm skeptical of), let us specify what /16 you can have. There's gotta be a line of code somewhere in the guts of WSL2 that's specifying |
|
This is the cause of issues on my setup too... |
|
This is continuously causing problems, just to name recent one:
Can we have at least some blacklist of subnets WSL2 will not use? |
|
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 Likewise, I've added it to my GitHub, with some more polish, comments and tweaks added over time: 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! |
|
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. 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 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. |
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. |
|
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 :
|
I'm author of that script and this is my corporate GH account. It unfortunately seems that my script is no longer compatible with current version of Windows. I'm not going to fix it - took me days to figure it out last time. I'm not going to use mirrored-mode. This feature is completely undocumented from security perspective. If I got the mirrored mode right, operating system will mirror all network packages to virtual machine. Now if you ask me, connecting the VM which isn't automatically security patched directly to a public network doesn't sound like a great idea to me. Yes there's a firewall implementation, but it only works to some extent. There's not too many options for me left to do my daily work. For those of still using WSL2, I do hope that Microsoft does get this sorted out. After waiting for proper fix for couple of years and getting zero responses for them in these threads, I wouldn't keep my hopes high. If you do need to develop for *nix, my recommendation is to switch operating system. |
and others
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 [email protected]. 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)
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.
The text was updated successfully, but these errors were encountered: