DNS hijack rule does not apply DNAT reliably

[mark8223]

Describe the bug

Have a DNS hijack rule for IPv6 that DNAT's packets to Google's DNS server as follows:

config redirect
	option dest 'wan'
	option target 'DNAT'
	option name 'Hijack-DNS-IPv6'
	option src 'lan'
	option src_dport '53'
	option dest_ip '2001:4860:4860::8888'
	option family 'ipv6'
	list src_mac '$clientMAC'

Then from an iOS client with iSH shell app, fire off a DNS query to a fictional server that should get hijacked by the rule and DNAT'ed:

nslookup google.com fd::1

This will fire off an A query and an AAAA query very close to each other. Listening with tcpdump on the wan interface of the router you'll see the A query being DNAT'ed, but the AAAA query goes out to the internet still with the original destination (obviously wrong and undesired behavior):

11:53:01.900537 Out ethertype IPv6 (0x86dd), length 92: $clientIPv6.61581 > 2001:4860:4860::8888.53: 27025+ A? google.com. (28)
11:53:01.900584 Out ethertype IPv6 (0x86dd), length 92: $clientIPv6.61581 > fd::1.53: 53025+ AAAA? google.com. (28)

This should not ever happen, as any IPv6 packet on port 53 should be caught by the rule and DNAT'ed.

OpenWrt version

r28427-6df0e3d02a

OpenWrt release

24.10.0

OpenWrt target/subtarget

ramips/mt7621

Device

TP-Link Archer C6U v1

Image kind

Official downloaded image

Steps to reproduce

Install rule as in the example.
Get an iOS phone and install iSH app then fire off an nslookup as above.
I don't know what's special about this client, but it's able to generate the second packet that is not DNAT'ed correctly by the rule. Other Linux-based nslookup clients I have seem to not be able to reproduce this.

Actual behaviour

AAAA query shortly after A query is not DNAT'ed.

Expected behaviour

Both A and AAAA queries should be DNAT'ed.

Additional info

This bug reproduces 100% of the time on 24.10 and 0% of the time on 23.05.

Diffconfig

Terms

• I am reporting an issue for OpenWrt, not an unsupported fork.

[brada4]

Remove dst wan line

[mark8223]

Remove dst wan line

Made no difference.

13:06:38.748218 Out ethertype IPv6 (0x86dd), length 92: $clientIPv6.51902 > 2001:4860:4860::8888.53: 42310+ A? google.com. (28)
13:06:38.748263 Out ethertype IPv6 (0x86dd), length 92: $clientIPv6.51902 > fd::1.53: 2774+ AAAA? google.com. (28)

[brada4]

Did you reload firewall?
Could you share generated fragment from nft list ruleset ?

[egc112]

In addition to @brada4 's advice make sure your iphone has a fixed MAC address and has a working IPv6 GUA address , check with https://test-ipv6.com/

For the record the rules I use are (so without dest 'wan'):

/etc/config/firewall:  
config redirect
	option target 'DNAT'
	option name 'DNSto8888ipv4'
	option src 'lan'
	option src_dport '53'
	option dest_ip '8.8.8.8'
	list src_mac 'D0:AB:D5:92:CC:CC'
	option reflection '0'

config redirect
	option target 'DNAT'
	option name 'DNSto8888ipv6'
	option src 'lan'
	list src_mac 'D0:AB:D5:92:CC:CC'
	option src_dport '53'
	option reflection '0'
	option dest_ip '2001:4860:4860::8888'
	option family 'ipv6'

[mark8223]

@brada4 Yes, I reloaded the firewall.

@egc112 Yes, the client has a IPv6 GUA address, and I get 10/10 on the IPv6 test. $clientIPv6 in the tcpdump excerpts is a GUA address. But this shouldn't matter for this specific case, the router is simply letting a packet through wan that should never ever pass without DNAT. It's a security risk at this point because the rules are not applied consistently.

Once again, my rule with $clientMAC and $clientIPv6 redacted:

config redirect
	option target 'DNAT'
	option name 'Hijack-DNS-IPv6'
	option src 'lan'
	option src_dport '53'
	option dest_ip '2001:4860:4860::8888'
	option family 'ipv6'
	list src_mac '$clientMAC'

nft list ruleset excerpt in 23.05:

	chain dstnat_lan {
		meta nfproto ipv6 tcp dport 53 ether saddr $clientMAC counter packets 0 bytes 0 dnat ip6 to [2001:4860:4860::8888]:53 comment "!fw4: Hijack-DNS-IPv6"
		meta nfproto ipv6 udp dport 53 ether saddr $clientMAC counter packets 0 bytes 0 dnat ip6 to [2001:4860:4860::8888]:53 comment "!fw4: Hijack-DNS-IPv6"
	}

tcpdump excerpt in 23.05 for nslookup google.com fd::1 in iSH app on iOS:

# tcpdump -i pppoe-wan port 53 -nn
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on pppoe-wan, link-type LINUX_SLL (Linux cooked v1), snapshot length 262144 bytes
11:02:26.169572 IP6 $clientIPv6.60444 > 2001:4860:4860::8888.53: 61970+ A? google.com. (28)
11:02:26.169729 IP6 $clientIPv6.60444 > 2001:4860:4860::8888.53: 39435+ AAAA? google.com. (28)

nft list ruleset excerpt in 24.10:

	chain dstnat_lan {
		meta nfproto ipv6 tcp dport 53 ether saddr $clientMAC counter packets 0 bytes 0 dnat ip6 to [2001:4860:4860::8888]:53 comment "!fw4: Hijack-DNS-IPv6"
		meta nfproto ipv6 udp dport 53 ether saddr $clientMAC counter packets 0 bytes 0 dnat ip6 to [2001:4860:4860::8888]:53 comment "!fw4: Hijack-DNS-IPv6"
	}

tcpdump excerpt in 24.10 for nslookup google.com fd::1 in iSH app on iOS:

# tcpdump -i pppoe-wan port 53 -nn
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on pppoe-wan, link-type LINUX_SLL (Linux cooked v1), snapshot length 262144 bytes
11:50:27.586489 IP6 $clientIPv6.63029 > 2001:4860:4860::8888.53: 35905+ A? google.com. (28)
11:50:27.586589 IP6 $clientIPv6.63029 > fd::1.53: 64905+ AAAA? google.com. (28)

It's really easy to repro by almost anyone in a few minutes. It seems deterministic too, doesn't just happen sometimes, it happens every time.

[tmcqueen-materials]

@mark8223 : Can you provide output from tcpdump including the -e option? And the output of nft list ruleset just before and just after a lookup (I want to know if the rules are being hit). I am wondering if something in your config is changing the src mac address before applying the DNAT rule.

I am unable to reproduce this using iSH on iOS 18.4 with 24.10