DNS hijacking in 23.05.0 doesn't work

Hello, OpenWRT gurus!

I can't intercept DNS traffic from LAN at OWRT 23.05.0, although rules are created successfully. My router has real "white" IP address, IP v6 is turned off completely.
Config in /etc/config/firewall (as in manual at WIKI page of OWRT):

config redirect 'dns_int'
	option name 'InterceptDNS'
	option src 'lan'
	option src_dport '53'
	option proto 'tcp udp'
	option target 'DNAT'
	option family 'ipv4'

Rules are automatically created in the chain dstnat are:

	chain dstnat_lan {
		meta nfproto ipv4 tcp dport 53 counter packets 0 bytes 0 redirect to :53 comment "!fw4: InterceptDNS"
		meta nfproto ipv4 udp dport 53 counter packets 71 bytes 4717 redirect to :53 comment "!fw4: InterceptDNS"
	}

And it simply doesn't work. I run at client Windows nslookup, set server 1.1.1.1 and see UDP connections to 1.1.1.1:53 realtime. I employed dnsmasq-full with the options

option filter_aaaa '1'
option noresolv '1'
list server '127.0.0.1#5453'

and stubby at 5453 port. There is no DNS leaks if I use router's DNS, but clients can communicate with the remote DNS servers still. How can I fix it?

P.S. I really hate nft. It's damn unobvious and troublesome comparing to iptables.

if these are vanilla port 53 DNS requests, the requestor won't see any differance between replies coming from the IP it was trying to reach, and the router.

temp block some public FQDN in your router, like google.com, then try the nslookup again.

I don't want to block all plain DNS requests. All devices, especially old ones, should work properly. I want to redirect plain DNS requests from all lan to dnsmasq at router (and it should forward it to stubby).
And I see at router in realtime connections to 1.1.1.1:53

seeing this how ?

if you stop stubby, is nslookup still working ?

Are you sure that router itself will show connection in sessions list from client to 1.1.1.1:53 if it is redirected through router itself?

Client's window:

Router's realtime monitoring:

Requests that sent to router's DNS (192.168.1.1) from client's nslookup:


are going through stubby obviously

The procd firewall object I create in adblock-fast is the following:

					json_add_string type redirect
					json_add_string target DNAT
					json_add_string src lan
					json_add_string proto "tcp udp"
					json_add_string src_dport 53
					json_add_string dest_port 53
					json_add_string family any
					json_add_boolean reflection 0

And it results in the slightly different nft rules:

	chain dstnat_lan { # handle 415
		tcp dport 53 counter packets 199 bytes 11880 redirect to :53 comment "!fw4: ubus:adblock-fast[main] redirect 0" # handle 12679
		udp dport 53 counter packets 232354 bytes 15504343 redirect to :53 comment "!fw4: ubus:adblock-fast[main] redirect 0" # handle 12680
	}

Which based on the packet counters seem to work.

It turned out that rule from OWRT wiki is working, although in the realtime connections we can see the nonexistent connections to remote DNSs. How to check that intercept works:

  1. No hijacking rules in /etc/config/firewall or elsewhere.
  2. run at client computer DNS request to blocked content via OpenDNS FamilyShield server: nslookup pornhub.com 208.67.222.123
    It should return smth similar to 146.112.61.106, (IP from OpenDNS address pools)
  3. Insert rule from wiki to /etc/config/firewall:
	option name 'InterceptDNS'
	option enabled '1'
	option src 'lan'
	option src_dport '53'
	option proto 'tcp udp'
	option target 'DNAT'
	option family 'ipv4'

and run in ssh: service firewall restart

  1. run at client computer the same request, it should response to you with smth like to 66.254.114.41 (if you don't use OpenDNS or other family shields at router)
  2. run at client computer request to almost arbitrary IP:
    nslookup cnn.com 128.129.130.131
    and you should get the correct answer to CNN's IPs.
  3. You can block remote DNS requests at all with the rule in /etc/config/firewall
	option name 'BlockDNS'
	option src 'lan'
	option dest 'wan'
	option target 'REJECT'
	option dest_port '53'
	option family 'ipv4'

Frankly speaking, all this mess has sense only in the case if you use additional DNS-over-TLS servers like stubby or DNSCrypt-proxy2 that allow to encrypt DNS requests from the provider/MITM completely. Or if you need to fool devices with hardcoded to the firmware domain names to use local services instead of remote ones (e.g. WiFi radio).

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