Thanks for your reply. While I know that the most common deployment of Pihole is, naturally, a physical RPI device, I am interested in a solution that is 100% self-contained in the machine itself. Admittedly, having the router forward to the Pihole will accomplish network-wide protection for all DHCP clients, but this is an exercise that assumes I have no control of networking outside my own trusted Qubes desktop/laptop. So to put it another way, I *want* all changes to be in Qubes because I'm interested in making this a generalizable solution that requires no additional hardware and no outside network administrative privilege.
I've also put some effort into having mirage forward DNS *through* the firewall from the exterior interface (sys-net's class C address and network manager), but I was hoping for a solution that allowed even greater granularity--and understanding the mirage firewall rules to capture 100% of DNS I think is a perfect way to keep network exposure low and continually trustable. On Saturday, August 15, 2020 at 5:20:33 AM UTC-7 Mike Keehan wrote: > On 8/15/20 9:21 AM, [email protected] wrote: > > I've installed qubes-mirage-firewall 0.7.1 on my Qubes 4.0.3 > > installation and am having trouble isolating my DNS calls with the > > standard rules.ml file. > > > > My configuration looks like this: > > > > sys-net (uplink to router using 1.1.1.1 DNS) > > | sys-mirage > > | - pihole (set to use 8.8.8.8 DNS) > > | - appvm (fedora32) (set to use 10.139.1.1) > > > > The only changes to rules.ml are these: > > > > ... > > let dns_port = 53 > > let dns_provider = Ipaddr.of_string_exn "10.137.0.8" > > ... > > let from_client dns_client (packet : ([`Client of Fw_utils.client_link], > > _) Packet.t) : Packet.action Lwt.t = > > match packet with > > | { dst = `Firewall; transport_header = `UDP header; _ } -> > > if header.Udp_packet.dst_port = dns_port > > then Lwt.return @@ `NAT_to (`External dns_provider, dns_port) > > else Lwt.return @@ `Drop "packet addressed to client gateway" > > ... > > > > My intention is for all DNS requests in AppVM forward to sys-mirage (via > > `Firewall) and be NAT'ted to the Pihole at the provided IP above. > > > > The problem I run into is that I can't seem to *break* the DNS. For > > example, if the Pihole VM is shut down, I would expect DNS to fail. With > > the NAT_to destination unavailable, all AppVMs with sys-mirage should > > stop resolving, correct? I have also tried setting dns_provider to an > > unused ip 10.137.0.x and it still resolves. > > > > When I make DNS queries from the AppVM, it seemingly bypasses the pihole > > despite the `Firewall rule. I can check dnsleaktest and it reports back > > 1.1.1.1 (DNS from my router). If I manually change /etc/resolv.conf on > > the AppVM to 10.137.0.8, it routes through the pihole and operates > > perfectly (dnsleaktest reports back 8.8.8.8). > > > > I notice that with the Pihole down /and/ /etc/resolv.conf modified, DNS > > /does/ break--but the question is: *why isn't ( dst = `Firewall`;... ) > > catching the forwarded **10.139.1.1 and 10.139.1.2** DNS queries from > > AppVM and NAT_to `External dns_provider?* > > * > > * > > Or maybe more directly, what rules are necessary to ensure I catch 100% > > of DNS requests from appvms so that I can route it to the pihole? > > > > Best, > > hexparrot > > > > Just set the Pihole's DNS address in your router's DHCP service, or > use the Pihole's DHCP service. > > I use my Pihole as the DHCP server on my network, then everything on > my network gets the Pihole as the DNS resolver. No changes necessary > on Qubes (nor on any other machine on my network). > > If you do not have DHCP running on your network, you can set up the > DNS resolve address in sys-net's NetworkManager. > > Mike. > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/c9575ecd-32c1-45f5-b652-2bb9d3325fdcn%40googlegroups.com.
