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-QBSsudo 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_addressit 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 ACCEPTit 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 email@example.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.
Description: S/MIME Cryptographic Signature