Allow setting Windows vEthernet (WSL) RFC1918 selection

[postwait]

In build 18999.vb_release.191004-1432 (and lower) the WSL2 Windows-side address is chosen at random. On most complex corporate networks there are many routed RFC1918 spaces that are not directly attached (or become attached during subsequent VPN attachment). The random selection has a high probability of colliding with such in-use spaces.

There should be an option to assign the host-side vEthernet (WSL) a static IP and subnet (e.g. 172.28.254.0/24) and then have the vEthernet and WSL2 host(s) choose their IP addresses accordingly.

Currently, I have to reboot until it find a non-colliding network for the WSL2 subsystem.

There are no "commands to repeat this problem" as it pervasively exists. This is a request to add something like:

wsl --internal-net 172.28.254.0/24

(it would obviously require a --shutdown and restart upon change)

[Biswa96]

This is somewhat similar with #4210. Though the feature request idea is good. WSL2 is in insider builds now and corporate may not use unstable builds.

[postwait]

I will note that this isn't the same as setting an ip on a wsl instance. This is setting the network in which the current behavior takes place. I think it would be onerous to require a user to actually choose ips for all their wsl to get a good subnet.

[therealkenc]

There is only one IP address for "all your wsl" for the single kernel instance. The WSL subnet is always a /8, and there is are exactly two ethernet addresses with two IP addresses on that segment. You picking a /8 subnet and WSL picking IP between 2 and 254 on that sub are the same thing as you picking the number once. I am not entirely sure why the number is random --- it could be .2 (the gw is always .1).

There is an ask somewhere for each distro instance to have its own IP but I can't find it. There's another for the number being picked out of a hat to be deterministic #4467. Yours can be an ask to pick the hat. Fair enough.

[luxzg]

This suggestion would help in grand scheme. Unsure if it would solve all issues stemming from it, but sounds as easy to implement without breaking current ways. Also, it is quite inexplicable why IPs have to change on each reboot, if it works, why change it on next boot? Every DHCP out there has lease time, except MS virtual switch setups (including WSL2 and Hyper-V's "Default switch"). So I'd support the above suggestion, but also there needs to be a "lease time" ot equivalent, otherwise most common issues/scenarios will happen again and again. Limiting to a /24 subnet (as in example: 172.28.254.0/24) will only help long-term if we dont get last octet at .123 on one reboot and .234 on next one. If it keeps shuffling, yes, this suggestion will help with avoiding conflicts on large networks, but - that's all it will do. Randomisation on current scale is bad.

[eduardcloud]

Hi,
Is there provision for this? Really need it when you have a lot of vpns.

[berlincount]

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.

[petr-motejlek]

We need at least a way how to make it refresh the subnet. As of now, we are playing a roulette whether WSL picks a subnet that our VPN uses and they block each other out :D

[chewi]

This is affecting a large number of people within Microsoft. Please can it get some attention.

[luxzg]

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:
#4150 (comment)

Likewise added it to my GitHub:
https://github.com/luxzg/WSL2-fixes

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.

[postwait]

This issue isn't about bridging. Bridging is nice and a very welcome feature. But it isn't suitable for everyone as I often don't want my wsl hosts on my local network. I usually wanted them sitting behind a host-managed NAT as they are by default. That said, I still need to be able to control the assigned subnet.

I am surprised this feature isn't a low-hanging-fruit engineering ticket. While I've not seen the source, I can't imagine it being a compared implementation.

[luxzg]

Well, first of all, most people complaining here usually complain because IP from WSL is colliding with their corporate network or VPN. Bridging with known IP helps with that. It also allows your WSL instance to be a part of VPN and corporate network. Likewise, in exactly the same way it also allows you to tell it NOT to be part of your VPN or corporate network. Actually, you can do just about anything at all. Because Hyper-V switch can be External or Internal or Private. Likewise, NAT is still a possibility, just needs a few more settings. It is all described in Microsoft documentation regarding Hyper-V Virtual Switch (including further linked NAT docs) and it can all ve read here: https://learn.microsoft.com/en-us/virtualization/hyper-v-on-windows/quick-start/connect-to-network

Sure, "bridged" is a name in the config, but it is just a config name, functionality is giving you access (or "bridge") to "raw" Hyper-V network adapter. And only thing that differs this from standard Hyper-V VM networking is that (at the moment) you can add only one adapter to your WSL2 distro, while a VM can handle "n" adapters of any kind.

I do realize it's more work than simply having a one-liner in wsl.conf or .wslconfig, but spending 10-15 minutes to setup WSL networking with current "bridging" option is IMHO best option we've had in about 6.5 years of WSL lifetime.

If you think that using NAT on WSL2 manually is a huge issue let me know, and although I have personally exactly zero need for NATed WSL, I'll make a proof of concept guide for you.

[postwait]

I already have my WSL instanced NATted manually. It is effective, but unnecessarily complex as WSL, by default, choose a random subnet and there should be a way to override that because it's the right protect feature to have.

That said, a guide would be an excellent contribution. +1

[luxzg]

I already have my WSL instanced NATted manually. It is effective, but unnecessarily complex as WSL, by default, choose a random subnet and there should be a way to override that because it's the right protect feature to have.

That said, a guide would be an excellent contribution. +1

I finally caught some time tonight, but unfortunately I'm having some weird hickups, so I'll admit defeat (for now).
I do everything "by the book" but as soon as I attach internal switch to WSL via bridge option something happens, and WSL starts with systemd all borked up. systemctl calls and even "service... " commands all time out, and even "sudo" takes 2-3 minutes to go through, so it's impossible even to (re)start a network service/daemon. As soon as I replace that "NetNAT+internal" interface with good old "external vSwitch" everything is back to normal. I tried several times, tried changing subnets, but something there just doesn't like me. And with midnight near, I call it a day. Sorry for giving up on that part of the guide :-( But I do mean that "for now"... When I get to another PC with WSL I'll give it a quick try again, maybe it's just something on my PC. Btw, I do have a quick guide written for these steps, if someone wants to try on their PC, I can post it somewhere (not here, not to confuse innocent people "passing through"). Sorry again for a fail.

[microsoft-github-policy-service]

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!

[berlincount]

for the next one stumbling on this: I found #4210 (comment) to be helpful here.

I'm using 192.168.255.0/24 for my VMs and have been happy since.