Wireguard VPN setup

Is this guide suitable for Fedora 40?

Yes, I updated the guide to make this clearer

2 Likes

Just spent more time than willing to admit I finally got it working by adding sudo to the front of both commands… sigh. I guess you could change the file permissions as well. Hopefully this works for you too

Add this code to /rw/config/rc.local

RANDOM_VPN=$(sudo nmcli connection show | awk '/wireguard/ { print $1 }' | sort -R | head -n 1)
sudo nmcli connection up "$RANDOM_VPN"
1 Like

I am currently trying to set up a VPN Qube here on QubeOS and have followed your kind guide on here but i have got to a place where im stuck and would love a little help please as on Qubes the IP addresses are most confuse to me.

Anyways i have set up a new Qube and granted it Network to sys-firewall and added Network manager in Services already yet during Mullvad Wireguard setup it states on advanced an option to click ENABLE KILL SWITCH yet if i click that then it wants to know; Allow local network access with kill switch
Select a local network to allow
then theres a drop down list of different IP addressed pre-loaded yet idk which one to choose, the options are;
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
or im i just not suppose to alter anything at all thus Not click the Kill Switch option? :flushed:

those are only local area network IP, you can safely allow them.

how does one know that, how do you know that, how can i know that without needing to ask you please?

Will or can those IP addresses change on me one day and i need to re-edit or add more or anything like that or will i keep those forever even if i change my router or restore a Qubes Backup or such like?

I have networking skills. Not sure at which point someone need to learn that when using a computer daily :woman_shrugging: maybe there is some documentation about it on Mullvad website.

no, this was defined a long time ago and will never change (the Internet would break :joy: ).

Actually, thinking about it, you should try to not allow these networks and see if the VPN still work, if so, don’t check it, it’s useless on qubes os. It may be needed for the VPN to work because Qubes OS internal network uses the network 10.0.0.0/8 but if the Mullvad App is smart, it should add an exception for the IP providing the network, so you would not have to allow all the 10.0.0.0/8 range.

So, TLDR

  • try to disable the “allow setting”, see if it works, this will change nothing for a Qubes OS user.

it is not the app, its the config file im downloading, does this change things?

I didn’t use mullvad much, but I don’t think you need the killswitch integrated in the configuration file, if you use configuration files, you will be able to easily implement a 100% reliable killswitch using qubes os firewall, so don’t bother.

1 Like

Should i C&P the commands exactly as you gave in dom0 Terminal or the sys-vpn qube Terminal and should i be editing any of those commands to suit my specific .config or are the commands universal regardless of anyones .config file they downloaded.

idk what a 3liner means, does that mean C&P all 3lines of commands as a oner into dom0 Terminal?

Im just guessing my dsthost is the same as the one stated 1.2.3.4 # (2)
Also by using those commands for the kill switch will it mess with anyother setup as i will not be using the sys-vpn qube all the time for my internet, i only want it set up for the odd time i ever go out and need it as i normally just use a VPN Router on hardwire direct to the computer for example when at home?

Sorry for all the questions im just a lot scared of messing everything up :flushed:

Thanks @solene @deeplow and others for this thread.

Using debian 12, I have several dozen wireguard config files I want to import. As @isolator notes, in debian it must be done as root, and must be set to not autoconnect once added to avoid problems. So, with this line, I’ve successfully added one profile with autoconnect disabled and disconnected:

sudo nmcli connection import type wireguard file fileName.conf && sudo nmcli connection modify fileName autoconnect no && sudo nmcli con down fileName

Does anyone have a script that could read the contents of a folder and run this command for every conf file in it?

Similarly, could the same be done to add all servers to the VM’s firewall rules?

Edit: expanded the command to also disconnect the newly imported profile.

a for loop

Thanks, I’ll try to put one together and post it when it works.

Edit:
With this script I successfully imported and configured dozens of profiles. My first bash script.

#!/bin/bash
#For Debian.
#Save in the same folder as the vpn.conf files and run from a root terminal.
for file in ; do
c="${file%.
}"
sudo nmcli connection import type wireguard file $file && sudo nmcli connection modify $c autoconnect no && sudo nmcli con down $c
done

Now for one to modify the firewall rules, unless someone already has one.

1 Like

Thanks for the guide!

I am having a hard time following the guide because of two reasons:

  1. Does this step “Use the Qube GUI to set the firewall to the VPN endpoint (this avoids leaks)” and this step “Block all traffic outside VPN using command line Qubes OS Firewall” compliment each other or do I need to use one or another? Because when I enter the command qvm-firewall sys-vpn reset obviously this resets the previous steps configuration, right? So if I had to choose one or another, which one should I choose?

  2. I am trying to create a Wireguard VPN Qube for my homelab, I am using DDNS as I do not have a static IP address. Will the firewall work in the case if I enter dsthost=myddnsaddress.com ?

one happens with the qube firewall, while the other happens on Qubes OS firewall infrastructure, the rule is applied to the qube’s netvm and can’t be altered from the qube itself.

The first one, within the qube is rather practical if you do not know in advance the IPs and ports you will use with your VPN client, typically using a VPN app from the provider and you want to change the ports.

The second firewall rule is better as it can’t be bypassed by the qube, even as root, but you need to know at least the destination port (and ideally the IP if you want to tighten).

yes, it’s resolved at some step, maybe when the qube’s netvm is starting and then it won’t change until I don’t know when… maybe when the qube restart or the firewall is modified. It may be written somewhere in the documentation.

2 Likes

So in my case, I would prefer the solution with qvm-firewall but where are these rules are written down? If I want to revert them back or simply delete them, is there a config file somewhere in dom0?

What exactly does this do?:

nft add rule ip qubes custom-forward tcp flags syn / syn,rst tcp option maxseg size set rt mtu

I just manully add :
ip link set dev eth0 mtu 1280

What’s better here? (I am using qubes-vpn-support)

Excellent work, Solene + Community! I have set up several sys-vpns using the Mullvad WireGuard guide in Qubes 4.1 and this is a dream compared to that!

Question 1)

What exactly does the MTU fix do? What will the packet size be?

That the fix is required is correct, I am still confused about it, but I figured it out a long time ago. Interestingly, DuckDuckGo was also one of the broken sites.

I used this approach:

cat >> /rw/config/rc.local <<-'EOF'
	# Set MTU to 1280
  ip link set dev eth0 mtu 1280
EOF

Any comments/thoughts on which approach is better?

Question 2)

Is any hardening required if I set the qvm-firewall rule to only allow traffic to the VPN endpoint? I am mainly asking about the killswitch configuration.

I know it says optional, but what is the real benefit here?

Also, isn’t setting up a custom DNS server counterproductive in most cases? Shouldn’t it be recommended to use the VPN endpoint (which usually handles DNS), or at least a DNS server from the same VPN provider? Mullvad, for example, has public DNS servers.

the option in iptables was named “mss clamp”, you can see what it does: linux - How iptables "--clamp-mss-to-pmtu" calculates PMTU? - Super User and TCP MSS Clamping in Firewalld | firewalld

IMO it’s better than lowering the MTU.

2 Likes

qvm-firewall rules can’t be bypassed, so you are fine doing it. It’s optional because as I explained just above, it’s not “app friendly” if you want to easily change hostname / port / protocol.