But it should definitely be well publicised/documented, because otherwise people won't realise they have a gaping hole in their greens m defences.
Granted, I don't know much about WSL, but that's a very surprising model to me. I would naively assume that anything in userspace is controlled by the Windows OS-level firewall, not that Linux gets to emit raw packets. To say the least, I'm a little more hesitant than you are to call that reasonable.
These VPN authors are just idiots - let's stop over complicating things. Half the time people LIKE that they can use linux firewall features on their linux hosts for stuff.
Maybe work on your reading comprehension?
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.)
QubesOS provides another VM as a dedicated firewall just to route untrusted guests' traffic through, first. With enough cores, it all runs fast.
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.
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.)
It all works astonishingly well.
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.
I know of people who run Windows 10 in a Qubes VM. It is dizzying to think of what they are really doing: running a Hyper-V system, with its own VMs, in a VM on a Xen hypervisor.
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).
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 ...
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.
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?
It's the only way they can reliably prevent abuse like a thousand people using one number - because this way you can just track the number of open connections per account number.
This is superior to tracking IP-addresses to detect fraud for obvious privacy reasons. I do a similar thing for a service I run.
Out of curiosity, how do you even manage to use more than five devices for private use at once? Even just owning that many is unlikely.
I expect the distributions on WSL to use their own firewall - that's half of the fun of using WSL.
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!
I think the question is whether you consider a VM more like another machine in your network that merely happens to run on the same hardware or a part of the host system.
Personally I really liked the resource efficient WSL1 approach and I lament that they dropped it. But I know for some usecases (e.g. docker) a real Linux kernel was needed.
I don't think users of NordVPN, ExpressVPN, MullvadVPN et al. are as sophisticated as you think.
Using WSL2 though... you kind of have to be tech savvy to do use it, and those people are probably willing to work around the issue.
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.
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.
WSL2 is basically a VM and any VM which binds directly to the Adapter (e.g. not NAT mode) will have the same behaviour. In some cases you'd even want it to do this.
WSL2's NAT is close to a standard Hyper-V NAT adapter but there's unexpected differences (like the localhost binding) that make it stand out.
It's tunnels, all the way down :-)
Currently, I run Linux on a Xen domU and configure VPN client inside the guest.
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).
I used to run Linux VM inside HyperV before WSL2 released, and it worked like a charm. WSL2 just adds a lot of hacks to integrate Windows & Linux experience.
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.
I think a better solution would be to explore creating a VPN solution for HyperV OS itself if possible...
I think that’s a bit different than this, though it’s possibly related. As you said, the situation there is traffic is blocked.
WSL and WSL2 are fundamentally different in how they work. In fact, the poor I/O performance (caused in part by Windows Defender) in WSL is part of what led to the Hyper-V based approach to begin with.
My guess is that something might need to change either in the way VPNs use the firewall rules in Windows when passing on to WSL2 or in WSL2 to make for more granular control over how that stuff is passed on - to address the Mullvad. Because as it stands now, the way Mullvad performs under WSL2 seems to be by design (by WSL2 design, if not Mullvad’s design).
Obviously, many users who enable a VPN in Windows will want that connection to persist when they use WSL2 — but I can also think of plenty of scenarios where that might not be the case, which I imagine makes coming up with a solution more difficult.
I will say, the WSL2 team is incredibly responsive to feedback. You can file issues on GitHub and the team is very active on Twitter. If this is something that can be fixed on the WSL2 side, I feel confident the team will work to do it.
Not what's happening here (despite the title).
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.
[1] https://twitter.com/richturn_ms/status/1270766764356366336
It does something similar on Linux, actually. Huge pain when trying to firewall servers only to discover that Docker happily bypasses all of your rules.
Pretty much sums it up.
How's the display scaling these days? Is it still a better experience to run a 4k monitor at a lower resolution? What's the Nvidia driver situation? Still janky because their drivers are doing their own thing?
Except Spotify, that needs a command line flag to set the scale factor, but that app is well known to be half-assed on Linux (they also don't support input methods, so searching for Japanese songs is a copy and paste exercise) and that's not Linux's fault.
AIUI the nvidia drivers are a lot better these days, but most Linux users, myself included, know to stay away from nvidia unless you have very good reasons not to. AMD cards work beautifully.
I think there are great desktop environments and window managers for Linux.
Linux users don't use Nvidia if they are interested in the modern desktop use case. That's a well known factor. If someone migrates to Linux using Nvidia, chances are high they'll change it to AMD on the next GPU upgrade.
