New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open

marmarek opened this Issue Sep 10, 2015 · 11 comments

Member

marmarek commented Sep 10, 2015

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.

marmarek added bug C: core P: minor labels Sep 10, 2015

marmarek added this to the Release 3.0 milestone Sep 10, 2015

marmarek modified the milestones: Release 3.0 updates, Release 3.0 Oct 8, 2015

This comment has been minimized.

Show comment

Hide comment

3hhh Nov 3, 2016

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 commented Nov 3, 2016 •

edited

Edited 1 time

3hhh edited Nov 3, 2016 (most recent)

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 commented Nov 3, 2016 •

edited

Edited 1 time

3hhh edited Nov 3, 2016 (most recent)

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 modified the milestones: Release 3.0 updates, Release 3.1 updates Nov 19, 2016

Member

marmarek commented Nov 28, 2016

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

marmarek modified the milestones: Release 4.0, Release 3.1 updates Nov 28, 2016

This comment has been minimized.

Show comment

Hide comment

tasket Apr 16, 2017

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 commented Apr 16, 2017 •

edited

Edited 1 time

tasket edited Apr 16, 2017 (most recent)

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 commented Apr 16, 2017

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

tasket added a commit to tasket/Qubes-vpn-support that referenced this issue Apr 28, 2017


      Fix NS IPs per QubesOS/qubes-issues#1183

dc20b40

tasket commented Apr 28, 2017

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 commented Jun 19, 2017

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 commented Jun 19, 2017

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 commented Jun 19, 2017

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 commented Aug 27, 2017

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

Member

marmarek commented Aug 27, 2017

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,

andrewdavidwong modified the milestones: Release 4.0, Release 4.0 updates Mar 31, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

You can’t perform that action at this time.