I have 2 DNS servers inside my network (PiHole) and on my Ubiquiti EdgeRouter I have 2 rules, one that allows my DNS servers out and the second that redirects other IP back to on of my DNS servers on port 53.
Not sure if this is right:
/ip firewall nat
add chain=dstnat dst-port=53 protocol=udp to-addresses=10.10.10.2 action=dst-nat comment="redirect DNS"
So I’ve been playing around with this for a while and I think NAT is redirecting to my PiHole, but the PiHole is not responding.
> ip firewall/nat/print
Flags: X - disabled, I - invalid; D - dynamic
0 ;;; defconf: masquerade
chain=srcnat action=masquerade out-interface-list=WAN ipsec-policy=out,none
1 ;;; Allow DNS servers UDP
chain=srcnat action=masquerade to-ports=53 protocol=udp src-address=10.1.0.2/31 dst-port=53 log=yes log-prefix=""
2 ;;; Allow DNS servers TCP
chain=srcnat action=masquerade to-ports=53 protocol=tcp src-address=10.1.0.2/31 dst-port=53 log=no log-prefix=""
3 ;;; DNS Redirect UDP
chain=dstnat action=dst-nat to-addresses=10.1.0.2 to-ports=53 protocol=udp src-address=!10.1.0.2/31 dst-port=53 log=no log-prefix=""
4 ;;; DNS Redirect TCP
chain=dstnat action=dst-nat to-addresses=10.1.0.2 to-ports=53 protocol=tcp src-address=!10.1.0.2/31 dst-port=53 log=no log-prefix=""
However, when using the Ubiquiti EdgeRouter, the redirects work great and PiHole responds properly to any outgoing IP trying to use port 53. PiHole resolves it and responds. Tested using ‘dig’ on a couple of linux desktops.
But when I switch back to the Mikrotik router, I see the request in the PiHole logs but dig timesout.
The NAT rules look the same to me. What am I missing?
You can always enable logging and to see what is happening there.
I have similar rules, but also a FORWARD rule to allow the Pihole(s) to make lookups to the outside world to the 2 upstream DNS I configured.
All your clients / systems are in the 10.1.0.x “LAN” ?
I would say your missing the part of who is being redirected here…
/ip firewall nat
add chain=dstnat dst-port=53 protocol=udp to-addresses=10.10.10.2 action=dst-nat comment=“redirect DNS” (src-address=subnet??? src-address-list=???)
ahh I see you have addressed that in your later post… I still prefer to use a firewall address list called EXCLUDED, of which are at least the pi server itself, and any other IPs not requiring redirection…
However I dont understand the purpose of these.
1 ;;; Allow DNS servers UDP
chain=srcnat action=masquerade to-ports=53 protocol=udp src-address=10.1.0.2/31 dst-port=53 log=yes log-prefix=“”
2 ;;; Allow DNS servers TCP
chain=srcnat action=masquerade to-ports=53 protocol=tcp src-address=10.1.0.2/31 dst-port=53 log=no log-prefix=“”
However with these above 2 rules AND “log=yes” perhaps some insight can be gained IF the upstream DNS-lookup from the Pihole actually reaches this stage.
So what do the LOGS tell you ?
So after some more work and thinking, I found a site that reminded me why I have rules 1 and 2. And, surprise, I was using them wrong. Here’s my current setup:
0 ;;; defconf: masquerade
chain=srcnat action=masquerade out-interface-list=WAN ipsec-policy=out,none
1 ;;; Rewrite DNS lookups UDP
chain=srcnat action=masquerade to-ports=53 protocol=udp dst-address=10.1.0.2 dst-port=53 log=yes log-prefix=""
2 ;;; Rewrite DNS lookups TCP
chain=srcnat action=masquerade to-ports=53 protocol=tcp dst-address=10.1.0.2 dst-port=53 log=no log-prefix=""
3 ;;; DNS Redirect UDP
chain=dstnat action=dst-nat to-addresses=10.1.0.2 to-ports=53 protocol=udp src-address=!10.1.0.2/31 dst-port=53
log=yes log-prefix=""
4 ;;; DNS Redirect TCP
chain=dstnat action=dst-nat to-addresses=10.1.0.2 to-ports=53 protocol=tcp src-address=!10.1.0.2/31 dst-port=53
log=no log-prefix=""
This site: https://jeff.vtkellers.com/posts/technology/force-all-dns-queries-through-pihole-with-openwrt/
Is where I remembered I needed rules 1/2 for helping to fool client devices into thinking their DNS server choice was what actually responded.
And, this seems to kind of work. However, it’s intermittent. Sometimes dig is getting a timeout, sometimes it goes through instantly. Here’s a log for those rules.
In this example, the first one responded in 0ms. Then ran dig immediatly again and got 3 timeouts.
2025-05-04 16:48:46 firewall,info dstnat: in:bridge out:(unknown 0), connection-state:new src-mac 55:4a:a4:fc:88:1b, proto UDP, 10.1.0.20:54910->1.2.3.4:53, len 84
2025-05-04 16:48:46 firewall,info srcnat: in:bridge out:bridge, connection-state:new,dnat src-mac 55:4a:a4:fc:88:1b, proto UDP, 10.1.0.20:54910->10.1.0.2:53, NAT 10.1.0.20:54910->(1.2.3.4:53->10.1.0.2:53), len 84
2025-05-04 16:48:59 firewall,info dstnat: in:bridge out:(unknown 0), connection-state:new src-mac 55:4a:a4:fc:88:1b, proto UDP, 10.1.0.20:37091->1.2.3.4:53, len 84
2025-05-04 16:48:59 firewall,info srcnat: in:bridge out:bridge, connection-state:new,dnat src-mac 55:4a:a4:fc:88:1b, proto UDP, 10.1.0.20:37091->10.1.0.2:53, NAT 10.1.0.20:37091->(1.2.3.4:53->10.1.0.2:53), len 84
2025-05-04 16:49:04 firewall,info dstnat: in:bridge out:(unknown 0), connection-state:new src-mac 55:4a:a4:fc:88:1b, proto UDP, 10.1.0.20:38934->1.2.3.4:53, len 84
2025-05-04 16:49:04 firewall,info srcnat: in:bridge out:bridge, connection-state:new,dnat src-mac 55:4a:a4:fc:88:1b, proto UDP, 10.1.0.20:38934->10.1.0.2:53, NAT 10.1.0.20:38934->(1.2.3.4:53->10.1.0.2:53), len 84
2025-05-04 16:49:09 firewall,info dstnat: in:bridge out:(unknown 0), connection-state:new src-mac 55:4a:a4:fc:88:1b, proto UDP, 10.1.0.20:58143->1.2.3.4:53, len 84
2025-05-04 16:49:09 firewall,info srcnat: in:bridge out:bridge, connection-state:new,dnat src-mac 55:4a:a4:fc:88:1b, proto UDP, 10.1.0.20:58143->10.1.0.2:53, NAT 10.1.0.20:58143->(1.2.3.4:53->10.1.0.2:53), len 84