What is the content of /etc/resolv.conf in your VPN qube when the VPN is started with wg-quick?
with resolvconf, these are dns of the firewall-vm before the vpn-qube / gateway of the vpn-qube
nameserver 10.139.1.1
nameserver 10.139.1.2
when I install openresolv (ip of the dns server in the config)
# Generated by resolvconf
nameserver 10.2.0.1
I do have dns inside the vpn qube which seems to go over the vpn with openresolv (dns is dropped in qvm-firewall)
But every qube with the vpn qube as it’s gateway still has no dns
nmcli (which works with the proton config) puts this in resolv
# Generated by NetworkManager
nameserver 10.2.0.1
nameserver 10.139.1.1
nameserver 10.139.1.2
the mullvad config works with wg-quick even if just the ip of the dns of the gateway qube is there
these rule do not help
DNS=9.9.9.9
nft add chain qubes nat { type nat hook prerouting priority dstnat\; }
nft add rule qubes nat iifname == "vif*" tcp dport 53 dnat "$DNS"
nft add rule qubes nat iifname == "vif*" udp dport 53 dnat "$DNS"
BTW how do you guys call all the upstream / downstream qubes, I am getting a bit confused myself how I should call them
What are your firewall rules? You use 9.9.9.9 instead of 10.2.0.1 here. Which one is allowed?
In dom0 I have completely blocked dns (even if if there are no firewall rules at all still no dns)
I then tried to set this in /rw/config/qubes-firewall-user-script
DNS=9.9.9.9
nft add chain qubes nat { type nat hook prerouting priority dstnat\; }
nft add rule qubes nat iifname == "vif*" tcp dport 53 dnat "$DNS"
nft add rule qubes nat iifname == "vif*" udp dport 53 dnat "$DNS"
In hopes of fixing it but with or without it still does not work
Inside the vpn-qube I have dns, but for some reason everything connected to it does not, also this is only the case with protonvpn… and only when using wg-quick with nmcli everything works properly
even if I manaully change the dns to 9.9.9.9 in the wireguard-config or /etc/resolv everything connected to the vpn-qube still does not have any dns
Pls tell me if anything is unclear, I will try to do a proper write up
What did you do exactly?
none of those
I do, I need the MTU fix.
Same behavior for me using the systemd unit.
Speaking of DNS in wireguard VPN qubes, I always use this:
Actually nowadays I have a slightly different convoluted setup in the sys-vpn-* qubes, checking for the existence of the zzz-my-hook in /rw/config, and copying it to the correct location if it exists, combined with some qubesdb vm-config magic… but the principle is the same.
Removing 10.139.1.[1-2] also acts as a “poor man’s DNS leaks preventer” although only specific traffic is allowed in the upstream firewall qube - I mean, it’s an unneeded bonus feature.
Lets assume qvm-firewall vpn-qube reset. For now I just want it to get working at all.
- Install following packages into fresh debian-13-minimal:
qubes-core-agent-networking wireguard wireguard-tools resolvconf - Create a proxy qube based on the template
- move the wireguard configs to the qube
- Copy this into rc.local
wg-quick up $config_path - Dns of every qube connected to the vpn-qube does not work
But it’s not supposed to work. You either need to run the qubes Os script that does something with the DNS resolving in a netvm, I forgot the script name but it does not work under all circumstances…
Or you need the DNS requests redirect nft rules.
Okay that’s new news.
Like I said with mullvad it works. and even with rules like this it does not:
DNS=9.9.9.9
nft add chain qubes nat { type nat hook prerouting priority dstnat\; }
nft add rule qubes nat iifname == "vif*" tcp dport 53 dnat "$DNS"
nft add rule qubes nat iifname == "vif*" udp dport 53 dnat "$DNS"
Also why does it work with network manager then, I am also not using these nft rules there? And I have qvm-firewall vpn-qube drop specialtarger=dns in dom0, so it’s also not leaking ( I also check the responding dns server with dig)
Why is it not supposed to work? I am extremely confused right now.
Apparently I am missing something major
Could you send me configuration files in private of mullvad and proton VPN? Strip private keys, preshared keys if any, you can also remove the public key. I need to compare the files.
I don’t understand why it works with mullvad. I don’t think the DNS should work out of the box, although it might depend of the local resolving system, you install resolvconf, maybe it’s doing something.
Are there any PostUp lines in your WG configuration?
Also, try using the Proton internal DNS that goes through the tunnel instead of an external one. In your previous answers, it was 10.2.0.1, but it could be different.
After connecting to Proton with wg-quick, run these two commands in your VPN qube and test the connectivity of your app qubes.
sudo nft flush chain qubes dnat-dns
sudo nft add rule ip qubes dnat-dns meta l4proto { tcp, udp } iifgroup 2 ip daddr { 10.139.1.1, 10.139.1.2 } th dport 53 dnat to "$(awk '/nameserver/ {print $2}' /etc/resolv.conf)"
Another thing: you don’t need to explicitly drop the Qubes DNS forwarding. Simply removing the accept rule is sufficient, since the last action is always to reject anything not part of the firewall rules. All you have to do is add the VPN’s IP address (from the configuration).
You need to install openresolv instead of resolvconf to get dns inside the vpn qube
sent you a pm
No, one of the reason I am so confused.
running this command in the vpn qube:
sudo nft flush chain qubes dnat-dns
in combination with these dns rules
DNS=9.9.9.9
nft add chain qubes nat { type nat hook prerouting priority dstnat\; }
nft add rule qubes nat iifname == "vif*" tcp dport 53 dnat "$DNS"
nft add rule qubes nat iifname == "vif*" udp dport 53 dnat "$DNS"
Gives me dns in qubes connected to the vpn qube. If either is missing it does not work
Just running this with the dns rules does not give me dns.
sh -c 'sudo nft add rule ip qubes dnat-dns meta l4proto { tcp, udp } iifgroup 2 ip daddr { 10.139.1.1, 10.139.1
.2 } th dport 53 dnat to "$(awk \'/nameserver/ {print $2}\' /etc/resolv.conf)"'
But running it after the flush it still works then.
The dns request of the vpn qube go over protons internal dns but the connected qubes do not. double checked this, they go over the ones defined in the nft rules
I made some changes:
- edit the introduction: fedora-38 is not a news anymore
and the link was useless. Is Configuring a ProxyVM VPN Gateway still relevant? - replace the section about service enabling by a link to the docs (providing several methods)
- change the headers to make clear that you can set up the firewall with two methods
- each
qvm-firewallcommand is commented directly - remove the useless alt attributes
- add a Customization section (only to mention minimal-netvm service)
- add a basic Troubleshooting section with some tips I found out to be useful while testing.
I followed this guide with a debian-13-xfce template, so I think that we could remove any reference to a specific template. I also used a named disposable.
Edit: I forgot to mention that I still don’t get the different killswitch options.
3 Likes
I am using only the anti-leak firewall rules in dom0 since it is must simpler than the nftables.
Which leak cases will be covered by nftables which are not blocked by dom0 firewall approach?
(Cross-post: How To make an OpenVPN Gateway in Qubes (4.2, 4.3) - #2 by whoami)
Any idea what rules could be responsible for this behavior? I would guess that some private ip spaces get treated special in wg-quick
You should start from scratch and try playing with the DNS rules only, without the firewall rules. Something is blocking your requests, so you need to figure out what by setting aside some of the configuration.
Guess my best bet is just giving up, because the only rules I have right now are the ones automatically set by wg-quick.
I already tried all possibly combinations and thing I can think of.
And I really don’t know enough to play around with the networking of qubes.
I think there might be some magic included in the mullvad configs.
Anyway thanks for trying to help out
Hi @solene or anyone familiar. I hope this is not already addressed, I tried searching this thread for “LAN” and “local”, but I did not find a solution.
I use the Wireguard config from ProtonVPN, which has AllowedIPs = 0.0.0.0/0, ::/0 and some Endpoint = 1.2.3.4:51820 in the peer configuration. I added this Endpoint to the Qubes Firewall settings per your original guide and everything works flawlessly for WAN connections.
My use case is that I have a remote server in my LAN setup with several IPs in the 172.16.0.0/12 subnet. I connect to any of these hosts using IP, so DNS is not needed.
I have a qube on which I develop software and occasionally need to deploy it to one of these local servers. Due to the allowed IPs and firewall settings, I obviously cannot connect to the LAN endpoints. So I “temporarily” switch my net-vm to “sys-firewall”, which feels very dirty.
I have tried to manually update some settings to be able to connect to 172.16.0.0/12 locally, and otherwise route through Wireguard. What I have attempted, using this IP calculator to disallow 172.16.0.0/12 (thus having AllowedIPs = 0.0.0.0/1, 128.0.0.0/3, 160.0.0.0/5, 168.0.0.0/6, 172.0.0.0/12, 172.32.0.0/11, 172.64.0.0/10, 172.128.0.0/9, 173.0.0.0/8, 174.0.0.0/7, 176.0.0.0/4, 192.0.0.0/2), I manually updated the AllowedIPs in my vpn-client.conf file. Then I went to the Qubes Firewall Rules for sys-vpn and added 172.16.0.0/12 to the allowed connections. Then restarted sys-vpn.
Still, from within sys-vpn terminal itself, I cannot reach hosts in this local subnet. Is there something else I need to do? Should I expect this to work under any circumstance? Finally, is there any reason I should not try to do this? Assuming either that I do or do not completely trust the hosts in 172.16.0.0/12.
Thank you.