DNS port open when Pi Hole and dnsmasq setup

Hi all,

I installed Pi Hole (dns ad blocker) on the network with a static ip of 192.168.88.3. DHCP server on the Mikrotik point to 192.168.88.3 as DNS server and so do any of my static IP addresses. I have also added a few NAT rules to force DNS queries to the Pi Hole. My filter and NAT roles below.

Originally, I had filter rules 0-10 on and NAT rules 0-5 (all) on.

Then I noticed that there were some DNS queries made to my Pi Hole from external IP addresses. I also did a port scan using the GRC shields up interface. Port 53 was open.

So I added filter rules 11 and 12 to try to block external DNS queries to port 53.

However even with those rules enabled, GRC still said that my port 53 was open. Please help. What am I doing wrong here?

Filter Rules

 0  D ;;; special dummy rule to show fasttrack counters
      chain=forward action=passthrough 

 1    ;;; defconf: accept established,related,untracked
      chain=input action=accept connection-state=established,related,untracked 

 2    ;;; defconf: drop invalid
      chain=input action=drop connection-state=invalid 

 3    ;;; defconf: accept ICMP
      chain=input action=accept protocol=icmp 

 4    ;;; defconf: drop all not coming from LAN
      chain=input action=drop in-interface-list=!LAN 

 5    ;;; defconf: accept in ipsec policy
      chain=forward action=accept ipsec-policy=in,ipsec 

 6    ;;; defconf: accept out ipsec policy
      chain=forward action=accept ipsec-policy=out,ipsec 

 7    ;;; defconf: fasttrack
      chain=forward action=fasttrack-connection 
      connection-state=established,related 

 8    ;;; defconf: accept established,related, untracked
      chain=forward action=accept 
      connection-state=established,related,untracked 

 9    ;;; defconf: drop invalid
      chain=forward action=drop connection-state=invalid 

10    ;;; defconf:  drop all from WAN not DSTNATed
      chain=forward action=drop connection-state=new 
      connection-nat-state=!dstnat in-interface-list=WAN 

11    ;;; Drop external DNS TCP
      chain=input action=drop protocol=tcp in-interface-list=WAN dst-port=53 
      log=no log-prefix="" 

12    ;;; Drop external DNS UDP
      chain=input action=drop protocol=udp in-interface-list=WAN dst-port=53 
      log=no log-prefix="

NAT rules

Flags: X - disabled, I - invalid, D - dynamic 
 0    ;;; defconf: masquerade
      chain=srcnat action=masquerade out-interface-list=WAN log=no log-prefix="" ipsec-policy=out,none 

 1    chain=dstnat action=dst-nat to-addresses=192.168.88.3 protocol=udp src-address=!192.168.88.3 
      dst-address=!192.168.88.3 dst-port=53 log=no log-prefix="" 

 2    chain=dstnat action=dst-nat to-addresses=192.168.88.3 protocol=tcp src-address=!192.168.88.3 
      dst-address=!192.168.88.3 dst-port=53 log=no log-prefix="" 

 3    chain=srcnat action=masquerade protocol=udp src-address=192.168.88.0/24 dst-address=192.168.88.3 dst-port=53 
      log=no log-prefix="" 

 4    chain=srcnat action=masquerade protocol=tcp src-address=192.168.88.0/24 dst-address=192.168.88.3 dst-port=53 
      log=no log-prefix="" 

 5    ;;; Plex MSI
      chain=dstnat action=dst-nat to-addresses=192.168.88.51 to-ports=32400 protocol=tcp 
      dst-address=[MY PUBLIC IP] in-interface=ether1 dst-port=32401 log=no log-prefix=""

Filter rule order matters. Packets are matched against rules from top to bottom until first match. If none of rules match, packets are accepted (implicit rule).

Since you have a rule in your firewall that blocks all the input traffic that is not coming from your Lan then DNS queries will be blocked too. As far as the Mikrotik is concerned.
In case you were missing the above rule, your drop rules should be placed on top of the firewall and not at the end as you have them now.
However, the dns requests as you say, reach the pi.That is not an input chain but a forward chain…!
So you should add a drop forward rule with dst address the pi and block the DNS requests coming from the Wan interface.

Thanks for the reply. I think I am just dont understand how the filter rules work.

I tried another solution which worked by specifying in the NAT rules that the dnsnat rules should be coming from the local interface only. That worked.

That seems to suggest to me that the NAT rules take precedence over the filter rules?