Additional Firewall Rules required for correct DoH with Dnsmasq and https-dns-proxy Setup?

I am planning to implement DoH with Dnsmasq and https-dns-proxy on a router with Openwrt 23.05.3:

https://openwrt.org/docs/guide-user/services/dns/doh_dnsmasq_https-dns-proxy

Beside the normal LAN interface, I have created a separate Guest LAN interface to restrict management access to the router for connecting hosts. The Guest LAN creatoon required an additional firewall zone to allow forwarding to destination zone WAN and set 2 new traffic rules for DHCP (port 67) and DNS (port 53) for the guest lan interface.

I found the following short tutorial that explains the setup of DoH in OpenWRT:

However, I am wondering about the custom firewall rules that the author is adding to OpenWRT:

iptables -t nat -A PREROUTING -i br-lan -p udp --dport 53 -j DNAT --to 192.168.1.1:5053
iptables -t nat -A PREROUTING -i br-lan -p tcp --dport 53 -j DNAT --to 192.168.1.1:5053
ptables -t nat -A PREROUTING -i br-lan -p udp --dport 53 -j DNAT --to 192.168.1.1:5054
iptables -t nat -A PREROUTING -i br-lan -p tcp --dport 53 -j DNAT --to 192.168.1.1:5054

The OpenWRT Wiki documentation for DoH does not mention that the firewall rules need to be adjusted with the mentioned settings to get this setup working.

Are those custom firewall rules really required for correct DoH setup?

Thanks for your feedback!

You need to back DNAT rule with ct status dnat accept which is done automatically if you set rule in fw4/fw3 via luci.
Those rules divert external DNS requests to your doh proxy. Could be (better) they divert to dnsmasq.

But why is the OpenWRT Wiki documentation on DoH not mentioning those custom firewall rules?

Shouldn't Dnsmasq automatically forward DNS queries to https-dns-proxy for encryption?

Do these custom firewall rules really have to be set manually as the YouTube tutorial suggests?

I used to use that rule on my openwrt router just to "hijack" dns requests.

On my 23.05.2 openwrt router using fw4 I have a single traffic rule that targets anything going to port 53/853 and diverts it to my upstream dns resolver (pihole) which then resolves all external dns traffic with doh. Then I am using banIP to target dns IPs (8.8.8.8 for example) to block those dns requests.

I am doing it this way to keep my openwrt router as the router/firewall/dhcp server for all the vlans and I have offloaded all external dns functions to the pihole. For me this is my preferred way to manage things.

1 Like

It is more like policy thing, if you want to prevent users from using other DNS servers. Not essential to those getting dns address from dhcp

1 Like

Ok, so you're saying that these custom settings are in place as a "catch all" firewall rule to ensure that all DNS request on the entire network on port 53 are properly forwarded to the proxy and no user in the network, intentionally or not, can bypass those DNS redirection settings?

Because they're not necessary. HTTP-DNS-Proxy will, if you set the 'Force DNS' option, create the necessary rules. If you want to do it manually then follow the instructions on the DNS hijacking wiki page (which is linked to on the wiki page you mentioned in the first page).

4 Likes

@krazeh I have left the default settings of the DNS HTTPS PROXY:

Force Router DNS: "Force Router DNS Server to all local devices"

So the previously mentioned custom firewall rules are not required, correct?

I was also wondering about the forwarding rule changes in the DHCP section:

I understand the rule on localhost IP on port 5053 and 5054, but I don't get where the mask icloud and use application dns entries are coming from or for what they are in place?

Also I am only able to use nslookup for a domain without the localhost option:

However, Cloudflare's 1.1.1.1 check and the browser validation test check out fine despite the Secure SNI option:


DNSEC Resolver Test is also ok:

So I assume DoH is configured correctly with the default package options (Cloudflare / Google)?

1 Like
3 Likes
1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.