Firewall rule 'Allow DNS queries' does not take into account custom (VPN) DNS server

[marmarek]

https://groups.google.com/d/msg/qubes-users/EPe4U0kF67A/CJfHD245KwAJ

There appears to be a bug in Qubes firewall dns forwarding after
'qubes-setup-dnat-to-ns' is called to update the nat PR-QBS chain /and/
there are 'Deny except...' whitelist rules added from a connected
(downstream) appvm.

The destination addresses in the Qubes-generated dpt:domain rules in the
FORWARD chain remain their old direct-to-netvm values instead of getting
updated to the vpn addresses. So those nat'd dns packets keep hitting the
'reject-with icmp-host-prohibited' rule since they are never matched and
accepted above.

The firewall might need to be fixed so that whatever new dns addresses are
picked up by 'qubes-setup-dnat-to-ns', the dpt:domain rules in FORWARD are
also changed to look for those addresses.

Reported by theman, cprise.

[3hhh]

Still valid in 3.2.

(all in VPN VM:)

Example:
FORWARD chain in VPN proxy VM (10.137.4.1):
0 0 ACCEPT udp -- * * 10.138.4.3 10.137.2.1 udp dpt:53
0 0 ACCEPT udp -- * * 10.138.4.3 10.137.2.254 udp dpt:53
0 0 ACCEPT tcp -- * * 10.138.4.3 10.137.2.1 tcp dpt:53
0 0 ACCEPT tcp -- * * 10.138.4.3 10.137.2.254 tcp dpt:53

(10.137.2.1 = firewallVM used by the VPN VM as netvm)

iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
PR-QBS all -- anywhere anywhere
PR-QBS-SERVICES all -- anywhere anywhere

Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
MASQUERADE all -- anywhere anywhere

Chain PR-QBS (1 references)
target prot opt source destination
DNAT udp -- anywhere 10.137.4.1 udp dpt:domain to:[VPN-SERVER-DNS-IP]
DNAT tcp -- anywhere 10.137.4.1 tcp dpt:domain to:[VPN-SERVER-DNS-IP]

Chain PR-QBS-SERVICES (1 references)
target prot opt source destination

All of that after setting resolv.conf to [VPN-SERVER-DNS-IP] and a manual call to /usr/lib/qubes/qubes-setup-dnat-to-ns .

route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.50.0.1 128.0.0.0 UG 0 0 0 tun0
0.0.0.0 10.137.2.1 0.0.0.0 UG 0 0 0 eth0
10.50.0.0 0.0.0.0 255.255.0.0 U 0 0 0 tun0
10.137.2.1 0.0.0.0 255.255.255.255 UH 0 0 0 eth0
10.137.4.14 0.0.0.0 255.255.255.255 UH 32740 0 0 vif12.0
10.137.4.16 0.0.0.0 255.255.255.255 UH 32743 0 0 vif9.0
10.138.4.3 0.0.0.0 255.255.255.255 UH 32744 0 0 vif8.0
10.138.4.4 0.0.0.0 255.255.255.255 UH 32741 0 0 vif11.0
10.138.4.5 0.0.0.0 255.255.255.255 UH 32739 0 0 vif13.0
10.138.4.6 0.0.0.0 255.255.255.255 UH 32738 0 0 vif14.0
127.0.0.1 10.137.2.1 255.255.255.255 UGH 0 0 0 eth0
128.0.0.0 10.50.0.1 128.0.0.0 UG 0 0 0 tun0

[3hhh]

workaround:
iptables-save | sed -r 's/10.137.2.1/32/[VPN-SERVER-DNS-IP]/32/g'|iptables-restore fixes the issue until the qubes firewall refreshes (can be persisted using /rw/config/qubes-firewall-user-script)

[marmarek]

This is already handled in Qubes 4.0 (as part of #1815 ). But it isn't feasible for backport to R3.2 unfortunately.

[tasket]

Comprehensive regex to fix the FORWARD chain, per @3hhh suggestion:

sed -r 's/(-A FORWARD.+ -d )10\.137\.[0-9]+\.1(\/32 .+--dport 53 -j ACCEPT)$/\1'$DNS1'\2/'
sed -r 's/(-A FORWARD.+ -d )10\.137\.[0-9]+\.254(\/32 .+--dport 53 -j ACCEPT)$/\1'$DNS2'\2/'

This could be added to both qubes-firewall-user-script and qubes-vpn-handler.

[tasket]

Should also investigate possibility of re-populating /var/run/qubes/qubes-ns with new DNS addresses.

[tasket]

Committed a fix for this in my VPN project. This can be added to the VPN doc as well.
(It also removes one editing step.)

[tasket]

I'm thinking this could be fixed in R3.2.x and maybe the best overall way is to use an additional file like /var/run/qubes/qubes-tun-ns to hold the tunnel's DNS addresses. This can be used by the firewall if it exists.

Another way is to put the sed code from my script into qubes-setup-dnat-to-ns, which is even triggered by Network Manager for VPN connections. Doing it this way would make stuff 'just work' with either scripted or NM connection methods.

[3hhh]

The sed solution was a mere hack and should never make it into any proper OS design.

Moreover it only works if you switch the "Allow DNS queries" checkbox even if you allow all network traffic (which is different from the standard Qubes OS behavior).

[tasket]

Correct, it only works under that condition but that's because the purpose is to prevent unnecessary blocking of DNS. Using sed seems hackish, but I noticed this elsewhere in Qubes so figured it wasn't too bad.

OTOH, the other solution just imitates what is done with /var/run/qubes/qubes-ns, seems simpler.

[3hhh]

This is somewhat fixed in 4.0rc1 as the dynamic iptables rules in proxyVMs were removed entirely, i.e. custom DNS servers should work.

Only drawback: Local DNS servers are affected by #3051

[marmarek]

the dynamic iptables rules in proxyVMs were removed entirely, i.e. custom DNS servers should work.

This is not true. There are moved into nftables. And they do support custom dns (based on what you have in /etc/resolv.conf). See specialtarget=dns here,

[github-actions]

This issue is being closed because:

• This issue is on the "Release 4.0 updates" milestone.
• Qubes OS 4.0 reached EOL (end-of-life) over one year ago.
• There has not been any activity on this issue in over one year.

If anyone believes that this issue should be reopened and reassigned to an active milestone, please leave a brief comment.
(For example, if a bug still affects Qubes OS 4.1, then the comment "Affects 4.1" will suffice.)