WireGuard DNS is not propagated to reliant VMs

[Ranguvar]

Hey tasket!
I've had this working in the past without mucking about, so I've likely fscked something this install, pardon.

I have working WireGuard VPN, reliant VMs can ping out to IPs, but cannot name resolve.

sys-vpn is the name of the VM running qubes-vpn-support with WireGuard, and it has provides_network - True.

/etc/resolv.conf points to the defaults, rather than sys-vpn, my WireGuard ProxyVM, which points to the DNS entry in the WireGuard conf file, and has working resolution.

Any help debugging this would be most appreciated.

[tasket]

@Ranguvar Hi... What is your template OS version and source for installing wireguard?

The state of resolv.conf sounds OK bc qubes-vpn-support doesn't attempt to alter the local DNS for the vpn vm. The place to check DNS is the PR-QBS chain: iptables -t nat -L PR-QBS.

[Ranguvar]

Thanks tasket!

Template is Fedora 29, I simply copied it to a new 'wireguard' template, enabled jdoss/wireguard, and installed wireguard-tools and wireguard-dkms.

I used Syff's solution in issue 2844 to mount an overlay on top of the kernel modules where wireguard.ko is now stored: QubesOS/qubes-issues#2844 (comment)

This overlay is mounted in rc.local before the rest of the vpn-support script is run.

Output of iptables -t nat -L PR-QBS from sys-vpn:
Chain PR-QBS (1 references)
target prot opt source destination
DNAT udp -- anywhere 10.139.1.1 udp dpt:domain to:128.31.0.72
DNAT tcp -- anywhere 10.139.1.1 tcp dpt:domain to:128.31.0.72
DNAT udp -- anywhere 10.139.1.2 udp dpt:domain to:172.98.193.42
DNAT tcp -- anywhere 10.139.1.2 tcp dpt:domain to:172.98.193.42

Output on personal VM, using sys-vpn as network provider:
Chain PR-QBS (1 references)
target prot opt source destination

[tasket]

If 128.31.0.72 and 172.98.193.42 are the vpn's dns addresses, then that looks workable. However, it seems like the revision of qubes-vpn-support may be older as the current version sets up dnat in a slightly better way ('anywhere' would replace 10.139.1.2 in the new version, making the fallback server a catch-all).

Also, I'm currently not able to test wg connections as I currently don't subscribe to a vpn that offers wg. Unfortunately, that situation is compounded by a recent inability to boot templates or standalone vms using the internal kernel, which is the method I've used so far.

A few points for exploration:
0. Look at the journalctl log for anything unusual from the qubes-vpn-handler service.

1. wg-quick is auto-patched to handle DNS assignment and placed in /tmp at connection time. The patch relies on the two commands defined in 10_wg.conf that utilize the insertion point the wg project provided. So looking at /tmp/wg-quick after connection is another way to check.

2. Monitoring the PR-QBS and FORWARD chains for activity (packet counts) may help. Of course, you can take it further with tools like wireshark.

3. Something about the firewall may be too restrictive. You can try these commands in the wg vm to temporarily loosen them a bit without removing anti-leak for dependent vms:

iptables -D INPUT -i tun+ -j DROP
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT

4. Another way to test is to clone the vpn vm, disable the vpn-handler* service (in cloned vm settings window), then start up wg-quick manually and pay attention to the output. This way it will use the default DNS assignment routine. From there, you can run the /usr/lib/qubes/qubes-setup-dnat-to-ns script which should place the correct DNS entries in PR-QBS. Then test DNS access from a downstream vm.

[tasket]

I've gone ahead and used a mullvad trial account to test, and it works. I'm still using Debian 9 to test, but had to upgrade the template kernel to 4.19. I've updated my wg wiki page to reflect this.

[Ranguvar]

Hey, sorry I haven't had a chance to test.

I'd like to get this working with the PVH Qube I have right now, and I'll see if I can.

It looks like the injected DNS functions are ending up below some much larger DNS functions which are taking precedence.

I'm traveling and will be able to test this weekend or next week.

[MaximumViciousDeer]

I'm also having the problem that DNS is not propagated to client VMs.
I've installed WireGuard in a Fedora 30 template VM with the latest kernel (QubesOS/qubes-issues#3591 (comment)).

Testing DNS inside the VPN VM yields the expected results but in the client VMs I see my ISP's DNS instead of the VPN providers DNS. I am currently using Azire VPN.

@tasket regarding your suggestions:
0. Found some messages from qubes-vpn-handler, looked successful.

1. /tmp/wg-quick is a script - what to look for?
2. Not sure how to do this...
3. iptables is complaining "Bad rule" for the first line. How to amend this?
4. I tried this and it doesn't make any difference unfortunately.

Other notes:

• I don't get any up/down notifications for the WireGuard VM like I do for the OVPN VM. Is this missing?
• IPv6 doesn't seem to be working, perhaps related to: https://www.qubes-os.org/doc/networking/#ipv6