NAT redirect - DNS timeout

[jbernardo]

Hello,
I have a working setup with a pi-hole doing DHCP+DNS and using the opnsense unbound as upstream DNS server. DNS queries are fast, everything works, ads/malware/telemetry is blocked by the pi-hole.
Next step for me would be to redirect any queries from my LAN to any DNS server other than the pi-hole.For that, I added a "Destination NAT" rule, with protocol TCP/UDP, any destination/port DOMAIN (53), redirect target IP - the IP of the pi-hole, target port DOMAIN (53), inverted source my pi-hole IP.
Now, queries to any DNS server outside the LAN show as "RDR" in the log, and appear in the pi-hole query log. But, the query result never makes it back to dig or nslookup, it always ends with ";; communications error to 1.1.1.1#53: timed out"
What am I missing here? Do I need a firewall rule?
Thank you.

[nero355]

See here : https://forum.opnsense.org/index.php?topic=9245.msg259581#msg259581

And for more 'TIPS & HINTS' that topic in general ofcourse :)

[BrandyWine]

The pi @ 1.1.1.1 is inside on LAN net? So the initial request wants to head out the WAN but it gets dst NAT'd to 1.1.1.1.
Ok, so what happened to the SRC address?

SRC wanted DNS from 9.9.9.9, but the fw sent it to 1.1.1.1. SRC tcp/ip table does not show any connection to 1.1.1.1.

UDP is not a socketless protocol. Try also SRC NAT'ing to use the FW IP itself.

That's my guess.

[jbernardo]

See here : https://forum.opnsense.org/index.php?topic=9245.msg259581#msg259581

And for more 'TIPS & HINTS' that topic in general ofcourse :)

Thanks, I tried but still not working.

[jbernardo]

The pi @ 1.1.1.1 is inside on LAN net? So the initial request wants to head out the WAN but it gets dst NAT'd to 1.1.1.1.
Ok, so what happened to the SRC address?

SRC wanted DNS from 9.9.9.9, but the fw sent it to 1.1.1.1. SRC tcp/ip table does not show any connection to 1.1.1.1.

UDP is not a socketless protocol. Try also SRC NAT'ing to use the FW IP itself.

That's my guess.

1.1.1.1 is cloudflare - the attempt to use it was to check if the redirect worked. The pi-hole is inside the lan network, with a 10.0.0.16 address.
But you were correct - a SRC NAT fixed it, and now I do get 0.0.0.0 responses to blocked dns entries, while dig thinks it is talking to a server other than the pi-hole.
Depending on whether I set the "Translate source IP" to "This firewall" or "any", the pi hole logs now show either the firewall address or a "random" address for the source of the redirected queries, but that is secondary.
Attached is the SRC NAT I added:

[viragomann]

Assuming the pi-hole resides within your LAN, you also need a source NAT rule to hairpin DNS requests from other LAN devices going to the pi-hole:

Interface: LAN
protocol: TCP/UDP
source: LAN network
destination: pi IP
dest. port: 53
translation: LAN address

[jbernardo]

Assuming the pi-hole resides within your LAN, you also need a source NAT rule to hairpin DNS requests from other LAN devices going to the pi-hole:

Interface: LAN
protocol: TCP/UDP
source: LAN network
destination: pi IP
dest. port: 53
translation: LAN address

"translation: LAN address" doesn't seem to work, I get the timeouts again on the client when I try to use a DNS server outside the lan, instead of the redirect. "translation: This firewall" is the one that is working for me now. "translation: any" was working but I changed something while testing and no longer works, timesout.

[meyergru]

Of course it does not work that way, because the Pi itself needs to be excluded from the hairpin rule. Thus, the source for the NAT rule must be something like !DIRECT_DNS_CLIENTS, denoting the negation of a firewall alias containing the IPs of any client that must have direct DNS access.

The Pi's IP must be included in that alias. If it isn't, it cannot reach any upstream DNS servers and thus any DNS request will ultimately fail.

[jbernardo]

I'm already excluding the main pi-hole IP (check the image in my previous post), but you reminded me I should also exclude the IPs of the backup pi-holes, I'll do that now. And of course, the virtual IP for the pi-hole failover.

[viragomann]

Of course it does not work that way, because the Pi itself needs to be excluded from the hairpin rule.

I think, the pi must rather be excluded from redirecting to itself. And that's already done according to the initial post.
Then the hairpin rule has not any impact on requests from the pi itself at all.

[jbernardo]

For documentation purposes (just in case - https://xkcd.com/979/), here is my currently working solution, with aliases for the pi-holes, both destination and source NATs.

[nero355]

For documentation purposes (just in case - https://xkcd.com/979/)

Hehehe! One of my favorites! NICE! ^_^

here is my currently working solution, with aliases for the pi-holes, both destination and source NATs.

I think you forgot to select IPv4 in the first screenshot ?

Redirects for IPv6 are a bit different than those for IPv4 according to the earlier mentioned topic!