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
Run into some weird errors probably due to my lack of understanding though i think the guide should mention a few more things + be made into an ASCI text file to make a offline copy easy.
There is the need to hvm the new sys-vpn.
and then add the network adapter, ethernet port or wifi adapter internal or external to the sys-vpn
follow the guide
once this is done you can only set firewall rules in the firewall
Please correct me if i am wrong but this is the ony way i could get it to run while traveling with a notebook and random wifi hotspots.
You shouldn’t pass the network interfaces to the VPN qube. The new sys-vpn qube should use sys-firewall as a network source, and then provide network to other qubes.
What you did here is to bypass sys-net by replacing it with sys-vpn.
When reworking the firewall documentation page, I’ve read they recommend to always create a sys-firewall between a net-vm (with a physical network interface, or a VPN) and qubes. Should we update this guide to add the extra firewall qube?
Yes. For full protection (and textbook implementation) there should exist a firewall both before, and after the VPN qube, in case the VPN qube itself gets compromised.
In my opinion, this first firewall, let’s call it sys-fw-pre-vpn, can be a simple clone of sys-firewall, set to use sys-vpn as networking cube.
The other firewall, between sys-vpn and sys-net, let’s call it sys-fw-post-vpn, needs all the hardening that you mention for sys-vpn: icmp and DNS blocking outside the tunnel, and ideally only allowing connections to the VPN provider’s IPs and the VPN ports, depending on what VPN flavor you use (IPSec, wireguard etc.).
Like this:
AppVM (qube where you run the browser, mail reader etc.; net vm: sys-fw-pre-vpn)
↓
sys-fw-pre-vpn (clone of sys-firewall; net vm: sys-vpn)
↓
sys-vpn (any hardening here can be undone if qube is compromised; net vm: sys-fw-post-vpn)
↓
sys-fw-post-vpn (clone of sys-firewall; apply hardening here! ; net vm: sys-net)
↓
sys-net
All the qubes with “vpn” in their names must “provide network[ing]”.
I know I’m mostly “preaching to the choir” but probably this info is worth repeating.
Because I want to apply the hardening only for sys-vpn, not for all the other qubes that may be using sys-firewall. Those qubes need Internet access on other ports than the VPN ports.
What kind of hardening are you using? If you use the Firewall tab for your VPN qube, it will configure rules only for that qube and won’t interfere with other qubes behind that NetVM
I use the normal hardening, as described above in your (excellent) guide in the first post of this thread, and in addition I disable ping as described in @xmpriv 's post and drop any DNS requests (they should go through the vpn tunnel).
Well, what if a vulnerability exists in the VPN implementation, and the sys-vpn qube gets compromised? Then the attacker can change the firewall settings in sys-vpn and have unrestricted access to the Internet.
This is why the hardening and traffic restriction(s) have to be done outside the sys-vpn qube, in the sys-fw-post-vpn qube.
