So, if I'm understanding correctly the Linux system gets access to the raw Ethernet system, and so bypasses the Windows firewall. Seems not entirely unreasonable - if you want Linux to use a firewall then install one into it.<p>But it should definitely be well publicised/documented, because otherwise people won't realise they have a gaping hole in their greens m defences.
For reference, this kind of problem is avoided on QubesOS (another, Xen-based, hypervisor system) by routing all traffic through another VM that entirely owns the network hardware. I run my Wireguard on that VM.<p>The host OS image, dom0, also routes its network traffic through that VM, to get updates. (It doesn't trust the updates it gets that way; it checks their signatures.)<p>QubesOS provides another VM as a dedicated firewall just to route untrusted guests' traffic through, first. With enough cores, it all runs fast.<p>For many users, all guest VMs are untrusted. Dodgy programs like browsers get their own VMs, spun up as needed and discarded. That does take a fair bit of RAM; my maxed-out 16GB laptop notices the strain. But memory is cheap these days, if you have the sockets to put it in.<p>As an aside, dom0 also mediates access to the UI hardware, including display RAM. Each guest can run X, but its pixels are copied to the real display by dom0. Guest VMs can't see one another's pixels or input traffic. dom0 also mediates access to audio and video streams, and can route them to selected VMs as needed. (In a future release they plan to manage the display in its own VM, because display drivers are a big attack surface of their own.)<p>It all works astonishingly well.<p>Incidentally, this model of a hypervisor with all the user-level OSes as VMs, including the host, originated at IBM in the 1960s. That worked in a megabyte or two, which seemed like a lot at the time.
The title is wrong. The VPN traffic does NOT leak. What leaks is the traffic that the VPN software tries to block when the VPN connection is not active. Mullvad uses Windows Firewall to block all internet access if VPN is not active (if the user configured so) and WSL2 bypasses this by not going through Windows Firewall. When the VPN is active, WSL2 traffic IS tunneled through the VPN.<p>UPD: The solution may be to have Windows Firewall rules apply to WSL2 or have Mullvad control Linux internet access through on-the-fly UFW settings update or completely disconnect internet (but that likely does not work nicely and is why Mullvad went for the Windows Firewall based solution in the first place).
A bit off topic, but this sort of transparency is why I don't mind paying $6 / mo for a vpn when mullvad's competitors are much cheaper. Their wireguard support is great, and their speeds are much faster than what I got through openVpn on pia.
The idea of the a linux distribution is going to be using the WINDOWS firewall?? seems a bit crazy to me.<p>I expect the distributions on WSL to use their own firewall - that's half of the fun of using WSL.<p>PLEASE don't push fake news like this that results in distribution on WSL having to deal with / modify the window firewall - that would be a total nightmare!
We have tested a few other VPN clients from competitors and found that all of them leak in the same way. The way Microsoft has implemented virtual networking for Linux guests makes it very difficult to properly secure them.
Potential workaround: is it possible to configure VPN clients to _ignore_ the WSL2 runtime and instead run a VPN client inside WSL2?<p>That way the Linux network config can deal with the Linux side of things and the Windows network config can deal with the Windows VPN routing.<p>Of course you can just configure OpenVPN inside WSL2 and also run a VPN on the desktop but that's tunnels in tunnels and that way madness and network issues lies.
This is the exact reason I didn't try running weird VPN configs like this. The reliable way is to run Linux inside a VirtualBox and have it connected to VPN on its own.<p>Currently, I run Linux on a Xen domU and configure VPN client inside the guest.<p>PS: I don't want all my traffic to go through VPN. Especially things like Netflix or Youtube where VPNs are blocked (and VPN BW is lower anyway).
Let me get this right: Installing WSL2 causes HyperV to be installed. When Hyper-V is installed, HyperV replaces Windows as the Machine Host. Therefore Windows itself becomes a guest OS of Hyper-V, and the installed Linux also becomes a guest of HyperV.<p>So what mullvad would prefer is that Linux traffic to be routed through the adjacent Windows Guest by default, so that the windows software can control the Linux network traffic.<p>I think a better solution would be to explore creating a VPN solution for HyperV OS itself if possible...
If you run your VPN tunnel on the same machine that is emitting your super-serious must-be-tunneled traffic, you are always just one configuration mishap or even software exploit (if you happen to be a Firefox Tor browser user) away from revealing your real connection.
I have noticed similar simply because the Cisco AnyConnect client doesn't work with WSL2 and is a known issue [0]. But that seemed to be blocking traffic instead of just allowing all traffic over non-VPN. However, openconnect does work fine as does the UWP-based AnyConnect client. I wonder how those latter two are successful tunneling traffic (or if it's only if they are started before the wsl2 vm is).<p>0 - <a href="https://github.com/microsoft/WSL/issues/4277" rel="nofollow">https://github.com/microsoft/WSL/issues/4277</a>
This is due to Hyper-V, which is being rolled out on Windows 10 and required for WSL2. The OS is now running as a VM, and virtualized programs like WSL2 are running alongside - these VMs can't control each other's traffic. It's interesting that a feature meant to improve sandboxing actually makes firewalling and VPN more difficult, in its current state. I think the the proper fix is at the Hyper-V level, which might need to explicitly manage firewall and VPN features.
Docker on Windows can run on WSL2 backend as well. So I assume this would also apply to Docker traffic too.<p>Other interesting note, Docker Windows does some funky stuff with firewalls too. It puts and any/any exception in the firewall when you install it [1]. So may also be important to know with VPN stuff.<p>[1] <a href="https://twitter.com/richturn_ms/status/1270766764356366336" rel="nofollow">https://twitter.com/richturn_ms/status/1270766764356366336</a>
Related issue with some workarounds that people are reporting various levels of success with: <a href="https://github.com/microsoft/WSL/issues/5068" rel="nofollow">https://github.com/microsoft/WSL/issues/5068</a>
Strange then that the WSL2 guest gets a RFC1918 private address, because that would imply that the host is NATing traffic to and from the guest. However that does not happen through the ordinary Hyper-V NAT routing machinery -- at least Get-NetNat shows nothing in Powershell and in fact multiple people have reported broken WSL2 networking because they had leftover NAT rules from old Hyper-V VM's. It would help to have some conceptual documentation here about what WSL2 is doing.
A little bit off-topic, but I have a problem with WSL2 and Wireguard for Windows. When I enable Wireguard for Windows, WSL2's default DNS server will stop working, but directly setting dns server to 8.8.8.8, 1.1.1.1 or something similar works.
I can’t re-create the issue with the mullvad client, or on my work-issued laptop with the Cisco Any-Connect VPN. Everything is dropped the second the VPN goes up.