OPNSense + PiHole

PiHole off:

Right now I'm on different machine 192.168.103.12 (previously on .10), so first lines in log are from nslookup that failed

Okay, that's got some interesting parts in it.

It's still trying to use Pi-hole but there is no response back, which is exactly what we expect.

Do you have ssh service enabled for opnSENSE? I'd like to check a few things at the console shell...

Yes I have (but only locally)

Ah, I think I've found it. Without Query DNS servers sequentially everything works. But it should be following order so I'm going to do some digging.

I don't think we need shell access for this.

Awesome, thank you.

Okay, this is an odd one and I'm not sure how things worked for me with this issue in place.

If you remove the edns0 config and restart dnsmasq then the strict order will work.

The problem is that ends0 precludes dnsmasq from regenerating the query and dnsmasq never hears the timeout and the signal to try the next server down the list.

So, for now I'd remove edns0 and go back to conditional forwarding for the local name resolution. Should be able to set cf to point to OPNsense (I forget the capitalization...) and use your local lan domain name.

I'm going to try and see if there is some way to fix this issue, but I don't think it will make it in to a dnsmasq version that would be pulled in to opnsense. Unless we can chat with them and see.

@DL6ER I'll get you on MM for this, I think that ends0 = 32 should have enough information to recreate the query with the full ip and source port.

Yes it's working now (after removing ends0)! Thank you.

Two additional question (in same topic):

  • do we need conditional forwarding? if we enable PiHole to forward local IPs it will ask Unbound and Unbound will correctly resolve local IPs, am I right ?
  • right now if PiHole is down client will ask DNSmasq and DNSmasq will ignore PiHole IP and also Unbound and will ask external DNS (e.g. 8.8.8.8), is it possible to configure it so if PiHole is down it will ask Unbound (client->DNSmasq->Pihole->Unbound or if Pihole is down client->DNSmasq->Unbound), I think it is impossible to set IP+port required for Unbound in System->Settings->General->DNS servers

So instead of:

Use something like this (I think it is impossible):

You could do it a couple of ways. If you are okay with forwarding local to unbound and having unbound respond with the DHCP leases then that will work. My example configuration is designed so that there's not a possibility of leaking, as small a possibility that is.

I'll think about your idea some more and see if there's a way to do as you mention and be able to have fallback DNS without needing to tweak opnsense dnsmasq. Credit will go to you if it works and we do a blog post about it.

dnsmasq will ignore any DNS servers that are reachable via 127.0.0.1 or at the same IP as dnsmasq to prevent loops. And as you saw, there is no place to put a port with /etc/resolv.conf. (That's what opnsense changes when you add DNS servers to General settings.)

<20 minutes later...>

Okay, I think your last question sparked a bit of an idea for me. If opnsense has compiled unbound with the required flags then we could use unbound entirely and not need dnsmasq. That's a better approach since opnsense discourages dnsmasq as a resolver.

We could still use edns0|ecs and limit the forwarding to only the Pi-hole server. And make a local zone for the local domain name for your lan. I don't know if unbound adds the reverse PTR records for DHCP leases, but if it does then even better.

It will take some manual configuration and files but it may work to be a more elegant solution to the problem of wanting Highly Available DNS and something to function if Pi-hole goes offline.

Give me some time to play with it and see what I can come up with.

What I would do is

I think I have something that works with unbound and forward-first. When Pi-hole goes offline then unbound becomes a recursive server like it normally operates. Each query has to fail on Pi-hole first so you will have additional latency when in fail mode but that may be a good indication that you need to investigate.

Unfortunately the unbound for opnsense is missing the ecs module so it's back to conditional forwarding unless/until opnsense can be convinced to include the module in the compilation run.

dnsmasq on the opnsense is no longer used at all.

Hi, sorry for late response.

I'm not sure if I understand you correctly.
You are saying that I could use unbound without dnsmasq and have fallback DNS but this require forward-first option? Is this option already available or does it require mentioned compilation flag for unbound (I don't see this option in OPNsense but maybe missed it)?

In this case if PiHole is running will it ask external DNS? This would mean that unbound functionality of asking "root" name server (not sure how they are called) would not work (it would work only if PiHole was down).

Sorry if I mixed something I'm not an network admin, I just learning on my home network, first time configuring something more advance than basic router:P

I'm working on a few different approaches.

The limiting factor is the versions of the daemons included with opnsense. unbound is a really nice solution but it needs to be compiled with subnet support. The default freebsd package has that disabled and I'm not exactly sure where or who on opnsense to ask for that flag to be enabled on compile.

dnsmasq would be another solution but it appears to have a bug when edns0 is enabled and strict-order is called for. Fixing that would require opnsense to include the fixed version. I don't know how that would be done on opnsense either.

I do see what you mean about unbound being both the first DNS and the upstream to Pi-hole. To solve that I would have unbound running on opnsense as the ingress DNS and then run Pi-hole and unbound together on the Pi-hole server. Easy to do and actually is the preferred method of using unbound.

So, where does that leave us? If you don't want to have the clients show as individual then unbound would work now with the two daemon configuration. There is a slight delay for the forward-first to kick in when Pi-hole is offline but I think that's a fair compromise and possibly a signal to users that something needs to be addressed.

If anyone has contacts at opnsense that we could chat with, please let us know.

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.