search

microsoft / WSL

Issues found on WSL
https://docs.microsoft.com/windows/wsl
MIT License
16.95k stars 798 forks source link

WSL IP address & Subnet is never deterministic (Constantly changing) #4467

Open jpsenior opened 4 years ago

jpsenior commented 4 years ago

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:

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.

Biswa96 commented 4 years ago

Duplicate of this issue https://github.com/microsoft/WSL/issues/4210.

craigloewen-msft commented 4 years ago

I'm marking this as a duplicate of https://github.com/microsoft/WSL/issues/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.

jpsenior commented 4 years ago

@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.

craigloewen-msft commented 4 years ago

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.

therealkenc commented 4 years ago

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) "wsl.exe --pick-a-different-nondeterministic-subnet".

[Ideal solution remains using DHCP with a random but permenant (persisted) ethernet address for the WSL vEth.]

luxzg commented 4 years ago

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). For some reason MS does WSL (and Windows Sandbox) same way as Hyper-V's Default switch, with a problem being obvious - on "full" Hyper-V you can manually create another External or Internal virtual switch, and use that instead, but no such option on WSL 2. Usage case for WSL 2 is huge, but current way of assigning IPs is handicapping the whole project. People will literally switch to other host OS just because of this one badly designed feature. WSL networking (as well as that of Hyper-V Default switch and Windows Sandbox) need to be seriously rethought. It can be "fixed" partially by allowing a choice of network subnet/range, PLUS an equivalent of lease time to prevent change on reboot (or if VM/WSL wasn't in use for a short while). If previously assigned IP was good and it wasn't reassigned in meantime, WSL (and similar systems) should get it again even if a year passed. I agree that mechanics needs to be in place to request new IP, but if 4601 is implemented you won't need to keep resetting your IPs all the time. But still, a simple "reset" command could be implemented to flush all cached information (eg leased IPs, subnets, etc). It could also be useful for hard reset in case of bad config.

All these bug reports / feature requests are coming down to same issue - predictable and stable IPs. I am glad to see that team is at least hearing the feedback, and I hope that down the line the reasoning will also trickle down to other related teams (all being based on Hyper-V virtual switching). If it was down to me, I would probably keep the defaults as is, but allow everyone to use Hyper-V custom External or Internal switch for their virtualized subsystem, be it full Hyper-V VM, WSL 2 networking, or Windows Sandbox. And if end user decides to use the alternative networking setup, and disconnects default built-in NAT networking for all subsystems that use that very same NAT - then allow user to disable the surplus networking. For couple years now we keep seeing issues people have with Default Switch, and so many revisions down the line it is still NOT the optional feature it should have been since start. Sorry if it sounds like a rant, I just hope we won't get to WSL 4.5 in 2025 and still have the same situation as we've been having for years now on other (related) front. Thanks!

daveshih01 commented 4 years ago

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!

luxzg commented 4 years ago

+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!

odbayar commented 4 years ago

Until this feature is fixed, there aren't many use cases for WSL2. Please, please fix it.

GLStephen commented 4 years ago

This is a blocker for a lot of "it would just work if the IP were predictable" workflows.

Jan1torEarl commented 4 years ago

Preventing me from using WSL2 as well.

drdamour commented 3 years ago

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?

drdamour commented 3 years ago

my issue got marked a duplicate of this https://github.com/microsoft/WSL/issues/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 wsl --set-default-switch "JRS WSL" it's be really helpful

Is your feature request related to a problem? Please describe. I'm in a corporate environment and my windows defender is very restricted. I do get to own the 172.18.0.0/16 address space. We use this for our docker desktop stuff so we can have things talk, and i want to do the same for my WSL2 but there doesn't seem to be a way to tell WSL to use that space. Every reboot it just randomly picks something from 172.16.0.0/10 or 192.168.0.0/24 it seems and i can't change it.

Describe the solution you'd like I want to be able to do wsl --set-default-switch "JRS WSL"

this would be after i do something like:

New-VMSwitch -SwitchName "JRS WSL" -SwitchType Internal
New-NetIPAddress -IPAddress 172.18.5.1 -PrefixLength 24 -InterfaceAlias “vEthernet (JRS WSL)”
New-NetNAT -Name “JRS WSL NAT” -InternalIPInterfaceAddressPrefix 172.18.5.0/24

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 There's a lot of issues related to this out there:

Additional context Is there some guidance on how we can have our corporate GPO setup so that windows defender doesn't get in the way of internal network adapters? They have NO net connection profile...can GPO target them by that + internal? That'd be another way to solve this

jbragdon1 commented 3 years ago

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.

Aster-the-Med-Stu commented 3 years ago

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 wsl --set-default-switch "JRS WSL" it's be really helpful

Is your feature request related to a problem? Please describe. I'm in a corporate environment and my windows defender is very restricted. I do get to own the 172.18.0.0/16 address space. We use this for our docker desktop stuff so we can have things talk, and i want to do the same for my WSL2 but there doesn't seem to be a way to tell WSL to use that space. Every reboot it just randomly picks something from 172.16.0.0/10 or 192.168.0.0/24 it seems and i can't change it.

Describe the solution you'd like I want to be able to do wsl --set-default-switch "JRS WSL"

this would be after i do something like:

New-VMSwitch -SwitchName "JRS WSL" -SwitchType Internal
New-NetIPAddress -IPAddress 172.18.5.1 -PrefixLength 24 -InterfaceAlias “vEthernet (JRS WSL)”
New-NetNAT -Name “JRS WSL NAT” -InternalIPInterfaceAddressPrefix 172.18.5.0/24

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 There's a lot of issues related to this out there:

  • 4467 - the issue in terms of not being able to specify the ip deterministically. If we can specify the switch then this gets closed.

  • 4139 - the issue in terms of defender firewall, again if you can specify the switch you can whitelist a network and this gets a solution

  • 4285 - specifically about DNS not working, since the WSL host is asking your laptop to resolve dns names on port 21 the firewall blocks these. This is how i noticed the problem at first, but of course it's a bigger issue.

  • 4210 - this is about assigning a static ip, but many of the workarounds are about setting up the network as needed. If we can specify a /31 subnet..that's effectively a static ip.

  • https://techcommunity.microsoft.com/t5/windows-insider-program/hyper-v-default-switch-ip-address-range-change-ver-1809-build - lots of people fighting over specifying subnets for VMs...not WSL specific but it's the same basic issue
  • https://gist.github.com/coltenkrauter/608cfe02319ce60facd76373249b8ca6 - people are doing weird workarounds cause they don't realize this is a firewall issue between their VM and Host, so they're skipping it and going to internet DNS

Additional context Is there some guidance on how we can have our corporate GPO setup so that windows defender doesn't get in the way of internal network adapters? They have NO net connection profile...can GPO target them by that + internal? That'd be another way to solve this

Indeed, I even tried attaching the WSL switch to an existing OpenWrt installation. However it is giving me a ridiculous error:

❯ Connect-VMNetworkAdapter -VMName OpenWrt -Name WSL -SwitchName WSL
Connect-VMNetworkAdapter : Failed to modify device 'Ethernet Connection'.
'OpenWrt' failed to modify device 'Ethernet Connection'. (Virtual machine ID ED89A066-F6DB-4F06-B89F-47866951C04D)
Could not find Ethernet switch 'A26945C2-15D2-453A-9C9A-A180208FCF6B'.

I just don't understand why WSL2, which is based on Hyper-V, has such a weird switch.

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 wsl --shutdown first... There isn't an explicit enough error warning about this...

Assign WSL2 machine a static IP with OpenWrt running in Hyper-V

First thing first, the WSL switch should be set as "internal" in Hyper-V manager (wsl --shutdown first), so that WSL2 instance could connect to Hyper-V host. Setting up OpenWrt shouldn't be too hard in Hyper-V but remember, OpenWrt image doesn't support UEFI. As a result, Gen1 machine should be used. Of course, other router OS like PfSense works.

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 /etc/network/interfaces by yourself, like:

# interfaces(5) file used by ifup(8) and ifdown(8)
# Include files from /etc/network/interfaces.d:
source-directory /etc/network/interfaces.d

# The loopback network interface
auto lo eth0
iface lo inet loopback

# The primary network interface
iface eth0 inet dhcp

Remember to run touch /etc/fstab first otherwise the default isc-dhcp-client would refuse the IPv4 address:

root@[Redacted]:~# ifup eth0
Internet Systems Consortium DHCP Client 4.4.1
Copyright 2004-2018 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/eth0/00:15:5d:45:76:1e
Sending on   LPF/eth0/00:15:5d:45:76:1e
Sending on   Socket/fallback
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 8
DHCPOFFER of 192.0.2.135 from 192.0.2.1
DHCPREQUEST for 192.0.2.135 on eth0 to 255.255.255.255 port 67
DHCPACK of 192.0.2.135 from 192.0.2.1
/sbin/dhclient-script: 19: /sbin/dhclient-script: cannot open /etc/fstab: No such file
DHCPDECLINE of 192.0.2.135 on eth0 to 255.255.255.255 port 67

At last you could finally set up some static address in OpenWrt's DHCP server config (As WSL2 virtual adapter's MAC seems not changing over time) or (if you wish) False, WSL2's MAC address is constantly changing. Modify /etc/network/interfaces and set a static IP. This should be a working workaround before Microsoft finally fixes this in default config.

And you need to run [Release name] run bash -c "ifup eth0" to start this machine, as WSL2 has no systemd nor SysV support.

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.

daveshih01 commented 3 years ago

Somebody posted another workaround in Reddit - https://www.reddit.com/r/bashonubuntuonwindows/comments/ggexp8/why_the_ip_address_generated_by_the_wsl2_network/fqp10wo/

I think I've resoled my issue. Just created dummy NIC (just in Control Panel) with static IP4 network 172.16.0.0 255.240.0.0 . This avoid WSL2 for creating NIC with B class networks at all. So WSL2 go back to C class networks - automatically (as for legacy WSL) ... and now my VPN works well with WSL 2 (OpenVPN reroute all 172.16.x traffic to vpn gateway in my case that cause huge CPU usage) - I'm so happy :)

Also Docker on WSL 2 go back to C class network.

If anyone has detailed steps of how that's done. Please share here. Thanks.

daveshih01 commented 3 years ago

If anyone has detailed steps of how that's done. Please share here. Thanks.

I was able to do this by doing the following, by following https://www.petri.com/using-nat-virtual-switch-hyper-v:

Deploying a NAT Virtual Switch The first step is to create an Internal virtual switch; this is a switch that is not connected to a physical NIC on the host; instead, the host management OS has a virtual NIC that is connected to the virtual switch; the end result is that (to begin with) that virtual machines on the internal virtual switch can talk to the host, but they cannot talk to the network that the host is connected to.

New-VMSwitch -SwitchName “DummySwitch” -SwitchType Internal

The next step updates the virtual NIC that connects the host management OS to the internal virtual switch. The following command will assign an IP address to this virtual NIC, and this IPv4 address will be the default gateway for the network on NAT network that we are creating.

New-NetIPAddress -IPAddress 172.16.0.1 -PrefixLength 12 -InterfaceAlias “vEthernet (DummySwitch)”

Lastly, reboot your Windows 10 just to be safe.

Thus blocking out the entire range of 172.16.0.0/12 that the default switch favors, and now my WSL 2 VM will always stay in 192.168.x.x IP range.

I know this is not what everyone wants, but I hope it will help some folks out there who are facing this issue.

berlincount commented 3 years ago

I'm also affected by this bug, do not consider it a feature, and am prevented from using WSL "for real" by it :-/

The time at which Hyper-V decides which IP networks aren't conflicting is not the time I have all of them active.

naruco commented 3 years ago

If anyone has detailed steps of how that's done. Please share here. Thanks.

I was able to do this by doing the following, by following https://www.petri.com/using-nat-virtual-switch-hyper-v:

Deploying a NAT Virtual Switch The first step is to create an Internal virtual switch; this is a switch that is not connected to a physical NIC on the host; instead, the host management OS has a virtual NIC that is connected to the virtual switch; the end result is that (to begin with) that virtual machines on the internal virtual switch can talk to the host, but they cannot talk to the network that the host is connected to.

New-VMSwitch -SwitchName “DummySwitch” -SwitchType Internal

The next step updates the virtual NIC that connects the host management OS to the internal virtual switch. The following command will assign an IP address to this virtual NIC, and this IPv4 address will be the default gateway for the network on NAT network that we are creating.

New-NetIPAddress -IPAddress 172.16.0.1 -PrefixLength 12 -InterfaceAlias “vEthernet (DummySwitch)”

Lastly, reboot your Windows 10 just to be safe.

Thus blocking out the entire range of 172.16.0.0/12 that the default switch favors, and now my WSL 2 VM will always stay in 192.168.x.x IP range.

I know this is not what everyone wants, but I hope it will help some folks out there who are facing this issue.

this is a simply way, and i'd done!

JosephHalter commented 3 years ago

If I create this VMSwitch using the proposed commands, I can't connect to my company VPN anymore.

git-rz commented 3 years ago

If I create this VMSwitch using the proposed commands, I can't connect to my company VPN anymore.

Same here, which is why I tried a slightly different approach that seems to be working: Simply configure an unused network adapter with a static IP and /16 subnet range. Leave it disconnected and it doesn't interfere with your company vpn.

image

I actually needed to block out the 192.168 to force WSL onto the 172.

This has worked for me and some of my team across several reboots. However, due to the intermittent nature of the issue in general, I am not sure this is 100% effective.

raphm commented 3 years ago

Chiming here to say that I agree with @berlincount. I'm also affected by this bug, and it renders WSL2 unusable for my purposes. You have built an amazing automobile here, and I really want to drive it, but the steering wheel keeps moving around every time I sit in the driver's seat.

GLStephen commented 3 years ago

Can someone on the Windows team explain why this is such an issue? Entire classes of use cases are stymied by this one feature that is a pretty basic capability of a "real" machine and an important one to emulate.

jgregmac commented 3 years ago

I agree that this (and similar issues with running vms on the default switch) must be resolved, and soon. This basic feature gap prevents everyone on my team from using Windows for the bulk of their developer work. I am tired of testing new workarounds to this problem that has hindered my work since the introduction of client hyper-v and more recently since the introduction of WSL2.

Adding dummy a dummy nic or virtual switch is not a good workaround. It is cumbersome to users, and I find that it causes severe network performance degradation owing to routing problems.

After over 20 years of telling teammates, “No, you don’t need a Mac,” I have surrendered. On this team, for our development work, we have to run Ubuntu or “get a Mac”. I hate this situation. Please correct this problem expeditiously!

kvietmeier commented 3 years ago

Just to pile on. Everyone except a few die hards that want to resort to some serious hackery have given up on WSL 2 at my company for all of the reasons outlined in these Issues.

The fix appears on the surface to be relatively straightforward and the problem related to the know issues with the default HyperV NAT'd vswitch. Not sure why this is so hard - both VMware Workstation and Virtualbox have had functional and reliable default vswitches that use the same address space and default local IP every time unless you change the CIDR for the vswitch. If you do nothing - you get the "default vswitch" - many tools rely on this, especially Vagrant.

Give us a standard, built-in default vswitch that assigns every VM the same IP and uses NAT. This has been working for Vbox and VMware on Windows for at least 10yrs but probably closer to 15.

jgregmac commented 3 years ago

For what it is worth, I have authored a PowerShell script that automates one of the workarounds to this issue that has cropped up in various forums. The script has not been tested extensively, but I have had some positive feedback from immediate co-workers.

The script sets up a dummy loopback adapter that "fakes out" Hyper-V and WSL2 when they startup so that they will not grab a network range that overlaps with your corporate private networks. Startup and shutdown scripts are installed that activate and de-activate the dummy interface a key times (you would not want it running at all times, of networking simply would break).

The script takes some of the pain out of implementing a seriously kludgy workaround: no manual installation of loopback adapters of creation of scheduled tasks are required. But this definitely should not be confused for "a solution": it's just a workaround.

I am posting the script here in case it helps anyone while a real fix emerges: https://github.com/jgregmac/hyperv-fix-for-devs

7e4 commented 3 years ago

This needs to be fixed. Wasted 2 hours trying to find out why a server was unreachable, only to find out Hyper-V used the servers subnet for it's WSL switch... What a toy OS.

selivan commented 3 years ago

This prevents me from using WSL with corporate VPN, because sometimes it suddenly overlaps with networks routed with it. Totally unusable without an option to explicitly set subnet for WSL.

I mean no offence, but what were the developers thinking? "Hey, let's make it use random private subnet on every reboot, people love random subnets suddenly overlapping their own subnets".

berlincount commented 3 years ago

I mean no offence, but what where the developers thinking? "Hey, let's make it use random private subnet on every reboot, people love random subnets suddenly overlapping their own subnets".

tbh, by now, I'm totally willing to go on the offense: seriously, what the fsck?!?

and not a single response from @microsoft on this thread yet - I'm deliberately pinging @craigloewen-msft @jackchammons @benhillis @bitcrazed @OneBlue, as they are likely amongst the ones who can help us remove all of the cludges, hacks and workarounds by coming up with a proper solution (like allowing pre-selection of Hyper-V interfaces or at least a subnet).

my biggest worry is that diffusion of responsibility will make none of them respond - so, I'm kindly asking for every single one of them to respond, and forward and escalate this issue to the correct persons.

it IS actually actively harming productivity for a significant about of people, as you can see from the amount of responses on this ticket and this comment alone (click "thumbs up" if you are affected and want a change).

luxzg commented 3 years ago

I mean no offence, but what where the developers thinking? "Hey, let's make it use random private subnet on every reboot, people love random subnets suddenly overlapping their own subnets".

tbh, by now, I'm totally willing to go on the offense: seriously, what the fsck?!?

and not a single response from @microsoft on this thread yet - I'm deliberately pinging @craigloewen-msft @jackchammons @benhillis @bitcrazed @OneBlue, as they are likely amongst the ones who can help us remove all of the cludges, hacks and workarounds by coming up with a proper solution (like allowing pre-selection of Hyper-V interfaces or at least a subnet).

my biggest worry is that diffusion of responsibility will make none of them respond - so, I'm kindly asking for every single one of them to respond, and forward and escalate this issue to the correct persons.

it IS actually actively harming productivity for a significant about of people, as you can see from the amount of responses on this ticket and this comment alone (click "thumbs up" if you are affected and want a change).

I'd like to chime in a little after months of "absence" from this issue.

1) I gave up on WSL completely, I use "proper" Win 10 Pro or Win Srv so I just install my "proper" VMs with real networking and real OS (such as Ubuntu server) whenever I need Linux based functionality.

2) I tried pinging those people, makes no difference because... (see 3.)

3) By all their comments and responses this is BY DESIGN and is made to make WSL2 networking transparent for newbs with Win 10 Home that need Linux layer on Win 10 as a CLIENT. Any linux-server functionality is not in their scope. They just want to let you use basic Linux CLI commands, and lately goal seems to be a compatibility layer for CLIENT Linux GUI apps, primarily through Ubuntu partnership. If you want Linux server applications or services like (obviously) web server (Apache, nginx) or databases (MySQL, PostgreSQL) , or containers - they aren't really interested in helping you.

Now, we all know reality is that average Win 10 Home user doesn't use or need Linux, and as such doesn't really need WSL. And advanced users that would welcome real Linux compatibility layer also need proper networking. So WSL2 is left for sysadmins that need to use CLI tools that lack equivalent on Windows, and couple diehard tinkerers that have time and will to just experiment all the time, and are likely also Windows Insiders or MS employees.

Due to above WSL2 was and will stay a good idea with completely missed goals and audience.

With Win 11 we will probably get something like WSL3 that includes completed GUI / X server integration, with same dumbed down networking, aimed at next generation of Windows Insiders with latest and greatest hardware (all that 0.01% of market), and that's it.

My recommendation for 95% of Windows professionals (developers, admins, and such) is to just get Pro and use Hyper-V, with proper virtual switching stack, and put normal Linux distro that they'd otherwise use in production as local VM. Or if you are home/student user that can't afford Pro, use Win Home and Virtual Box as cheaper solution, but still with way better emulation.

7e4 commented 3 years ago

My recommendation for 95% of Windows professionals (developers, admins, and such) is to just get Pro and use Hyper-V, with proper virtual switching stack

My guess is we are all way past that level and can't move fully to Linux because of business policies and/or applications only available on Windows. WSL is great and serves a purpose. The issue needs to be fixed.

selivan commented 3 years ago

this is BY DESIGN and is made to make WSL2 networking transparent for newbs

That is ridiculous. For example, Virtualbox automatically creates host-only networks with subnets from 192.168.0.0/16 and NAT networks with subnets from 10.0.0.0/8, but they are fixed after being created and you can change subnets. Everything is working automatically for newbs, and people who need that subnets can just change it and be happy too.

7e4 commented 3 years ago

Now that I at least found the cause of the server being unreachable, I can work around it. I guess that's why MS doesn't put a high priority on this one. So it will be part of the routine to run check_wl_ip.cmd:

wsl --shutdown wsl ip a pause

to see if it uses a conflicting IP range.

selivan commented 3 years ago

@7e4 For me WSL does not change it's subnet on wsl --shutdown, only on complete system reboot.

git-rz commented 3 years ago

To reliably work around this problem you must work with your networking team to identify an IP range reserved for local virtual network overlays, one that will not conflict with VPN static routes. Then block off all the other possibilities with dummy adapters.

Here is a powershell script to create dummy adapters. In this example, dummy adapters are created to block off all possible addresses except for 192.168.0.0/18.

choco install -y devcon.portable

function register-dummy-adapter($name, $ip, $netmask) {
  devcon64 -r install $env:windir\Inf\Netloop.inf *MSLOOP

  $id = (Get-WmiObject Win32_NetworkAdapter -Filter "ServiceName='kmloop'" | Select-Object  -Last 1).NetConnectionID
  netsh int set int name = $id newname = $name

  $nic = ( Get-WmiObject Win32_NetworkAdapterConfiguration | Select-Object -Last 1)
  $nic.EnableStatic($ip,$netmask)
}

register-dummy-adapter Dummy192.168.64  192.168.64.1  255.255.192.0
register-dummy-adapter Dummy192.168.128 192.168.128.1 255.255.192.0
register-dummy-adapter Dummy192.168.192 192.168.192.1 255.255.192.0
register-dummy-adapter Dummy172.16      172.16.0.1    255.240.0.0

Run it with admin privileges. If you don't use chocolatey then you will need to adjust the devcon commands.

berlincount commented 3 years ago

To reliably work around this problem you must work with your networking team to identify an IP range reserved for local virtual network overlays, one that will not conflict with VPN static routes. Then block off all the other possibilities with dummy adapters.

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.

selivan commented 3 years ago

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

Biswa96 commented 2 years ago

Subnet can be deterministic with this workaround https://github.com/microsoft/WSL/discussions/7395

skorhone commented 2 years ago

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

skorhone commented 2 years ago

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.

https://github.com/skorhone/wsl2-custom-network

YAMLcase commented 2 years ago

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.

mrkanaly commented 2 years ago

@jgregmac has updated his solution using the work done by @skorhone. It provides a script to install a logon event that will re-create the WSL switch in your preferred location every time at boot. Recommend checking it out.

https://github.com/jgregmac/hyperv-fix-for-devs

wikiped commented 2 years ago

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 commented 2 years ago

@jgregmac @wikiped It is not required to set every field of that JSON data to create a virtual network. BTW, a little attribution of the original idea would be appreciated.

wikiped commented 2 years ago

@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.

jgregmac commented 2 years ago

@jgregmac @wikiped It is not required to set every field of that JSON data to create a virtual network. BTW, a little attribution of the original idea would be appreciated.

@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.

kvietmeier commented 2 years ago

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.

danieltharp commented 2 years ago

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 172.16.0.0/12 or the like.

zappacor commented 1 year ago

This is the cause of issues on my setup too... Any plan to make the WSL DHCP pool configurable? Or, at least, how can I get an IP address within the WSL subnet that won't be used so I can be 100% I won't run into duplicate IP issues?

izderadicka commented 1 year ago

This is continuously causing problems, just to name recent one:

Can we have at least some blacklist of subnets WSL2 will not use?