Wireguard DNS does not work in the Qubes AppVMs -> ProxyVM with the official Mullvad client

[TommyTran732]

Hi,

Before we start, I want to make it clear that I am aware of https://mullvad.net/en/help/wireguard-on-qubes-os/. However, this is not the setup I am using, since setting up a firewall with it is quite cumbersome. I am trying to set up Mullvad with the official client instead.

Steps to reproduce:

1. Make a standalone Fedora 36 VM on Qubes. Set networking to use sys-firewall. Name this VM sys-mullvad. (We need to use a standalone VM for the Mullvad client here because login session gets lost after a reboot in a normal AppVM setup, and I will make a seperate issue for that later).
2. Give sys-mullvad the network-manager service and tick the box "Provides Network".
3. Install the Mullvad client on it and log into Mullvad.
4. Make a new AppVM, set networking to use sys-mullvad.
5. Observe that if sys-mullvad uses OpenVPN (with or without Shadowsocks), DNS in the AppVM works properly. However, if sys-mullvad uses Wireguard, DNS does not work in the AppVM and the user has to manually set a custom DNS server in /etc/resolv.conf

Speculation:

I speculate that when OpenVPN is used, Mullvad integrations with NetworkManager in some way that it doesn't when Wireguard is being used. I haven't spent too much time looking into this yet, so I am not sure.

It is worth noting that if sys-mullvad isn't granted the network-manager service as described in step 2, the Mullvad client will have the same problem with OpenVPN like it does with Wireguard.

Why this should be supported:

I think manually setting wireguard up, installing the profiles, then manually setup the IP whitelist on the Qubes Firewall is extremely cumbersome. It gets even more annoying if the user tries to switch VPN servers and DNS servers. It would also be a pain trying to keep up wtth what IPs Mullvad adds and removes over time.

SInce Mullvad uses Qubes and continuously donates to the project, it would be very nice if it had better integration with Qubes OS.

[Minimalist73]

This issue is here since a long time. I opened something about this already in #3284 and it has been reported in #2865 where I provided a workaround.

[TommyTran732]

IVPN DNS does not work in the Qubes AppVMs -> ProxyVM with the official IVPN client ivpn/desktop-app#191

I am not sure that is actually the issue, because it only affects Wireguard, not OpenVPN. I will test it later though.

[pure007]

Is this related to https://github.com/QubesOS/qubes-issues/issues/7469 ? Seem like a temporary workaround would be to run sudo /usr/lib/qubes/qubes-setup-dnat-to-ns in the ProxyVM

[ohxodi]

I was working on a very similar configuration and found this topic as I had a DNS problem with my AppVM.

I have tested it quickly but, surprisingly, I have the exact same problem even if Mullvad is using OpenVPN. This is however consistent with how DNS works in Qubes OS.

Running /usr/lib/qubes/qubes-setup-dnat-to-ns in sys-mullvad is indeed a good workaround for the moment. I added it in /rw/config/rc.local file in order to run it just after mullvad-daemon starts.

[TommyTran732]

Hm... adding that to rc.local doesn't seem to solve any problem for me. I am using ShadowSocks + OpenVPN and it works fine, however.

[ohxodi]

Sorry for my late answer. I've quickly written this gist in order to be a little bit clearer on my configuration. I think this is very close to the configuration you were describing @tommytran732. DNS works the same way, either Mullvad is using OpenVPN or Wireguard.

As I've written, it is only a workaround and DNS update should be managed directly by Mullvad App as @Minimalist73 suggested in #3284. It should be a great enhancement for the Mullvad App.

[TommyTran732]

Sorry for my late answer. I've quickly written this gist in order to be a little bit clearer on my configuration. I think this is very close to the configuration you were describing @tommytran732. DNS works the same way, either Mullvad is using OpenVPN or Wireguard.

As I've written, it is only a workaround and DNS update should be managed directly by Mullvad App as @Minimalist73 suggested in #3284. It should be a great enhancement for the Mullvad App.

Awesome. One minor suggestion though: Instead of wgeting files, you can just do curl --proxy http://127.0.0.1:8082 in the templateVM. That way, you don't need to grant it the network access at all.

[ohxodi]

Thanks for the tip ! I was following Qubes OS documentation and was not sure how the proxy really works (whitelisting or "simple" proxy). I've just added a note to the gist in order to explain that.

[TommyTran732]

Honestly I am not sure if the GPG verification is necessary... I think it's rather useless.

You see, you are downloading a package over https here, so the only way you are getting a compromised package is if the server itself is compromised. The GPG key is downloaded directly from the same server, so if an attacker manages to compromise it they will also compromise the key you are downloading to verify stuff too.

[Museum7432]

Seeing how there is no solution provided anywhere (after hours of searching). I'd just add mine here. The issue is probably caused by mullvad app managing the DNS directly via /etc/resolv.conf (see the logs of mullvad-daemon.service) which means that the two placeholder DNS1 and DNS2 will be translated to the wrong DNS server (Qubes os networking). So i gave up fixing it and came up with a workaround (which also removes the need of networkmanager):

• force mullvad to use /etc/resolv.conf directly (with environmental variables)
• create a systemd service that waits for changes made to /etc/resolv.conf and run /usr/lib/qubes/qubes_setup_dnat_to_ns script (with inotify-tools)

set environmental variables for mullvad-daemon.service: sudo systemctl edit mullvad-daemon.service

[Service]
Environment="TALPID_DNS_MODULE=static-file"
Environment="MULLVAD_SETTINGS_DIR=/home/mullvad"

script that waits for dns changes (sudo dnf in inotify-tools)

#!/bin/sh
while true; do
    while inotifywait -e close_write /etc/resolv.conf; do
        /usr/lib/qubes/qubes_setup_dnat_to_ns
    done
done