5 ms·

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

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 6y ago
A good reminder that you really want proxying done on a separate device (router, Raspberry Pi, etc) physically between the endpoint and the internet.
- smarx007 6y ago
  1000 times this. See https://mullvad.net/en/help/openwrt-routers-and-mullvad-vpn/ 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.
- vmception 6y ago
  Does anyone have a raspberry pi hardened disk image for this? I just don't have time to troubleshoot all these things anymore
- gerdesj 6y ago
  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 6y ago
    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 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-696234746 https://github.com/microsoft/WSL/issues/4277#issuecomment-69...
    - gerdesj 6y ago
      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.
- m463 6y ago
  exactly. It's amazing how many things bypass on-device firewalls. Docker is a good example.
- fomine3 6y ago
  I like this VPN gateway approach. It feels rock solid.
sneak 6y ago
That’s exactly what leaking means. Traffic that is supposed to be vpn-or-nothing is going out in the clear.
- donor20 6y ago
  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?
  - wasmitnetzen 6y ago
    The firewall probably applied in the non-virtualized WLS1, but doesn't anymore in the new Hyper-V-based WSL2.
  - eptcyka 6y ago
    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.
    - mehrdadn 6y ago
      The host is the hypervisor though isn't it? Not the Windows inside it.
      - apetresc 6y ago
        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.
    - rbanffy 6y ago
      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.
TwoNineFive 6y ago
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/SecurityRecommendations#Tunnel-Shunting 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 6y ago
  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.
  - deleted 6y ago
    [deleted]
dang 6y ago
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 https://news.ycombinator.com/newsguidelines.html

closeparen 6y ago

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

smarx007 6y ago
1000 times this. See https://mullvad.net/en/help/openwrt-routers-and-mullvad-vpn/ 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.
vmception 6y ago
Does anyone have a raspberry pi hardened disk image for this? I just don't have time to troubleshoot all these things anymore
gerdesj 6y ago
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 6y ago
  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 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-696234746 https://github.com/microsoft/WSL/issues/4277#issuecomment-69...
  - gerdesj 6y ago
    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.
m463 6y ago
exactly. It's amazing how many things bypass on-device firewalls. Docker is a good example.
fomine3 6y ago
I like this VPN gateway approach. It feels rock solid.

sneak 6y ago

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

donor20 6y ago
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?
- wasmitnetzen 6y ago
  The firewall probably applied in the non-virtualized WLS1, but doesn't anymore in the new Hyper-V-based WSL2.
- eptcyka 6y ago
  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.
  - mehrdadn 6y ago
    The host is the hypervisor though isn't it? Not the Windows inside it.
    - apetresc 6y ago
      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.
  - rbanffy 6y ago
    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.

TwoNineFive 6y ago

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/SecurityRecommendations#Tunnel-Shunting 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 6y ago
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.
- deleted 6y ago
  [deleted]

dang 6y ago

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 https://news.ycombinator.com/newsguidelines.html