Wireguard looks by default in /etc/wireguard, and if you run the command as you did, it expects you to specify an interface name, like wg-quick up wgvpn0 which will use a configuration file /etc/wireguard/wgvpn0.conf
If you specify a path, then the automatic append of “.conf” does not happen. This is explained in the manual page for wg-quick(8) .
I’m having the same problem on qubes 4.2 with the standard none xfce fedora 38 too.
Update:
I got it to work though I’m unsure of the security implications of the solution I found.
I found when I disable SELinux temporarily in rc.local I can run the wg-quick up command successfully. Then I can also enable SELinux afterword. I’ve added this to my rc.local
setenforce 0
wg-quick up /rw/config/config.conf
setenforce 1
Ugh… selinux is enforcing in 4.2! If you want to avoid the temporary removal of the enforcing selinux state (you don’t know what else is going on at the same time…) you can check the attributes of a file in /etc/wireguard and apply the same to your config file in /rw/something or /home/something.
When I execute:
sudo nano /rw/config/qubes-firewall-user-script
There is a notice that says:
This script is called at AppVM boot if this AppVM has the qubes-firewall
service enabled. It is executed after the empty chains for the Qubes firewall
are created, but before rules for attached qubes are processed and inserted.
How are iptables rules supposed to work then, if there is no mention in the guide to add qubes-firewall service?
Thanks!
The script
/rw/config/rc.local
doesn’t run automatically at boot time. You have to manually run it. Does anyone know how to run this script to automatically start Qubes services (not just for VPN)?
I added network-manager service in the qube setting. Then, from command line I added Wireguard config file using nmcli.
nmcli connection add type wireguard con-name server-wg0 ifname wg0 autoconnect yes
# nmcli connection import type wireguard file my-WG-conf-file
# nmcli connection up my-connection
Now the network manager auto starts after reboot, and the tunnel will be up. Network manager will also add a new icon for the VPN in the top bar.
It should start automatically at boot time. Check it with some test write to log:
echo Test > /var/log/rclocal.log
What about vpndns1? I checked two different wireguard config files and they have different DNS IPs.
You put the DNS server for the tunnel that you wish to use.
how do you go about changing the server once this is done? you can change the proxy location but not the main server you’re connecting to as far as i can tell. So if you get poor speeds through the first server you have to do these steps all over again? Qubes should definitely find a better way to implement privacy VPNs as if you’re running Qubes that’s probably pretty important to you.
If the config file is in /rw, this is not a problem. You can change the IP inside the file and reload the configuration to point to the new server.
Qubes already provides a lot of features that users can use to do whatever they want, including setting up VPNs.
Could you in theory, create multiple “mullvadVPN” Qubes like “MullvadVPN1, MullvadVPN2” etc. with different servers and assing them to different Qubes and just set each net-qube to which server you want for that particular Qube?
Yes, that’s one of the main features of Qubes OS.
Hmmm… why waste 100+ Mb of hdd/ssd/nvme for a few bytes of config? This does not sound like an endorsement for QubesOS!
It would make more sense to have an “endpoint picker” in the same NetVM.
They are applied, but fails as PR-QBS chain is missing.
You can verify that by running sudo /rw/config/qubes-firewall-user-script-iptables as unprivileged user in your VPN qube returning the following error to STDOUT:
iptables: No chain/target/match by that name.
iptables: No chain/target/match by that name.
iptables: No chain/target/match by that name.
Hello -
I’m running Qubes 4.2.
I came to this thread because I noticed wireguard wasnt automatically starting, so I had to add the setenforce 0 and setenforce 1 lines to rc.local.
My next issue is DNS leak. On the MullvadVPN template there is no leak according to mullvad.net/check. The current official instructions on the mullvad website don’t have the part about installing the mullvad browser extension to setup the proxy.
So, it all seems to work now. Just summarizing my experience in case anyone runs into the same problem that I did. Thanks to Pawelek85 for the instructions and fiddler for the workaround.
Questions -
what are the security implications of these work arounds, if any?
Is there still a DNS leak in my Personal VM when using software other than firefox?
If the firewall rules are correct, it should work as expected. You can also add your VPN entry IP address to your VPN qube firewall to make sure that only requests going to the VPN IP can pass through (including DNS requests since they use the VPN tunnel).
You can look there for an example (follow the cli steps if you want more restrictive rules):
Hello. For some reason i’m having hard time getting this command to show the vif address as it should. One time it went good and showed the ip address, but not anymore… Is it safe to use the vpn connection without doing this dns hijacking part?
I mean, does the ip address we are looking for look like this in the terminal after executing command “ip a | grep eth0”
---->
" inet 11.123.0.13/41 "
I’m little confused.