QubesOS / qubes-issues

The Qubes OS Project issue tracker
https://www.qubes-os.org/doc/issue-tracking/
533 stars 46 forks source link

Strange issue with custom DNS (dnscrypt-based) after moving to 4.2 #9357

Closed oddgirl closed 2 months ago

oddgirl commented 2 months ago

How to file a helpful issue

Qubes OS release

4.2 fresh install, fully updated

Brief summary

I am trying to run custom DNS for my VPN qubes, most systems work as expected however, DNS just refuses to work

Iptraf-ng based observation suggests that something, somewhere sends ICMP unreachable for port 53

Steps to reproduce

Configure a setup that goes like

[app-vm]-[dedicated cloned firewall vm]-[VPN-vm WITH DNSCRYPT]-internet

verify that it works okay without DNS crypt.

Try redirecting forwarded packets on port 53 to DNS crypt in the firewall VM (which worked in Qubes 3.2, 4.0 and 4.1)

Expected behavior

DNS to work through DNS crypt

Actual behavior

DNS times out

Iptraf NG suggests odd behavior related to ICMP

Behavior is as follows:

in app vm

nslookup arghebar.com 8.8.8.8

Now, in firewall and VPN VM iptraf is running and hence we observe:

in firewall VM

│ UDP (58 bytes) from 10.137.0.10:46229 to 8.8.8.8:53 on vif16.0 │ │ UDP (58 bytes) from 10.137.0.33:46229 to 8.8.8.8:53 on eth0 │ │ ICMP dest unrch (host comm denied) (86 bytes) from 8.8.8.8 to 10.137.0.33 on eth0 │ │ ICMP dest unrch (host comm denied) (86 bytes) from 8.8.8.8 to 10.137.0.10 on vif16.0

in VPN vm │ IUDP (58 bytes) from 10.137.0.33:60285 to 8.8.8.8:53 on vif15.0 │ │ ICMP dest unrch (host comm denied) (86 bytes) from 8.8.8.8 to 10.137.0.33 on vif15.0
│ UDP (58 bytes) from 10.137.0.33:60285 to 8.8.8.8:53 on vif15.0 │ │ ICMP dest unrch (host comm denied) (86 bytes) from 8.8.8.8 to 10.137.0.33 on vif15.0
│ ICMP dest unrch (host comm denied) (86 bytes) from 8.8.8.8 to 10.137.0.33 on vif15.0

Which is extremely odd

Everything worked extraordinarily well on older qubes

P.S.: obviously I've overriden "classic" Qubes nat-to-NS to point to my DNS crypt in the VPN vm machine

In VPN vm rules are:

Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination
120 7529 DNAT udp -- 10.137.0.33 0.0.0.0/0 udp dpt:53 to:127.0.0.1:53

And, like I said it used to work ?

ben-grande commented 2 months ago

This is a support question, please refer to other venues. Apparently you are using iptables, qubes switched to nftables.

oddgirl commented 2 months ago

This is a support question, please refer to other venues. Apparently you are using iptables, qubes switched to nftables.

Ah well... thanks for prompt reply

It actually seems that nftables stuff is to blame (edited in)

I will post my workaround here later

github-actions[bot] commented 2 months ago

This issue has been closed as "not applicable." Here are some common examples of cases in which issues are closed as not applicable:

We respect the time and effort you have taken to file this issue, and we understand that this outcome may be unsatisfying. Please accept our sincere apologies and know that we greatly value your participation and membership in the Qubes community.

Regarding help and support requests, please note that this issue tracker (qubes-issues) is not intended to serve as a help desk or tech support center. Instead, we've set up other venues where you can ask for help and support, ask questions, and have discussions. By contrast, the issue tracker is more of a technical tool intended to support our developers in their work. We thank you for your understanding.

If anyone reading this believes that this issue was closed in error or that the resolution of "not applicable" is not accurate, please leave a comment below saying so, and we will review this issue again. For more information, see How issues get closed.