Messages

Hello,
I found out that I can get IPV6 with orange belgium - if I set their router to bridge mode and let my router (in this case opnsense) handle it. Seems that Orange.BE has DHCPV6-PD, and in my case with a /56 delegation size.
I set it up, can see from /tmp/vtnet0_prefixv6 that it is assigning a 2a01:xxxx:xxxx:xxxx::/56 prefix, so I configure the WAN DHCPV6 as in the "WAN DHCPV6 settings" image.
However, opnsense is using, for the WAN, a different prefix and delegation size, as you can see on the "Interfaces overview censored" image. It is pushing the "correct" prefix to the LAN, but with a incorrect delegation size.
What am I missing here, why is opnsense insisting on this fe80:/64?

And checking from the shell, default IPV6 routing is also going to this wrong prefix and ping v6 doesn't work.

Code Select Expand

# netstat -nr6 | grep default
default                           fe80::1%vtnet0                UG           vtnet0

I am using this script for carp on a single wan ip, as Orange will only assign one ip to a single mac address behind the bridge. I have cloned the mac between both opnsense instances and carp works. I don't see anything on that script that could interfere with DHCPV6, but have included that info for completeness.

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!

Well caught, I think it got away with that because I have IPV6 disabled. Orange Belgium still has to provide it, they are still IPV4 only for residential customers, so I am stuck without it.

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.