Hi all,
I am new here, and have just onboarded to OPNsense, coming from the 'other' sense :)
All is well and I have my configuration how I envisioned it to be.
The only step I am tinkering with still, is how to properly do DNS using Pi-Hole, whilst having a fallback.
My goal: I would like DNS traffic on all interfaces to go to Pi-Hole, but be able to quickly anticipate whenever the Pi-Hole would be unavailable, by (temporarily) routing through their own interface address, using Unbound (which I have currently enabled on all interfaces). I understand that this will not filter any ads, but this is only temporary anyhow.
What I have done so far:
- I have 4 VLANs altogether: MGMT (firewall and network equipment), TRUSTED (trusted devices), IOT (IoT devices) and PIHOLE (pi-hole device).
- All of the interfaces, except the Pi-Hole one, have the Pi-Hole address as DNS server under DHCP settings.
- All of the interfaces are allowed TCP/UDP traffic to the Pi-Hole address on port 53.
- The Pi-Hole itself is set to the interface address of its own VLAN (to resolve DNS queries).
Browsing the internet works. Blocking advertisements works.
As explained in my goal, I want to take this one step further, and somehow redirect DNS traffic, whilst still having the possibility to use the built-in Unbound resolver in case the Pi-Hole is not available.
Trying to wrap my head around it. I found some articles on the OPNsense forum, also on Google, but none of them actually matching my scenario (it seems).
I hope that anyone here might be able to push me into the right direction.
Many thanks in advance for your help!
[edit]
Thanks for the feedback all, this definitely helps in making the right decision forward!
rPi's are super ridiculously cheap.
c'mon why make the fw jump thru blazing hoops just to avoid spending twenty bucks?
spin up a 2nd pihole instance 2nd pi, advertise both rPis as DNS in the client scopes, and never ever take down both for maint at the same time.
your edge fw should rewrite any outbound dns reqs that aren't *from* your pi stack to transparently hit your pi stack, or just block the reqs entirely so you have an easy canary for hunting down any clients that go rogue.
if you don't trust your ISPs resolvers (and in this day and age, who would?), nor trust any of the centrally-aggregating others not to sell you out (quad, goog, csco, open, comodo, etc), then make sure your pi uses only the roots, and be sure to set your fw to use only the pis too.
ps ... fwiw, handling any app-embedded direct DoH or DoT resolver horseshit is a whole other ugly conversation.
good luck
R.
I'd recommend two three pihole nodes and you're done..
Thanks for your swift response both!
You are right, of course, to put in another pi-hole for redundancy purposes.
I don't want to be a cheapskate, and perhaps that's something I will explore in the near future.
@robvanhooren: I have set the pi to use the pi-hole interface address (192.168.30.1) as upstream server for DNS lookups, which is enabled in Unbound. That way I am indeed only using the root servers, instead of commercial upstream servers. I confirmed that to be the case via dnsleaktest.com.
One thing that I am needing some advice on still is pointing OPNsense to use the pi. Would it be as easy as creating a rule on the loopback interface for TCP/UDP 53 and point that to the pi? Disabling "Allow DNS server list to be overridden by DHCP/PPP on WAN" in System > Settings > General? Apologies for the ignorance, some things are fundamentally different than the 'other' sense I came from :).
For pihole settings, you have the static address of the rpi pihole is running on, set that as the DNS address in your DHCP server settings (under services). I also have my pihole addresses in system settings general including one link-local address for one of the piholes for ipv6 DNS queries.
You can also add a rule to NAT any outbound port 53 NOT coming from the pihole host and route that back to pihole. You'd need one rule for ipv4 and one for ipv6.
Hope that helps.
Thanks for the feedback, this definitely helps me in making the right decision.
For now I have found a solution by implementing a NAT rule that redirects traffic. In the (near) future I might consider adding a second pi-hole to obtain HA.
Now onto some further fine-tuning. I do not regret making the switch :)