Wireguard VPN setup (4.2 and 4.3)

Mirai · January 25, 2026, 11:09am

I would like to use a different vpn provider for the port forwarding.

Like it used to be on Mullvad to no weird port leasing.

Just forwarding the port from the vpn qube to the client qube. There shouldn’t be anything special when using network-manager ?

solene · January 25, 2026, 11:12am

Sorry, I thought it was the proton VPN topic

You need to use a few nftables to forward the traffic to the right place, and open the port in the appvm. My guide for forwarding ports (or the firewall documentation) is what you need. This is unrelated to network manager.

I can confirm it’ll work fine, I used such setup last year.

dkzkz · January 25, 2026, 11:42am

Everything works correctly but not the /rw/config/rc.local script i tried to delete the template-dispvm two times and restart again from scratch and it’s the same result any help please ? I’m using the last version on fedora on 4.3

What i have done so far is put the command of solene in /rw/config/rc.local > sudo chmod +x /rw/config/rc.local

(I noticed that every script i put in /rw/config/rc.local do not work even on debian based vm) and by doing some research i’v seen other people had problem with /rw/config/rc.local in the past

solene · January 25, 2026, 11:55am

Can you share the content of your /rw/config/rc.local file?

Why are you referring to disposable templates? I don’t see the connection between this and the rc.local script.

dkzkz · January 25, 2026, 12:23pm

The content of my /rw/config/rc.local

#!/bin/sh

# This script will be executed at every VM startup, you can place your own
# custom commands here. This includes overriding some configuration in /etc,
# starting services etc.
#
# Executable scripts located in /rw/config/rc.local.d with the extension
# '.rc' are executed immediately before this rc.local.
# Example:
#  /rw/config/rc.local.d/custom.rc
#
# Example for overriding the whole CUPS configuration:
#  rm -rf /etc/cups
#  ln -s /rw/config/cups /etc/cups
#  systemctl --no-block restart cups

RANDOM_VPN=$(nmcli connection show | awk '/wireguard/ { print $1 }' | sort -R | head -n 1)
nmcli connection up "$RANDOM_VPN"

I said that to give more information but anyway i can’t see where the problem is coming from

solene · January 25, 2026, 12:24pm

Does the script work if you start it manually?

dkzkz · January 25, 2026, 12:25pm

Manual start works yes this is so strange… it looks like the vm ignore the script

solene · January 25, 2026, 12:26pm

Can you add sleep 5 before the two commands?

dkzkz · January 25, 2026, 12:35pm

The “sleep 5” commands worked ! Thanks you’re amazing but… why i have to do that and not you ?

solene · January 25, 2026, 12:40pm

I’m not sure why it’s needed here, something might have changed since the guide, maybe network manager isn’t ready yet now at this stage?

dkzkz · January 25, 2026, 12:49pm

If you want i can do some other test for you just tell me what i have to do

barto · January 26, 2026, 11:54am

To permanently fix this timing issue, I changed in the sys-vpn template the systemd requirement for qubes-misc-post.service , so that it starts after “network-online.target”, not “network-pre.target”:

[deb-12m-vpn]# sed -ie 's/network-pre.target/network-online.target/g' /lib/systemd/system/qubes-misc-post.service

Notes:

this qubes-misc-post.service is running /usr/lib/qubes/init/misc-post.sh which in turn runs any /rw/config/rc.local.d/* scripts and /rw/config/rc.local;
for the impatient users: after the change, the template must be shut down and only then the changes will show up upon further sys-vpn (re)starts

lars-qubes · January 31, 2026, 8:48pm

First of all I want to thank you, Solene, for this guide who enabled me to set up a sys-vpn service Qube for wireguard based VPN (by Proton)!

Since I’ll not only want to use this but also understand the underlying concepts and settings I’m asking the following regarding this statement from you:

Why is that?

solene · January 31, 2026, 9:30pm

I don’t really remember the certainly good reason I had when writing this, but by pinning sys-firewall you are sure that the netvm will not change.

If you put sys-whonix as the default netvm, the VPN would not establish and firewall rules would not be applied.

lars-qubes · January 31, 2026, 9:36pm

I think this is it.

ryrona · February 22, 2026, 8:40am

I just wanted to inform about a low severity information disclosure security vulnerability happening on Qubes 4.3 when following these suggested Wireguard VPN guidelines, at least when using debian-13-xfce template for the VPN gateway qube.

github.com/QubesOS/qubes-issues

Local addresses leaks over VPN when using sys-vpn qube

opened 08:31AM - 22 Feb 26 UTC

ryrona2

P: default

### Qubes OS release Up-to-date QubesOS 4.3.0, with debian-13-xfce template. …### Brief summary Despite settings up a Wireguard-based sys-vpn qube according to community recommendations, the resulting sys-vpn qube will leak local addresses over the VPN. More specifically, it will leak the assigned local IP address of the eth0 and wg0 interfaces as shown by "ip a" in the sys-vpn qube. It is the sys-vpn qube itself that are leaking these IP addresses, not any qube using sys-vpn as gateway, and the leak is done through reverse DNS lookups going out to the VPN configured DNS server over the VPN interface. They happen periodically, maybe once every 10 minutes, and can easily be observed by running Wireshark in the sys-vpn qube, capturing on the wg0 interface. This issue was discovered during routine security audit, and is likely a regression from 4.2.x, as this issue was never observed on 4.2.x, despite same setup. ### Security implications Both IP addresses that leaks constitute persistent identifiers, and can potentially be used by an adversary located after the VPN connection to aid correlation of application traffic, determining that certain application traffic belongs to the same user, even over time. This risk is especially high of you are the only user or one of few users using a specific VPN server at a specific time. Since the IP addresses or local, they do not by themselves reveal the geographical location or identity of that user, though. The VPN provider assigned IP address, mentioned in the Wireguard configuration file, is one of the addresses that leak. This IP address is different for every VPN user, and is potentially uniquely identifying you. An adversary that can coerce the VPN provider to reveal real user behind a specific assigned IP address, may be able to deanonymize you. VPNs are supposed to prevent this specific attack, by not leaking any persistent identifiers known to the VPN provider. Some VPN providers run their own local DNS server, which will receive these reverse DNS lookup requests, and possibly answer them without contacting external DNS servers, which means no leaking to any adversary located after the VPN tunnel will happen in those cases. But it is not possible for you as an user to determine if this is the case, as it depends on server-side configuration at the VPN provider. ### Steps to reproduce In Qubes 4.3, create a new app qube based on debian-13-xfce template, name it "sys-vpn", assign sys-firewall as network qube, and mark that qube provides network. Add "network-services" as enabled service in qube configuration. Then, in dom0 terminal, run this: ``` qvm-firewall sys-vpn reset qvm-firewall sys-vpn add accept dsthost=VPN-IP dstports=VPN-PORT proto=udp qvm-firewall sys-vpn add drop qvm-firewall sys-vpn del --rule-no 0 qvm-firewall sys-vpn list ``` Finally, start the qube, move the Wireguard VPN configuration file there, and import it: ``` nmcli connection import type wireguard file wg0.conf ``` Start wireshark network monitor in sys-vpn on the wg0 interface, and observe traffic. ### Expected behavior No DNS queries like `Standard query ... PTR <local IP address>.in-addr.arpa` shows up in the trace. ### Actual behavior Such reverse DNS queries does show up every 10 minutes, source being sys-vpn IP address and destination being the DNS server IP address mentioned in the Wireguard configuration file. The configured remote DNS server responding to these queries can also be observed, usually with a response like "No such name". Issue persist after reboot. ### Additional information I was not able to locate which application running in sys-vpn it is that generates these reverse DNS lookups. The "netstat -cptuw" command was not able to catch the packets, and wireshark does not capture PIDs. I did not find any easy way on Linux to both capture all packets on an interface, and capture PIDs at the same time. I am not able to test with Fedora based template, the issue may be present in Fedora based templates as well. The issue only happens in the sys-vpn qube. No such reverse DNS lookups can be observed originating from the sys-firewall or sys-net qubes, despite based on the same template.

I found it during a routine security audit, and have reported it to the bug tracker, but it may as well be a configuration flaw rather than software bug. If anyone is able to help replicate or prevent this leak, it would be appreciated.

urxvtw · February 28, 2026, 7:09pm

Hey @ryrona I’ve noticed your impeccable work here, as well as debunking that Qubes OS is not secure on the grapheneOS forums, a while back. I also noticed you troubleshooted with Wireshark a USB problem of not being able to attach a pixel running graphene OS on qubes. I would like to ask you, (since there is no DM option), how did you achieve such mastery? Who thinks of running Wireshark on sys-usb and then have enough skill to actually find the problem? This is very inspiring and I hope you get a chance to reply as I’d like to learn and reach your level.

Mirai · March 1, 2026, 10:12am

Okay I have been trying for a while now but I can’t get VPN port forwarding to work.

Netcat can’t get a connection at all when listening in the vpn-qube-2 with nc -l $port.
Did not have this issue with wg-quick…

I don’t think any firewall rules should block it.

My setup is vpn-qube-2 > vpn-qube-1 > sys-firewall > sys-net
qvm-firewall blocks everything but the udp port for vpn-qube-1 but no rules at all for vpn-qube-2

Could somebody pls help out?

solene · March 1, 2026, 12:15pm

If I understand correctly, you want to have a service in vpn-qube-2 listening on a port, and the other side of the VPN should be able to connect, right?

Indeed, sys-firewall and vpn-qube-1 firewalls have nothing to do with this because they all see WireGuard tunnel. You might already know this, but I’m summarizing to be sure we both talk about the same thing

Can vpn-qube-2 and its remote peer able to ping each other?

Did you allow the incoming port in vpn-qube-2 on the WireGuard interface? By default, qubes block all incoming traffic on all interfaces, so it would be the expected behavior to have incoming connections through a VPN to be blocked.

Mirai · March 1, 2026, 12:51pm

Thanks,

I want to run a service in vpn-qube-2 that should be reachable by the public VPN address and the port. (Like mullvad port forwarding)

I can ping the endpoint.

I tried to set this rule in vpn-qube-2:

nft insert rule qubes custom-input udp dport "$port" accept
nft insert rule qubes custom-input tcp dport "$port" accept

But I though this should not even be necessary and just be tunneled via the normal udp port
Are these the right rules