Automatically disable/remove 'vEthernet (WSL)' from Windows Firewall Defender under all circumstances

Nobody has claimed this yet.

Running web services under WSL2 for connection from windows locally breaks when some IT person sets a domain group policy rule that 'all interfaces MUST have windows firewall enabled, and must default to block'.

This does not break the above for WSL1, only WSL2: This is a bug for WSL2.

This appears to be one of the causes of some network operability issues specific to WSL2 and not WSL1.

**Describe the solution you'd like**

The 'vEthernet (WSL)' adaptor, which connects WSL2 to the Windows kernel, should be by default not be considered an adaptor for the purposes of windows firewall. Setting it to be considered as such should be an advanced configuration, similar to setting up a firewall for the loopback adaptor in unix - somewhat nonsensical, but apparently often mis-configured by common 'secure' blanket policies.

It is generally desirable also that network communications for WSL2 perform as well as possible, and since these are essentially co-kernels, the interface between them should not have a firewall which only adds latency and an unnecessary additional point of failure. It's like running all local IPC though the windows defender firewall.

WSL2 should be different in this way compared to any other HyperV VM, where such isolation is a potentially useful feature. Similar isolation can be obtained by nesting a VM within the WSL2 side anyway.

**Describe alternatives you've considered**

- downgrade to WSL1, losing substantial performance, or
- have the network group policy add a specific configuration rule, to work around the problem, or
- install unverified third party software from the internet to automatically open and proxy ports between the two kernels, from one side or the other.
- manually re-add a new v4tov4 rule every time WSL2 restarts, because the IP address keeps changing

**Additional context**
- from solution suggested of just 'disabling the windows firewall' for the adaptor, which cannot be done due to domain group policy overriding all local policy.

No source file, test, or implementation entry point is identified. Start by investigating how WSL2 creates and configures the “vEthernet (WSL)” adapter and how Windows Defender Firewall policies affect it, comparing the behavior with WSL1 and other Hyper-V guests. Done would require an agreed, policy-compatible design and validation that local WSL2 web-service connectivity survives the stated firewall configuration.

Written by the indexing model from the issue text.