On 03/11/2018 11:21 AM, Chris Laprise wrote:
...and for now omitted the '-d' destination part in iptables.

Then if I issue:

sudo iptables -t nat -F PR-QBS
sudo iptables -t nat -A PR-QBS  -i vif+ -p udp --dport 53 -j DNAT --to $eth0_address sudo iptables -t nat -A PR-QBS  -i vif+ -p tcp --dport 53 -j DNAT --to $eth0_address

it appears to work from a downstream appVM. But I haven't checked yet to see if its really using the dnscrypt proxy; even if it is, the config may need to be adjusted for better security.

I just tested that one (my implementation was also doing pretty much exactly that + a local INPUT chain firewall so it was a 5 min test removing the INPUT firewall):

Since you'll need something like

-I INPUT -p udp -m udp --dport 53 -j ACCEPT
-I INPUT -p tcp -m tcp --dport 53 -j ACCEPT

it makes DNS accessible for all downstream VMs regardless of the qubes-firewall settings, i.e. apprently the nft FORWARD rules are not applied for DNAT to localhost.

That's probably why I had opened that github issue & implemented a local firewall back then...

You can verify my findings by using the dom0 qvm-firewall command line to revoke DNS access for a downstream VM & then use e.g. dig in that VM. The qubes-vm-settings GUI won't work as in 4.0 DNS & ICMP is always allowed.

So yes, if one is aware of that issue, one can certainly use it the way you described. If you rely on the qubes-firewall to work as expected, you shouldn't use it.

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/ba33e227-187d-4945-6b51-d1ef0093d21a%40hackingthe.net.
For more options, visit https://groups.google.com/d/optout.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to