[Tutorial 4.2&4.1] Mullvad Wireguard with Qubes

[sigma]

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!

[apparatus]

When to select 'qubes-firewall' in services tab

Yes, it is. qubes-firewall is the firewall manager, which takes settings from the firewall tab in qube manager, or qvm-firewall. It is enabled in netvms, but not in sys-net. You can check this with systemctl status qubes-firewall You don’t need to use the Services tab for this - as it says on that tab, “Unlisted services will follow default settings” and the default for a qube that provides network is for the service to be enabled. I never presume to speak for the Qubes team. When I …

[Eli]

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.

[apparatus]

@Eli

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)?

It should start automatically at boot time. Check it with some test write to log:

echo Test > /var/log/rclocal.log

[sigma]

@Pawelek85

**# replace 10.137.0.47 with the IP address of your vif* interface**
virtualif=10.137.0.47
vpndns1=10.64.0.1

@Pawelek85

4.Only Replace* 10.137.0.47
with your own MullvadVPN_local_IP IP address:

What about vpndns1? I checked two different wireguard config files and they have different DNS IPs.

[Eli]

You put the DNS server for the tunnel that you wish to use.

[Raist]

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.

[DVM]

@Raist

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?

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.

@Raist

Qubes should definitely find a better way to implement privacy VPNs as if you’re running Qubes that’s probably pretty important to you.

Qubes already provides a lot of features that users can use to do whatever they want, including setting up VPNs.

[Raist]

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?

[DVM]

Yes, that’s one of the main features of Qubes OS.

[barto]

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.

[cu3bz0r]

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.

[qubes-neurotic]

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?

[DVM]

@qubes-neurotic

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):

Wireguard VPN setup

Good news, with fedora-38 the network manager supports Wireguard out of the box! The only thing required are extra firewall rules in the VPN qube, as explained in the community documentation about VPN. What you’ll need This guide assumes you are using a VPN service that has wireguard support, most of them do, but you can also add your own if you have a server. ProtonVPN has a free plan, it has limits but gives you a fully working VPN and they support WireGuard. This pro…

[qubehead38]

@Pawelek85

ip a | grep eth0

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?

[qubehead38]

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.

[apparatus]

Yes. The address should be 10.137.x.x/32 or 10.138.x.x/32.

[qubes-neurotic]

Hi - is there a way to get this configured so that AppVMs that use the MullvadVPN qube can also still access IPs on the local network?

[unman]

You will need to change the firewall rules in the MullvadVPN qube to:

1. Change rule to stop forwarding traffic bound for the local network to localhost
2. Enable traffic from qubes to be forwarded to addresses on the local network

Not too difficult.

I never presume to speak for the Qubes team. When I comment in the Forum I speak for myself.

[qubes-neurotic]

Awesome!

So how do I do #1?