The people in charge of Mullvad VPN announced yesterday in their blog that they had discovered a security problem in Windows 10; or, more specifically, in the most recent version of the Windows subsystem for Linux (WSL2), whose connections, it seems, circumvent the native Windows 10 firewall (and with it, any rule we may have configured in it).
Their product includes an option that uses the firewall to block any Internet access unless connected to the VPN, but a user let them know that even when their VPN was disabled, their Linux over WSL2 installation was still connecting to the Internet without any problem (although, when a VPN tunnel was active, WSL2 traffic was also redirected through it without any problem).
They later did the same check with other competing VPNs, with the same result. But why is this, and why does it not affect the first version of WSL?
The problem is that WSL2 has a real kernel
Very simple: WSL 1 did not use a real Linux kernel, but an adaptation that translated the calls to the Linux system to calls to the Windows 10 NT kernel… but when WSL 2 arrived, it switched to using a real Linux kernel that runs on a Hyper-V virtual machine, with its corresponding virtual network adapter.
And it is this last element that generates that the connections originated from WSL2 are kept out of the Windows security layers.
Since the goal of WSL2 was to function as a standalone operating system as much as possible, it makes sense for it to work this way… but it also requires that users be aware of this change in behavior and know how to secure their connections from the subsystem.
The good news is that this allows the use of Linux’s own firewalls, such as the famous and ancient Iptables or the more modern Nftables, to control network traffic.
Regarding the possibility of reproducing the behavior of WSL1 in terms of VPN use, those responsible for Mullvad VPN say they are still investigating whether it would be possible to block unwanted traffic on virtual Hyper-V adapters.