[smarx007]

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.

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

[closeparen]

A good reminder that you really want proxying done on a separate device (router, Raspberry Pi, etc) physically between the endpoint and the internet.

[gerdesj]

This sounds like working as designed and not a flaw. If your Linux box needs a firewall then put one on it. As the article says, the VM is using Hyper-V networking so it is likely that the connection is either bridged with a virty software switch or is NATted in some way but with a short cut through the host firewall. If the VM has an IP on your LAN it is bridged and if it doesn't and you don't have to fiddle with your internet router then NAT is in play.

Linux has lots of options for firewalling. For Windows sysadmins, firewalld with a GUI could be a reasonably familiar option. Failing that, ufw is quick and reasonably easy for simple use cases. If you are feeling macho, then roll your own with iptables or nftables. The last time I did that properly was with ipchains ...

[smarx007]

I think the key idea is that Mullvad client changes firewall config on the fly to insert a 2nd highest prio rule "deny outgoing" allowing outgoing internet access only to itself until the VPN tunnel is established and then withdraws it automatically afterwards. So, a generic firewall advice is not applicable here as it's used in quite a specific way. If Microsoft does not fix the problem described in the blog post, I assume the easiest way would be to introduce some kind of daemon in a Windows client that a slave client tool installed in WSL env would have to connect to or the other way around to mirror a firewall config inside the Linux machine. And that will only work on recent versions, see https://github.com/microsoft/WSL/issues/4212#issue-459183662

UPD: I think it will be resolved in a much neater way soon https://github.com/microsoft/WSL/issues/4277#issuecomment-69...

[gerdesj]

I assume you mean this because I can't find any mention in the article about 2nd highest prio rules:

"How it leaks WSL2 uses Hyper-V virtual networking and therein lies the problem. The Hyper-V Virtual Ethernet Adapter passes traffic to and from guests without letting the host’s firewall inspect the packets in the same way normal packets are inspected. The forwarded (NATed) packets are seen in the lower layers of WFP (OSI layer 2) as Ethernet frames only. This type of leak can happen to any guest running under Windows Sandbox or Docker as well if they are configured to use Hyper-V for networking."

That is how virtual machines are supposed to work. Hyper-V is a virtualisation thing. Whatever Mullvad is doing is immaterial - they are only worrying about the host. If you use full on virty stuff, you need to treat each VM as a VM, not a container.

[vmception]

Does anyone have a raspberry pi hardened disk image for this? I just don't have time to troubleshoot all these things anymore

[smarx007]

1000 times this. See https://mullvad.net/en/help/openwrt-routers-and-mullvad-vpn/ for a relevant guide, see under the "Add a kill switch" for the equivalent functionality.

[fomine3]

I like this VPN gateway approach. It feels rock solid.

[m463]

exactly. It's amazing how many things bypass on-device firewalls. Docker is a good example.

[dang]

We changed the title from "Linux Under Windows Subsystem for Linux 2 Leaks VPN Traffic" to the article's own title. That's in the site guidelines: "Please use the original title, unless it is misleading or linkbait; don't editorialize."

https://news.ycombinator.com/newsguidelines.html

[TwoNineFive]

The title is correct. For example, a remote attacker could induce the transmission of unencrypted packets by taking the tunnel down by means of DoS attack.

Basically, the tunnel doesn't leak under ideal conditions, with non-ideal conditions being trivial to induce.

For example, StrongSwan (IPSec) talks about this in their best practices page here: https://wiki.strongswan.org/projects/strongswan/wiki/Securit...

The StrongSwan process can do some tricks to tell linux to not allow this outbound traffic by creating a kind of dummy/shunt tunnel. Also, iptables should be used to prevent the outbound transmission of non-ipsec traffic to that destination.

It's notable that I had a run-in with this issue a year or so ago with Ubiquiti Edgerouters, which run a fork of Vyatta. They don't allow the "-m policy --pol none --dir out" iptables module to be used in configuration, even though the underlaying linux kernel supports it. They even support it's use in-bound. Pure stupidity, if not malice.

Yes I am a network engineer.

[eptcyka]

If you were to inspect the Mullvad client and how it works on Linux, you'd find that it uses nftables to ensure that traffic only flows through the tunnel. The issue here is that a similar OS provided construct doesn't do that on Windows.

[sneak]

That’s exactly what leaking means. Traffic that is supposed to be vpn-or-nothing is going out in the clear.

[donor20]

Is Windows firewall supposed to apply to WSL? I never expected that! I'm serious - I run a different firewall on my onlinux.

Can you confirm that WSL is supposed to be dealing with (the nightmare) of the windows firewall for internet access? How does fedora / ubuntu etc coordinate / know to do this?

[eptcyka]

It's somewhat unintuitive that a virtualized guest can circumvent the host's firewall/network stack when the guest doesn't have an explicitly bridged or passthrough'd physical adapter.

[rbanffy]

It's not circumventing. It exists outside it.

As for the parent, if it's a Microsoft product running on Windows and Windows has a firewall, I'd expect it to be an effective firewall, at least for the things Microsoft gives me.

[numpad0]

Windows while Hyper-V is enabled runs atop Hyper-V VMM as a VM, same ways as Linux running as Xen Dom0.

WSL2 uses Hyper-V, so Windows running WSL2 is running on Hyper-V, not bare metal. Being a different VM than Windows “Dom0”, Linux Kernel in WSL2 would have direct connection to Hyper-V virtual ethernet switch. I think that’s what is happening.

[mehrdadn]

The host is the hypervisor though isn't it? Not the Windows inside it.

[apetresc]

Exactly this. If you're running WSL2 then you're in Hyper-V mode, which means Windows itself is also running virtualized. The WSL VM is a sibling of Windows on the hypervisor stack, not hosted inside of.

[wasmitnetzen]

The firewall probably applied in the non-virtualized WLS1, but doesn't anymore in the new Hyper-V-based WSL2.

[dymax78]

No one is disputing the definition of "leak(ing)" rather what traffic is being leaked, which is not VPN traffic as the title suggests and the Mullvad link clearly explains. edit: the title has since been modified.