Mirage Firewall with separate DNS

49 views
Skip to first unread message

wdchr...@gmail.com

unread,
Aug 15, 2020, 4:21:08 AM8/15/20
to qubes-users
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

Mike Keehan

unread,
Aug 15, 2020, 8:20:33 AM8/15/20
to qubes...@googlegroups.com
On 8/15/20 9:21 AM, wdchr...@gmail.com 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.

wdchr...@gmail.com

unread,
Aug 15, 2020, 3:24:42 PM8/15/20
to qubes-users
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.
Reply all
Reply to author
Forward
0 new messages