DNS Director not properly redirecting DNS traffic to router

[ArbitraryLake]

I've recently put Merlin (3006.102.6) on my RT-BE92U router with AdGuardHome running locally via amtm. Thanks to all for the great product. I have the main network at 192.168.2.0/24 and 2 other isolated networks on 192.168.52/24 and 192.168.53.0/24 for IoT and guests. Everything is working great except forcing port 53 DNS requests to go through AdGuardHome. If a client is setup to talk to 192.168.2.1, 192.168.52.1, or 192.168.53.1, respectively, which DHCP does, it works as expected. The problem is if you have a hardcoded DNS server on the client and then it isn't working. The query is redirected to the router's DNS server (so redirected from 8.8.8.8 to 192.168.2.1, for instance), but the reply comes from 192.168.2.1 and it isn't rewritten to look like it is coming from 8.8.8.8. Thus, the packet is listed as unsolicited and ignored. Below is the lots of detail if that is helpful, but if this is an easy fix feel free to ignore.

I ran nslookup on a Windows computer, changed the server to 8.8.8.8 and queried for redhat.com

Default Server:  RT-BE92U-EF20.local
Address:  192.168.2.1

> server 8.8.8.8
Default Server:  dns.google
Address:  8.8.8.8

> redhat.com
Server:  dns.google
Address:  8.8.8.8

DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
*** Request to dns.google timed-out

WireShark shows the 4 queries 192.168.2.7 to 8.8.8.8, but the replies come back from 192.168.2.1 instead of 8.8.8.8. I was expecting the reply src address to be rewritten to 8.8.8.8.

Running tcpdump -i br0 -n -vv 'port 53 and host 192.168.2.7' on the router yields

tcpdump: listening on br0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
17:57:31.832013 IP (tos 0x0, ttl 128, id 601, offset 0, flags [none], proto UDP (17), length 62)
    192.168.2.7.49235 > 8.8.8.8.53: [udp sum ok] 55+ A? redhat.com.local. (34)
17:57:31.834188 IP (tos 0x0, ttl 64, id 4524, offset 0, flags [DF], proto UDP (17), length 62)
    192.168.2.1.53 > 192.168.2.7.49235: [bad udp cksum 0x8594 -> 0xe379!] 55 NXDomain q: A? redhat.com.local. 0/0/0 (34)
17:57:33.833144 IP (tos 0x0, ttl 128, id 602, offset 0, flags [none], proto UDP (17), length 62)
    192.168.2.7.49236 > 8.8.8.8.53: [udp sum ok] 56+ AAAA? redhat.com.local. (34)
17:57:33.835222 IP (tos 0x0, ttl 64, id 5813, offset 0, flags [DF], proto UDP (17), length 62)
    192.168.2.1.53 > 192.168.2.7.49236: [bad udp cksum 0x8594 -> 0xe35c!] 56 NXDomain q: AAAA? redhat.com.local. 0/0/0 (34)
17:57:35.847030 IP (tos 0x0, ttl 128, id 603, offset 0, flags [none], proto UDP (17), length 56)
    192.168.2.7.49237 > 8.8.8.8.53: [udp sum ok] 57+ A? redhat.com. (28)
17:57:35.848786 IP (tos 0x0, ttl 64, id 6854, offset 0, flags [DF], proto UDP (17), length 88)
    192.168.2.1.53 > 192.168.2.7.49237: [bad udp cksum 0x85ae -> 0xd5fc!] 57 q: A? redhat.com. 2/0/0 redhat.com. A 52.200.142.250, redhat.com. A 34.235.198.240 (60)
17:57:37.861334 IP (tos 0x0, ttl 128, id 604, offset 0, flags [none], proto UDP (17), length 56)
    192.168.2.7.49238 > 8.8.8.8.53: [udp sum ok] 58+ AAAA? redhat.com. (28)
17:57:37.862695 IP (tos 0x0, ttl 64, id 8436, offset 0, flags [DF], proto UDP (17), length 121)
    192.168.2.1.53 > 192.168.2.7.49238: [bad udp cksum 0x85cf -> 0x84f9!] 58 q: AAAA? redhat.com. 0/1/0 ns: redhat.com. SOA dns1.p01.nsone.net. hostmaster.nsone.net. 1684376201 200 7200 1209600 3600 (93)

Here, the responses have bad udp checksums and the unmodified 192.168.2.1 reply src addresses as well. Not sure why the checksum is bad. Below is the conntrack -E output grep'ed for port=53 and 192.168.2.7 at the same time on the router:

    [NEW] udp      17 30 src=192.168.2.1 dst=192.168.2.7 sport=53 dport=49235 [UNREPLIED] src=192.168.2.7 dst=192.168.2.1 sport=49235 dport=53
    [NEW] udp      17 30 src=192.168.2.1 dst=192.168.2.7 sport=53 dport=49236 [UNREPLIED] src=192.168.2.7 dst=192.168.2.1 sport=49236 dport=53
    [NEW] udp      17 30 src=192.168.2.1 dst=192.168.2.7 sport=53 dport=49237 [UNREPLIED] src=192.168.2.7 dst=192.168.2.1 sport=49237 dport=53
    [NEW] udp      17 30 src=192.168.2.1 dst=192.168.2.7 sport=53 dport=49238 [UNREPLIED] src=192.168.2.7 dst=192.168.2.1 sport=49238 dport=53

The conntrack results are also wierd because the AdGuardHome DNS server clearly gets the queries because it replies, but I don't see the tracking for the queries in the conntrack output. I only see the DNS replies as NEW items and no rewriting of the src to 8.8.8.8. I thought at one point I had the queries getting logged in conntrack, but in that case the replies weren't there or at least connected to the queries.

More details:

I've tried User Defined DNS 1 with that set to 192.168.2.1 and that didn't change the results.

I'm getting packets back, so I'm not worried about iptables firewalling, but can provide iptables dump if desired. I have some port forwarding setup, but no other specified firewall rules and nothing added via the post-conf scripts or such.
The iptables nat looks like this where I tried it with and without the line I added in DNSFilter noted below (from iptables -t nat -S)

-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
...
-A PREROUTING -d(external IP addr)/32 -j VSERVER
-A PREROUTING -i br+ -p udp -m udp --dport 53 -j DNSFILTER
-A PREROUTING -i br+ -p tcp -m tcp --dport 53 -j DNSFILTER
-A PREROUTING -i wgs1 -p udp -m udp --dport 53 -j DNSFILTER
-A PREROUTING -i wgs1 -p tcp -m tcp --dport 53 -j DNSFILTER
-A POSTROUTING -o eth0 -j PUPNP
-A POSTROUTING ! -s (external IP addr)/32 -o eth0 -j MASQUERADE
-A POSTROUTING -s 192.168.2.0/24 -d 192.168.2.0/24 -o br0 -j MASQUERADE
-A POSTROUTING -s 192.168.52.0/24 -d 192.168.52.0/24 -o br55 -j MASQUERADE
-A POSTROUTING -s 192.168.53.0/24 -d 192.168.53.0/24 -o br56 -j MASQUERADE
-A DNSFILTER -m mac --mac-source (No Redirection MAC) -j RETURN
-A DNSFILTER -i br0 -j DNAT --to-destination 192.168.2.1 (added, but tried without first)
-A DNSFILTER -i br55 -j DNAT --to-destination 192.168.52.1
-A DNSFILTER -i br56 -j DNAT --to-destination 192.168.53.1
-A DNSFILTER -j REDIRECT
-A LOCALSRV -p udp -m udp --dport 51820 -j ACCEPT
-A VSERVER -p tcp -m tcp --dport xxx -j DNAT --to-destination 192.168.2.x:xxx
-A VSERVER -p tcp -m tcp --dport xxx -j DNAT --to-destination 192.168.2.x:xxx
-A VSERVER -p tcp -m tcp --dport xxx -j DNAT --to-destination 192.168.2.x:xxx
-A VSERVER -j VUPNP

I added the 2nd DNSFILTER line to make sure other anything headed to port 53 tcp/udp is DNAT'ed to 192.168.2.1, Then there is masquerading setup for 182.168.2.0 addresses. I tried more generic masquerading, too without luck.

Everything looks right to me though I'm not an expert, and it isn't doing what I had hoped. I want it to take any port 53 traffic and reroute it to the AdGuardHome server running on the router. Any suggestions would be appreciated. I'm happy to include any missing information or run any tests requested.

EDIT: I guess the bad checksums are common from tcpdump and typically false positives, so that's probably not problem.

 

[ColinTaylor]

DNS Director doesn't change the source IP in the reply. The query is redirected to 192.168.2.1 so that's where the reply comes from. So it appears to be working as designed.

That said, I don't know why your nslookup fails when your tcpdump clearly shows a valid reply.