I have been using @unman’s sys-mullvad template. Its had some hiccups, which I have attributed to my clunky hardware, but generally really good.
Recently however, connectivity has really downgraded. Right now I can get no website to download at all, no matter which server I choose. I am getting better responsiveness on Tor.
I know Mullvad have introduced quantum resistance, DAITA, obfuscation and the like which introduces a penalty, but even with that ‘off’, the service is abysmal.
There are so many layers here using Qubes - and I am not technical - I don’t know where to attribute the problem.
I have tried adjusting the MTU, but that old trick isn’t working. (I’m down to 1200).
The problem exists for Firefox, Firefox safe mode and Chromium.
Also - although this may have a separate origin - Reddit has become impossible to read (“You’ve been blocked by network security”) and has repeatedly banned accounts for no reason I can tell except the VPN. I cleared cache and cookies, but I wonder if they’ve fingerprinted my machine.
I can’t use my VPN-connected qubes, which is forcing me to throw away all that privacy-oriented work. It sucks.
Yes, but it’s not as bad on my machine with unman’s sys-mullvad setup (r4.2). I recently upgraded the mullvad-vpn on a different machine (r4.1 with a standalone debian-12-minimal based vm for mullvad) and on that machine the mullvad app will not stay connected for more than a few seconds at a time. It’s completely unusable. It worked fine right up until I upgraded the app from 2024.7 to 2024.8. I tried every vpn server arrangement possible, but to no avail. So it wasn’t DAITA, multi-hop, or even Wireguard vs. Openvpn either. Seems to be correlated with changes related to their recent security audit…
this makes me think you are using a VPN, maybe you are using mullvad over a VPN, which would lead to huge performance loss (nested VPN do not perform great)
I managed to barely maintain a connection on my r4.1 machine by disabling Lockdown mode under VPN settings in the Mullvad app. This was already disabled on my r4.2 machine, but curiously enabling it there did not cause any connection issues, whereas reenabling Lockdown on my r4.1 machine caused the problem again. No idea why the two instances are behaving differently,
I found Reddit quite often (but not always) blocking Mullvad. It doesn’t mean at all something is wrong.
I also noticed a massive difference in speed when using wireguard, these Mullvad servers seem a LOT faster. Since using wireguard I’ve had no issues, before that it was sometimes indeed horribly slow.
I used the community guide by Solene (thanks!) to set this up for 4.2.
This allows you to monitor what people browse on reddit, if you have a really small user base, it can be easy to determine who is reading what. I do not imply that you are doing it, but people show think of consequences of such third party frontend hosted by a stranger who shared them the link
I have publicly provided my entire server configuration on Codeberg since August 9th:
If you notice any opportunities to improve it for myself and other users, simply let me know and I will implement changes. The OVHcloud VPS was originally offered gratis to the Purism community, but I have recently decided to slowly share it with other communities as well, especially within the All around Qubes category.
I’ve had to let the thread go cold, unfortunately, but let me state what’s happening - oddly - on this machine (4.2) now:
I have three sys-mullvad-i...i and ...ii - single hop, different servers, Quantum Resistance on (therefore wireguard servers)
a dispVM (Fedora 40) fails to load mullvad.net in either Firefox or Chromium on each of them. MTU has been adjusted to 1380, then 1300, then 1200, as has worked on other VMs in the past.
another VM loads the page, navigates (slowly) to the payment page, but cannot load the PayPal button (Firefox) on sys-mullvad-i and sys-mullvad-ii (no MTU adjustment).
regular VMs like Personal, etc, are now loading well (on various sys-mullvad qubes), but other days can be jammed dead. Paypal payment completed on one of them.
I’m not technical, but I can’t make heads or tails of this. Its the inconsistency. I’m not willing to accept the idea its down to my old hardware, its not glitchy enough.
I don’t see any nftables rule to adjust the MTU at the VPN qube level, maybe it’s worth trying?
Without changing anything in any app qube, just apply the following command in your VPN qube and try your different tests again:
sudo nft add rule ip qubes custom-forward tcp flags syn / syn,rst tcp option maxseg size set rt mtu