[Tutorial 4.2&4.1] Mullvad Wireguard with Qubes

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.
1 Like

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

1 Like

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.

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

1 Like

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?

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.
1 Like

Awesome!

So how do I do #1? :grimacing:

I am getting little uneasy here. Now that i booted up my pc and launched the vms forgetting to manually go to the mullvad vpn and launch the vpn, now the app vms happily connected to internet WITHOUT mullvad vpn. Mullvad vpn proxy vms all has the killswitch enabled.

How can i live without being able to trust, sometimes the killswitch seems to work, sometimes it doesn’t work and sometimes the whole proxy vm doesn’t provide internet.

OK I must have been doing it all wrong all the time I think I found out why.

This part

Add DNS hijacking rules

Now we will add firewall rules to redirect DNS requests to 10.64.0.1 (the DNS on the VPN server) for all AppVMs that use the MullvadVPN ProxyVM.

Make sure that you have started an AppVM that has the Networking set to MullvadVPN, otherwise the “vif” IP address will not be visible.

Still in the MullvadVPN Terminal:

  1. To find out your MullvadVPN_local_IP address, run
    ip a | grep eth0

So the problem is, when i type “ip a | grep eth0” in the mullvad vpn terminal, it only gives this:

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group 1 qlen 1000
inet 12.117.0.51/22 scope global eth0

It doesn’t tell me the mullvad address like it should so I can’t get the hijacking rules, maybe this is why the killswitch never works? any help please

Are you using Qubes OS 4.1 or Qubes OS 4.2?

My qubes version is 4.2.

I just tought, that maybe the killswitch problem could’ve been caused because i didn’t have auto start on bootup on the mullvad vpn qube, but nope. It still happily connects without vpn tunnel, even tho the mullvad vpns wireguard is not actually yet manually booted up (shouldn’t have access to internet at this point because of killswitch), the config file has killswitch enabled.

Something weird is going on and I can’t point out what is happening, because sometimes the mullvad setup works normally, (killswitch, internet provide to other qubes and so on) and sometimes it doesn’t work like that, or some parts not work example killswitch or internet provide even if I do the mullvad proxy vm installation exactly the same way from start to finish.

So can someone say am I thinking of the impossible, or should it actually work like this when mullvad vpn has killswitch enabled:

The app vm shouldn’t be able to connect to internet in anyway when it has networking set to → mullvad vpn with killswitch on?

This guide is using iptables instead of nftables so this may cause the problems.
You should apply proper nftables rules in a way that is supported by Qubes OS 4.2.

thanks for reply. this guide worked for me Mullvad VPN App 4.2 setup guide - #8 by frustrated_user

Is there a way to allow/pass traffic to local network IP addresses?