Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
jpsenior opened this issue Sep 4, 2019 · 62 comments
Open

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

jpsenior opened this issue Sep 4, 2019 · 62 comments
Labels

Comments

@jpsenior
Copy link

jpsenior commented Sep 4, 2019

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)

$ ip addr show dev eth0
4: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:15:5d:94:d3:0c brd ff:ff:ff:ff:ff:ff
    inet 172.20.205.122/16 brd 172.20.255.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::215:5dff:fe94:d30c/64 scope link
       valid_lft forever preferred_lft forever
  • 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.

@Biswa96
Copy link

Biswa96 commented Sep 4, 2019

Duplicate of this issue #4210.

@craigloewen-msft
Copy link
Member

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.

@jpsenior
Copy link
Author

jpsenior commented Sep 8, 2019

@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
Copy link
Member

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
Copy link
Collaborator

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
Copy link

luxzg commented Dec 8, 2019

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
Copy link

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
Copy link

luxzg commented Jan 18, 2020

+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
Copy link

odbayar commented Apr 5, 2020

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

@GLStephen
Copy link

GLStephen commented Jun 1, 2020

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

@Jan1torEarl
Copy link

Preventing me from using WSL2 as well.

@drdamour
Copy link

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
Copy link

drdamour commented Sep 9, 2020

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:

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
Copy link

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
Copy link

Aster-the-Med-Stu commented Sep 23, 2020

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:

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.

@berlincount
Copy link

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
Copy link

selivan commented Jul 13, 2021

@Biswa96
Copy link

Biswa96 commented Sep 5, 2021

Subnet can be deterministic with this workaround #7395

@skorhone
Copy link

skorhone commented Sep 6, 2021

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
Copy link

skorhone commented Sep 8, 2021

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
Copy link

YAMLcase commented Oct 2, 2021

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
Copy link

@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
Copy link

wikiped commented Oct 22, 2021

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
Copy link

Biswa96 commented Nov 4, 2021

@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
Copy link

wikiped commented Nov 4, 2021

@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
Copy link

jgregmac commented Nov 5, 2021

@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
Copy link

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
Copy link

Who in the world thought it was smart to have

  • A random subnet
  • using probably the most used IP block by enterprises
  • and no ability to configure this behavior?

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
Copy link

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
Copy link

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

  • WSL2 decided on address 172.17.0.0/16
  • it's also default subnet for Docker
  • guess what - DNS resolution is not working in docker containers in WSL2
  • OK I can change docker subnet in daemon.json - but still not sure of what ranges WSL2 will try next
  • Docker in Docker like minikube - I'm f.cked again.

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

@git-rz
Copy link

git-rz commented Sep 15, 2022

I use strategy here, in this comment, to create the blacklist of subnets that WSL2 will not use. It is ugly, but it works.

@YAMLcase
Copy link

My strategy is to play ipconfig roulette. If it hits on a forbidden subnet, REBOOT.

@qwertycody
Copy link

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.

@luxzg
Copy link

luxzg commented Dec 6, 2022

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

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!

@nlvw
Copy link

nlvw commented Feb 14, 2023

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

@luxzg
Copy link

luxzg commented Feb 14, 2023

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

@nlvw
Copy link

nlvw commented Feb 15, 2023

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

@craigloewen-msft
Copy link
Member

craigloewen-msft commented Oct 11, 2023

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.

@joshnatis
Copy link

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

@craigloewen-msft
Copy link
Member

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.

@micheldiemer
Copy link

Other options with recent versions :

@zkorhone
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests