AdGuardHome IPTables blocking TLS port 853 from other hosts

[Markfree]

While testing out an AdGuard Home instance on a Docker container, it failed to reach upstream TLS servers.
Upon closer inspection, I traced the packets back to the AX86U router IPTables.

There is a chain called "DNSFILTER_DOT" that is blocking any packet on port 853 that is not destined for host 192.168.7.1.

# iptables -n -L DNSFILTER_DOT
Chain DNSFILTER_DOT (1 references)
target     prot opt source               destination
REJECT     all  --  anywhere            !192.168.7.1     reject-with icmp-port-unreachable

# iptables -S | grep DNSFILTER_DOT
-N DNSFILTER_DOT
-A FORWARD -i br+ -p tcp -m tcp --dport 853 -j DNSFILTER_DOT
-A DNSFILTER_DOT ! -d 192.168.7.1/32 -j REJECT --reject-with icmp-port-unreachable

After changing the rule, the test ADH instance was able to reach upstream TLS servers again.
However, when I searched most of the scripts on the JFFS partition, I could not find where the rule was set.

I think this rule might be related to the router AdGuard Home instance, but I'm not sure why it is included in the ruleset at all.
Any thoughts on why this?

 

[ColinTaylor]

The clue is in the name "DNSFILTER", now known as DNS Director.

DNS Director

Third party firmware for Asus routers (newer codebase) - RMerl/asuswrt-merlin.ng

github.com

 

[Markfree]

I see. Thanks for the tip.

Indeed, DNS Director is the one to blame.
When I switch to global "no redirection", the rule is unset and all requests to port 853 work properly.

However, when global redirection is enabled, packets for port 853 from different hosts are rejected instead of redirected.

Why not redirect them instead?

 

[dave14305]

Why not redirect them instead?

Because of TLS and certificate verification. A redirected DoT query cannot respond with the certificate of the original DoT server the client is expecting to hear back from. That’s why DoT is secure - it can’t be intercepted or subjected to a man-in-the-middle attack.