IVPN is a fairly popular and generally trustworthy VPN provider. In this post, I will walk you through how to use the official IVPN client in a ProxyVM on Qubes OS. We will deviate from the official guide by using systemd path to handle DNAT. This will provide the same robustness as their approach to modify /opt/ivpn/etc/firewall.sh, while avoiding the risk that the modifications will be overwritten by a future app update. We will also be using a TemplateVM for IVPN ProxyVMs instead of using Standalone VMs.

Preparing your TemplateVM

I recommend that you make a new TemplateVM based on the latest Fedora GNOME template and remove all unnecessary packages that you might not use. This way, you can minimize the attack surface while not having to deal with missing dependencies like on a minimal template. With that being said, if you do manage to get the minimal template to fully work with IVPN, feel free to open a discussion on GitHub or contact me directly and I will update the post accordingly.

I run this script on my template to trim it down.

Next, you need to create the bind directories for IVPN’s configurations:

sudo mkdir -p /etc/qubes-bind-dirs.d
echo 'binds+=( '\'''/etc/opt/ivpn/mutable''\'' )' | sudo tee /etc/qubes-bind-dirs.d/50_user.conf 

Installing the IVPN App

Inside of the TemplateVM you have just created, do the following:

sudo dnf config-manager addrepo --from-repofile=https://repo.ivpn.net/stable/fedora/generic/ivpn.repo
sudo dnf install -y ivpn-ui

IVPN needs to restart systemd-resolved and run /usr/lib/qubes/qubes-setup-dnat-to-ns every time IVPN modifies /etc/resolv.conf. Create the following files:

• /etc/systemd/system/dnat-to-ns.service

[Unit]
Description=Run /usr/lib/qubes/qubes-setup-dnat-to-ns
StartLimitIntervalSec=0

[Service]
Type=oneshot
ExecStart=/usr/bin/systemctl restart systemd-resolved
ExecStart=/usr/lib/qubes/qubes-setup-dnat-to-ns

• /etc/systemd/system/dnat-to-ns.path

[Unit]
Description=Run /usr/lib/qubes/qubes-setup-dnat-to-ns when /etc/resolv.conf changes

[Path]
PathChanged=/etc/resolv.conf
Unit=dnat-to-ns.service

[Install]
WantedBy=multi-user.target

• /etc/systemd/system/dnat-to-ns-boot.service

[Unit]
Description=Run /usr/lib/qubes/qubes-setup-dnat-to-ns
After=qubes-network-uplink.service

[Service]
Type=oneshot
ExecStart=sleep 15
ExecStart=/usr/lib/qubes/qubes-setup-dnat-to-ns

[Install]
WantedBy=multi-user.target

Create /etc/systemd/system/systemd-resolved.conf.d/override.conf to disable rate limiting on systemd-resolved restarting:

[Unit]
StartLimitIntervalSec=0

Next, enable the systemd path and service to run at boot:

sudo systemctl enable dnat-to-ns.path
sudo systemctl enable dnat-to-ns-boot.service

Finally, shut down the TemplateVM:

sudo shutdown now

Creating the ProxyVM

Create an AppVM based on the TemplateVM you have just created. Set sys-firewall (or whatever FirewallVM you have connected to your sys-net) as the net qube. If you do not have such FirewallVM, use sys-net as the net qube. Next, go to the advanced tab and tick the provides network access to other qubes box.

Open the IVPN and select Settings → DNS → Force management of DNS using resolv.conf.

Go to the IVPN Firewall section and tick the box Allow LAN traffic when IVPN Firewall is enabled. Due to some strange interaction between qubes services and IVPN, certain apps will get internet connections while others do not if this toggle is not enabled. This option will not actually allow AppVMs connected to the ProxyVM to connect to the local network.

Enable Always-on firewall to ensure that the killswitch stays on even when the tunnel is disconnected.

Additional Assurances

For additional assurances against VPN leaks, you can optionally add these 2 lines to /rw/config/qubes-firewall-user-script:

nft add rule qubes custom-forward oifname eth0 counter drop
nft add rule ip6 qubes custom-forward oifname eth0 counter drop

This is not strictly necessary, as I have not observed any leaks with the VPN killswitch provided by the app.

Notes

With this current setup, the ProxyVM you have just created will be responsible for handling Firewall rules for the qubes behind it. This is not ideal, as this is still a fairly large VM, and there is a risk that IVPN or some other apps may interfere with its firewall handling.

Instead, I highly recommend that you create a minimal Mirage FirewallVM and use it as a firewall behind the IVPN ProxyVM. Other AppVMs then should use the Mirage Firewall as the net qube instead. This way, you can make sure that firewall rules are properly enforced.

Mullvad is a fairly popular and generally trustworthy VPN provider. In this post, I will walk you through how to use the official Mullvad client in a ProxyVM on Qubes OS. This method is a lot more convenient than the official guide from Mullvad (which recommends that you manually load in OpenVPN or Wireguard profiles) and will let you seamlessly switch between different location and network setups just as you would on a normal Linux installation.

Preparing your TemplateVM

I recommend that you make a new TemplateVM based on the latest Fedora GNOME template and remove all unnecessary packages that you might not use. This way, you can minimize the attack surface while not having to deal with missing dependencies like on a minimal template. With that being said, if you do manage to get the minimal template to fully work with Mullvad, feel free to open a discussion on GitHub or contact me directly and I will update the post accordingly.

I run this script on my template to trim it down.

Next, you need to create the bind directories for Mullvad’s configurations:

sudo mkdir -p /etc/qubes-bind-dirs.d
echo 'binds+=( '\'''/etc/mullvad-vpn''\'' )' | sudo tee /etc/qubes-bind-dirs.d/50_user.conf 

Installing the Mullvad App

Inside of the TemplateVM you have just created, do the following:

sudo dnf config-manager addrepo --from-repofile=https://repository.mullvad.net/rpm/stable/mullvad.repo
sudo dnf install -y mullvad-vpn

To work around issue 3803, we will be using systemd path to run /usr/lib/qubes/qubes-setup-dnat-to-ns every time Mullvad modifies /etc/resolv.conf. Create the following files:

• /etc/systemd/system/dnat-to-ns.service

[Unit]
Description=Run /usr/lib/qubes/qubes-setup-dnat-to-ns
StartLimitIntervalSec=0

[Service]
Type=oneshot
ExecStart=/usr/bin/systemctl restart systemd-resolved
ExecStart=/usr/lib/qubes/qubes-setup-dnat-to-ns

• /etc/systemd/system/dnat-to-ns.path

[Unit]
Description=Run /usr/lib/qubes/qubes-setup-dnat-to-ns when /etc/resolv.conf changes

[Path]
PathChanged=/etc/resolv.conf
Unit=dnat-to-ns.service

[Install]
WantedBy=multi-user.target

Create /etc/systemd/system/systemd-resolved.conf.d/override.conf to disable rate limiting on systemd-resolved restarting:

[Unit]
StartLimitIntervalSec=0

Next, enable the systemd path:

sudo systemctl enable dnat-to-ns.path

Finally, shut down the TemplateVM:

sudo shutdown now

Creating the ProxyVM

Create an AppVM based on the TemplateVM you have just created. Set sys-firewall (or whatever FirewallVM you have connected to your sys-net) as the net qube. If you do not have such FirewallVM, use sys-net as the net qube. Next, go to the advanced tab and tick the provides network access to other qubes box.

Open the Mullvad VPN app. Go to Settings → VPN settings and toggle Local network sharing. Due to some strange interaction between qubes services and Mullvad VPN, certain apps will get internet connections while others do not if this toggle is not enabled. This toggle will not actually allow AppVMs connected to the ProxyVM to connect to the local network.

Enable Lockdown mode to ensure that the killswitch stays on even when the tunnel is disconnected.

Additional Assurances

For additional assurances against VPN leaks, you can optionally add these 2 lines to /rw/config/qubes-firewall-user-script:

nft add rule qubes custom-forward oifname eth0 counter drop
nft add rule ip6 qubes custom-forward oifname eth0 counter drop

This is not strictly necessary, as I have not observed any leaks with the VPN killswitch provided by the app.

Notes

With this current setup, the ProxyVM you have just created will be responsible for handling Firewall rules for the qubes behind it. This is not ideal, as this is still a fairly large VM, and there is a risk that Mullvad or some other apps may interfere with its firewall handling.

Instead, I highly recommend that you create a minimal Mirage FirewallVM and use it as a firewall behind the Mullvad ProxyVM. Other AppVMs then should use the Mirage Firewall as the net qube instead. This way, you can make sure that firewall rules are properly enforced.

MirageOS is a library operating system with which you can create a unikernel for the sole purpose of acting as Qubes OS’s firewall. In this post, I will walk you through how to set this up.

Advantages

• Small attack surface. The unikernel only contains a minimal set of libraries to function, so it has a much smaller attack surface than a general purpose operating system like a Linux distribution or openBSD.
• Low resource consumption. You only need about 64MB of RAM for each instance of the Mirage Firewall.
• Fast startup time.

Disadvantages

• No official package for Qubes OS. This means that you need to follow the development process on GitHub and download the new build whenever there is a release.
• Does not work well with the Windows PV network driver. With that being said, the Windows PV networking driver is pretty buggy on its own, and I don’t recommend that you use it anyways.

Installing the unikernel

To deploy MirageOS, you need to copy the vmlinuz and initramfs files from their releases page to /var/lib/qubes/vm-kernels/mirage-firewall in dom0.

TemplateVM

Create a TemplateVM:

qvm-create \
  --property kernel=mirage-firewall \
  --property kernelopts='' \
  --property memory=64 \
  --property maxmem=64 \
  --property vcpus=1 \
  --property virt_mode=pvh \
  --label=black \
  --class TemplateVM \
  your_template_name

Don’t worry if the TemplateVM doesn’t launch — we don’t need it to.

Disposable Template

Next, create a disposable template based on the TemplateVM you have just created.

qvm-create \
  --property template=your_template_name \
  --property provides_network=True \
  --property template_for_dispvms=True \
  --label=orange \
  --class AppVM \
  your_disposable_template_name

qvm-features your_disposable_template_name qubes-firewall 1
qvm-features your_disposable_template_name no-default-kernelopts 1

Your disposable templates should now launch and shut down properly.

Disposable FirewallVMs

You can now create disposable FirewallVMs based on your disposable template. I recommend replacing sys-firewall with a disposable Mirage firewall. If you use ProxyVMs like sys-whonix, I recommend that you add a disposable Mirage Firewall after the ProxyVM as well, and use it as the net qube for your AppVMs.

qvm-create \
  --property template=your_disposable_template_name \
  --property provides_network=True \
  --property netvm=your_net_qube_name \
  --label=orange \
  --class DispVM \
  your_firwall_name

This post will go over setting up Split GPG, then setting up Split SSH with the same PGP keys. Effectively, we are emulating what you can do with a PGP smartcard on Qubes OS.

Split GPG

Follow the official Qubes OS documentation to set this up.

Note that if you already have a PGP key with a passphrase, you can remove it by installing pinentry-gtk to vault’s TemplateVM, then run gpg2 --edit-key <key_id> and passwd to set an empty passphrase. The default non-graphical pinentry will just make an infinite loop and will not allow you to set an empty passphrase.

Split SSH

This part is based on the Qubes Community’s guide; however, I will deviate from it to use the PGP keys for SSH instead of generating a new key pair.

In dom0

• Create /etc/qubes-rpc/policy/qubes.SshAgent with @anyvm @anyvm ask,default_target=vault as the content. Since the keys are not passphrase protected, you should not set the policy to allow.

In vault AppVM

• Add enable-ssh-support to the end of ~/.gnupg/gpg-agent.conf
• Get your keygrip with gpg --with-keygrip -k
• Add your keygrip to the end of ~/.gnupg/sshcontrol

In vault’s TemplateVM

• Create /etc/qubes-rpc/qubes.SshAgent with the following content:

#!/bin/sh
# Qubes App Split SSH Script

# Activate GPG Agent and set the correct SSH socket
export SSH_AUTH_SOCK=$(gpgconf --list-dirs agent-ssh-socket)
gpgconf --launch gpg-agent

# safeguard - Qubes notification bubble for each ssh request
notify-send "[$(qubesdb-read /name)] SSH agent access from: $QREXEC_REMOTE_DOMAIN"

# SSH connection
socat - "UNIX-CONNECT:$SSH_AUTH_SOCK"

• Make it executable with sudo chmod +x /etc/qubes-rpc/qubes.SshAgent
• Turn off the templateVM. If the vault VM is running, turn it off, then start it to update the VM’s configuration.

In ssh-client AppVM

• Add the following to the end of /rw/config/rc.local:

# SPLIT SSH CONFIGURATION >>>
# replace "vault" with your AppVM name which stores the ssh private key(s)
SSH_VAULT_VM="vault"

if [ "$SSH_VAULT_VM" != "" ]; then
  export SSH_SOCK="/home/user/.SSH_AGENT_$SSH_VAULT_VM"
  rm -f "$SSH_SOCK"
  sudo -u user /bin/sh -c "umask 177 && exec socat 'UNIX-LISTEN:$SSH_SOCK,fork' 'EXEC:qrexec-client-vm $SSH_VAULT_VM qubes.SshAgent'" &
fi
# <<< SPLIT SSH CONFIGURATION

• Add the following to the end of ~/bash.rc:

# SPLIT SSH CONFIGURATION >>>
# replace "vault" with your AppVM name which stores the ssh private key(s)
SSH_VAULT_VM="vault"

if [ "$SSH_VAULT_VM" != "" ]; then
  export SSH_AUTH_SOCK="/home/user/.SSH_AGENT_$SSH_VAULT_VM"
fi
# <<< SPLIT SSH CONFIGURATION

• Restart ssh-client and confirm if it’s working with ssh-add -L.

Limitations

A malicious ssh-client AppVM can hold onto the ssh-agent connection for more than one use until it is shut down. While your private key is protected, a malicious actor with access to the AppVM can still abuse the ssh-agent to log into your servers.

Lokinet is an Internet overlay network utilizing onion routing to provide anonymity for its users, similar to Tor network. This post will go over how to set it up on Qubes OS.

Before we start…

This post should not be considered an endorsement of Lokinet in any shape or form. Lokinet is currently not in a good state — it has not had a public release since 2022, and most free public exit nodes have gone offline. According to the developers, they are doing major rewrites of the code, and it should not be used in production at the moment.

Creating the TemplateVM

Currently, the Lokinet client seems to work well with only Debian-based distributions. This means that our template will have to be one of the Debian-based ones. Personally, I use this script to trim down the Debian GNOME template and convert it to Kicksecure. Kicksecure reduces the attack surface of Debian with a substantial set of hardening configurations, and a nice feature to go with an anonymity network like Lokinet is Boot Clock Randomization which helps defend against time-based denonymization attacks.

Start by creating the bind directories for Lokinet’s configurations:

sudo mkdir -p /etc/qubes-bind-dirs.d
echo 'binds+=( '\'''/etc/loki''\'' )' | sudo tee /etc/qubes-bind-dirs.d/50_user.conf 

Next, add the Oxen PGP key and the Lokinet template. We will deviate from the official documentation and pin the PGP key to only be used for this repository:

curl --proxy http://127.0.0.1:8082 https://deb.oxen.io/pub.gpg | sudo tee /usr/share/keyrings/oxen.gpg
echo "deb [signed-by=/usr/share/keyrings/oxen.gpg] https://deb.oxen.io $(lsb_release -sc) main" | sudo tee /etc/apt/sources.list.d/oxen.list

Next, lokinet and resolvconf. lokinet-gui was very buggy when I tested it inside my VM, so I recommend installing only the daemon. resolvconf is used by the Lokinet init script but is not declared as a dependency for some reason, so you have to manually install it as well:

sudo apt update
sudo apt install lokinet-gui resolvconf

To work around the problem where Qubes overrides the DNS configuration at boot, create /etc/systemd/system/lokinet-dns-fix.service with the following content:

[Unit]
Description=Fix DNS for Lokinet
After=qubes-network-uplink.service

[Service]
Type=oneshot
ExecStart=/usr/bin/rm /etc/resolv.conf
ExecStart=/usr/bin/ln -s /run/resolvconf/resolv.conf /etc/resolv.conf

[Install]
WantedBy=multi-user.target

Enable the lokinet-dns-fix service:

sudo systemctl enable lokinet-dns-fix

At this stage, you can install any .deb app you want to use with Lokinet in the TemplateVM. I have been unable to get DNS working properly with Lokinet as a network VM, so for now we will have to use a Lokinet in each individual AppVM.

Finally, shut down the TemplateVM:

sudo shutdown now

Creating the AppVM

Create an AppVM based on the TemplateVM you have just created. Set sys-firewall (or whatever FirewallVM you have connected to your sys-net) as the net qube. If you do not have such FirewallVM, use sys-net as the net qube.

Edit /etc/loki/lokinet.ini and add the exit node you want to use. At the moment, the only free exit node that I am aware of is euroexit.loki:

[network]
exit-node=euroexit.loki