It’s ok to make mistakes, just make sure to learn from it, and clean the mess
Because you made a mistake? This is ridiculous. People make mistakes, you can’t make mistakes if you don’t have the opportunity, but if you make mistakes, you learn, you get experiences, and you can do better next time, and teach people how to not make the same mistakes as you.
Except if you don’t want to edit documentation anymore, in which case it would make sense.
I can see the history of changes on the topic, it seems some changes don’t make sense, like the addition of
Maybe instead of show up
will be available to be started from
upper left Q / Services.
``
is it what you are apologizing for?
Yes. That is what I added.
Sorry I could not re edit it. I guess someone realized I should not have been allowed to edit and removed my permission.
I had already created a sys-mullvad Qube and tried to install the Mullvad GUI app. Which caused me to have a different response than what your documentation shows.
In the community guides section we aim to have things as editable wikis. So anyone can edit and contribute. If someone messes something up (either on purpose or by mistake) we can always revert that
So no problem. We learn by mistake as @solene is saying.
Hello Solene, thank you for this amazing guide it’s working flawlessly for me. Just a few questions.
Has there been any extensive (or nonextensive) leak tests done to make sure that these iptables rules are sufficient enough to prevent a vpn leak? Of course using the Qubes GUI to set the firewall to the VPN end point is one way to do this however, it would be nice if the vpn setup was leakproof without relying on the Qubes Firewall. I am a user that always sets the Qubes Firewall to limit outgoing connections to the wireguard vpn end point, however in a case such as a bug in the firewall, I would feel much safer if the iptables rules and network manager would also fail safe by default. Two layers of protection rather than one sort of thing… Also network manager does not fail safe by default which is why I want to make sure that these iptables rules are sufficient enough. Perhaps there is additional hardening that could be done that hasn’t been mentioned in this guide? Or many other users who have tried this vpn setup and are coming across my comment have some insight?
Also I am interested to know if you or anybody else will carry this guide onto Qubes 4.2 where we will be moving to nftables by default. (I am hoping you will do so)
Again, thank you so much for this guide. It’s working very well, just wanted to discuss the aspects of failsafe regarding this setup.
Regarding leaks, I haven’t done extensive testing either. It may leak ICMP packets (pings) if the advanced part is skipped. This is because the Qubes GUI firewall by default leaks those.
It would be nice to have it updated indeed. We also welcome contributions by anyone. So if you get it working, feel free to improve it.
Starting in Fedora 29 39 networkmanager-applet will have the ability to add wireguard connections via the UI. So the guide may be updated too to remove the command line for that
