Best idiot-proof-guide for VPNs that will work on 4.3?

[stumpi]

so I have been using Qubes for many years now, but find that I am quite dependent on the community for a few things, though I am able to resolve a ton more than i could 8 years ago. Regardless, getting sys-vpns to work has been a bane of my Qubes using existence since the beginning. Between trying to figure out which one i should use, to actually following the guides (many seem sufficiently detailed), to posting and trying to get help on what I am doing wrong - its been a real pain. I am not in much of a position to make demands but it just seems like it could be incorporated into the setup process or a script that could be included in dom0 like create-vpn -ovpn open_vpn_file.opvm -u vpn service user name -p vpn password… I’m going to go out on a limb and assume its not that easy as no one has done it yet (I certainly have no clue how to do it).

I assumed after this upgrade (from 4.2 → 4.3) I should probably use this guide but haven’t gotten that to work and was thinking i’d try this one since i use proton but no, couldn’t get either to work. Other vpn-for-Qubes-for-dummies recommendations are welcome.

[parulin]

Follow only parts of this guide from @solene: Wireguard VPN setup (4.2 and 4.3)

By parts I mean: everything except Set the firewall to the VPN endpoint (this avoids leaks) until Some websites aren’t working. You will have a working VPN that might leak. Wireguard is supported by NetworkManager and provides a graphical interface so it’s your best choice.

If you want to help build such a guide, provide detailed feedback.

Ignore any guide using minimal templates.

[tommy]

If you worry about leaks and errors with config files, firewall etc, just install a GUI version, for example the Mullvad Gui in your template (or dedicated template). Create a dmv based on that tenplate, for example sys-vpn-dvm.

In sys-vpn-dvm, do: (So your vpn account stays saved)

sudo mkdir -p /rw/config/qubes-bind-dirs.d
echo "binds+=( '/etc/mullvad-vpn' )" | sudo tee /rw/config/qubes-bind-dirs.d/50_user.conf
echo "binds+=( '/var/lib/mullvad-daemon' )" | sudo tee -a /rw/config/qubes-bind-dirs.d/50_user.conf

Enable firewall, lockdown mode, vpn connection type etc by opening the Gui in sys-vpn-dvm

And now all you need to do is to create a Named Disposable, sys-vpn, and enable providing network. This setup gives you the option to enable firewall, kill switch etc, in sys-vpn-dvm. So you are sure everything is configured well by the GUI itself without risking leaks.

[stumpi]

Thank you @parulin and @tommy , i will try that.

Parulin’s minimal templates quote could be part of my problem (though I’ve gotten it to work in the past) in that if the guide allows, i usually try to use a minimal template.

[parulin]

Last time I tried this, it was not that simple: Mullvad VPN App 4.3 (and 4.2) setup guide

[tommy]

Yes, that’s why i recommend to use the Mullvad GUI solution, especially for people who are not so technically. And you have oversight, every time sys-vpn starts, you can set that the tray icon starts and manage and check your connections easily.

[parulin]

Same thing for the last guide I linked, I’m referring to the Fix DNS section.

[longTimeQubesUser]

My guide is the most idiot-proof, just follow the steps

https://forum.qubes-os.org/t/how-to-make-an-openvpn-gateway-in-qubes-4-2-4-3/

[FranklyFlawless]

Assuming Debian, not Kicksecure:

netVM/proxyVM openvpn gateway with kicksecure-18 template does not work

I used this tutorial to create a NetVM using the Kicksecure-18 template, following the installations and configurations exactly as described in the tutorial: I followed the tutorial, but instead of using the Debian Minimal template, I used debian-13-xfce. I cloned it and carried out all the configurations and installations described in the tutorial. It worked perfectly—OpenVPN worked flawlessly as a NetVM! However, I did the same thing with Kicksecure by cloning kicksecure-18 and following …

[James369]

I would love it if MirageVPN worked well for this with ovpn config files. It would be perrrrrfect!

[FullVINQubes]

A simple way to make the existing guides less intimidating is to validate one layer at a time:

1. In the VPN qube, confirm the tunnel interface comes up and that the endpoint is reachable.
2. 2. From a disposable client qube, check that the default route points to the VPN qube, not directly to the NetVM.
   3. 3. Make the VPN qube default-deny traffic that is not going through the tunnel, then test a disconnect and reconnect.
      4. 4. Check DNS and IPv6 from the client qube, including after the tunnel is restarted.
         5. 5. Reboot once and repeat the checks. A setup that works only after manually starting services is not really finished.
         6. Also watch the AllowedIPs and firewall rules when copying configs. Full-tunnel settings are convenient, but LAN or local-service exceptions need to be intentional so they do not create an accidental clearnet path.