Leaky DNS, guest zone can resolve ip's in trusted subnet

Installing and Using OpenWrt
1

Hi,

I have created a "guest" firewall zone that I have associated with my Guest WiFi acording to some (ancient?) guide I found on the old OpenWRT site.

Guest network is on subnet 192.168.3.x and trusted stuff is on 192.168.0.x.
Everything works fine and I cannot ping stuff on 192.168.0.x from 192.168.3.x guest zone.
But then I tried a nmap port scan from my "isolated" guest zone and it says that port 53 is open on every active device in trusted zone.

So basically, a guest WiFi client having IP 192.168.3.100 and running nmap says it found port 53 open on my PC on 192.168.0.100 and can resolve its name. (it cannot do much else though)

I suppose this is some DNS configuration that I missed. How do I prevent my DNS from "leaking" information on what devices are available on my other (trusted) subnet?

Thanks.

P.S. I also have Adblock installed on the router which does some port forwarding on port 53. Can this be the issue?

1 Like
2

Please post here the output of the following command, copy and paste the whole block:

uci export network; uci export wireless; \
uci export dhcp; uci export firewall; \
head -n -0 /etc/firewall.user; \
iptables-save -c ; \
ip -4 addr ; ip -4 ro ; ip -4 ru; \
ls -l  /etc/resolv.* /tmp/resolv.*; head -n -0 /etc/resolv.* /tmp/resolv.*

Please use "Preformatted text </>" for logs, scripts, configs and general console output.
grafik
Remove any sensitive data from the output, like passwords, wifi keys, etc

3

I vaguely remember that this setting in DHCP controls this behaviour:

image
image1428×172 14.4 KB

4

Thanks. I checked this but it is still resolving IP's "on the other side". Do I also need to restart router after enabling this setting?

Also, this is added by Adblock:

adblockCapture
adblockCapture1032×466 53.2 KB

5

Then I am not sure. Just provide the data asked earlier.

6

Likely it's the Adblock rules. My guess is that it redirects dns queries to local OpenWrt box and blocking ads by blocking their domain name resolution. Maybe editing the "From any host" to "From trusted zone" can verify if it is the case.

7

Unfortunately, it is not the case. I tried disabling the top two rules and DNS is still able to resolve addreses in trusted zone :frowning: Can I somehow force DNS to "forget" everything in 192.168.x.x subnet?

8

OK, I have been doing some more investigations. The reason I have port 53 "open" on just about any internal IP is because I am eforcing router DNS:

iptables -t nat -I PREROUTING -p tcp --dport 53 -j REDIRECT --to-ports 53
iptables -t nat -I PREROUTING -p udp --dport 53 -j REDIRECT --to-ports 53

So if I can just somehow prevent DNS from providing names of stuff within trusted zone I am OK.

9

Sorry to necro this thread, but I ran into this now. It appears the fix is to define separate dnsmasq instances, one per isolated network (maybe this wasn't possible back in 2020, I don't know).

The details are documented on the wiki, under the heading "Multiple DHCP/DNS server/forwarder instances".

If you do this with LUCI, note that you not only need to disable wildcard and add interfaces to listen to, you also need to add loopback to the list of excluded interfaces (otherwise all the instances will try to listen to loopback and conflict with each other). Though one instance should listen to loopback or local DNS resolution on the router itself (for e.g. NTP) won't work.

Hopefully it helps anyone else who gets this thread as the first google result.

EDIT: This doesn't actually quite work, it appears all the hosts with static leases are available to every subnet, just suffixed with their own domains (e.g. mycomputer.lan is now available in DNS as mycomputer.guest). The fix is to set the "instance" option on each static lease to restrict it to only that dnsmasq instance.