> windows firewall rules should not in any case be applied to traffic coming from a VM

I can't agree with this. Everything is running on Windows. The VM runs on Windows and WSL exchanges data with Windows all the time. That the data on the Windows side can leak because I installed a Microsoft-approved product from the Microsoft store on a Windows box with a Microsoft firewall is unacceptable.

Here’s the issue with your issue: if you are using WSL2 (or other various win10 configurations involving hyper-v), then windows is not running on bare metal anymore. In this scenario, windows is just another guest operating system subject to a hypervisor. Windows is a VM, and your in-VM firewall applies to the VM in which its running.

This is how you get real linux “on” windows - the on part is an illusion, trickery to make using linux transparent and integrated. By comparison, WSL1, which is still supported, is “just” (it’s actually pretty impressive in its own right) syscalls translated to the NT kernel.

Microsoft could do a better job communicating this, but I don’t think any of their design decisions are bad in this regard.

In which case it sounds like the Windows tools for configuring things should configure HyperV's networking too.

You know, just like the software inside the Windows VM can launch a separate Linux VM; you're already controlling HyperV from inside that VM.

So this is also an issue (by which I mean something to be aware of, that I think most aren't) with Linux docker containers on Windows/macOS?

It makes perfect sense now you say it - I knew hyper-v was a hypervisor, I knew in basic broad strokes what a hypervisor is and where it sits, but for some reason this didn't occur to me.

It could be very alarming to people running containers 'on a Windows' server, but then such people are probably more familiar with hypervisors anyway.

Is hyper-v networking still somehow configurable from the 'host', or is it undesirable for containers unless you don't want to do anything to the network (in software on that machine)?

So WSL1 is reverse wine basically?

Nope, WSL 1 uses pico processes, a technology based on Drawbridge research.

https://www.microsoft.com/en-us/research/project/drawbridge/

https://docs.microsoft.com/en-us/archive/blogs/wsl/windows-s...

https://channel9.msdn.com/Blogs/Seth-Juarez/Windows-Subsyste...

It is a bit more advanced than Wine, with first class support from NT kernel.

Whereas WSL 2 uses Hyper-V, which is a type 1 hypervisor, all OSes run as guest, including Windows itself.

Not _exactly_, but it's a pretty close analogy. Certainly moreso than WSL2 is.

As far as I know this is how Hyper-V worked since at least Windows 8(.1?). Installing the role would relegate the Windows OS to guest VM status, albeit with more privileges than any other VM.

Microsoft should make it more obvious since most Windows 10 users shouldn't be expected to make this distinction by themselves.

> Everything is running on Windows. The VM runs on Windows

As far as I understand, that is not quite right. With WSL2, everything is running on Hyper-V, the VM and Windows both run in parallel on Hyper-V.

Wow! Just installing WSL-2 makes such a fundamental change to how Windows itself runs?

Enabling hyper-v does.