Messages

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.

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.

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.

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:

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.

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.

"verify peer" was on - apparently is on by default? - and I had not generated a letsencrypt certificate for the second firewall.
PEBKAC

Web UI listening on all interfaces as literally "recommended"?

Yes, just rechecked, on both firewalls (System->settings->administration->Listen Interfaces).

I don't know if this is the same issue, but I am trying to setup the high reliability for the first time, and am stuck with this error also. Bot firewalls are at version 25.1.1, both have the same user/password pair in admins group and with privileges on all pages, ping works between both firewalls on the pfSync interface, and still I get the "HA The backup firewall is not accessible (check user credentials)" immediately as I try to sync configuration.