Unbound DNS keeps crashing every 2-3 mins.

[RES217AIII]

You accidentally inverted the Source instead of the Destination, and your Floating Rule is currently filtering outbound traffic (which is still blocking Unbound from reaching the internet).

Here is how both rules need to be configured:

1. Correct Destination NAT Configuration

Interface: Select all your local Interfaces/VLANs (do NOT select WAN or WireGuard).

Protocol: TCP/UDP

Source: any (Leave this completely default, do not invert!).

Port: *

Destination / Invert: Check the [X] (Invert) box.

Destination: Select This Firewall (self).

Port: 53 (domain)

Redirect Target IP: 127.0.0.1

Redirect Target Port: 53 (domain)

Filter Rule Association: Set this to Pass

Your current rule applies to traffic where the Source is not the firewall. We want it to apply to any client whose Destination is not the firewall.


2. Correct Floating Rule Configuration

If you still want to use the Floating Rule as a fallback block for port 53, it must only block incoming traffic from clients, never outbound traffic from Unbound.

Action: Block or Reject

Quick: Checked [X] (Apply immediately)

Interface: Select your local Interfaces/VLANs (do NOT select WAN, WireGuard, or Loopback).

Direction: Change this to IN (Currently, it is set to OUT, which blocks Unbound from hitting WAN!).

Protocol: IPv4 TCP/UDP

Source: any (Do not invert!).

Port: *

Destination / Invert: Check the [X] (Invert) box.

Destination: Select This Firewall (self).

Port: 53 (DOMAIN)



By setting Source: ! This Firewall, your rule was trying to match packets where the sender wasn't the firewall. We need to match packets where the intended target (Destination) isn't the firewall.

Your Floating Rule had the <- arrow (Outbound). This meant whenever Unbound itself tried to send a DNS request out to the internet via WAN, the firewall blocked it. Changing the direction to IN ensures it only blocks clients trying to push unauthorized DNS traffic into your local interfaces.

[apoorv569]

You accidentally inverted the Source instead of the Destination, and your Floating Rule is currently filtering outbound traffic (which is still blocking Unbound from reaching the internet).

Here is how both rules need to be configured:

1. Correct Destination NAT Configuration

Interface: Select all your local Interfaces/VLANs (do NOT select WAN or WireGuard).

Protocol: TCP/UDP

Source: any (Leave this completely default, do not invert!).

Port: *

Destination / Invert: Check the [X] (Invert) box.

Destination: Select This Firewall (self).

Port: 53 (domain)

Redirect Target IP: 127.0.0.1

Redirect Target Port: 53 (domain)

Filter Rule Association: Set this to Pass

Your current rule applies to traffic where the Source is not the firewall. We want it to apply to any client whose Destination is not the firewall.


2. Correct Floating Rule Configuration

If you still want to use the Floating Rule as a fallback block for port 53, it must only block incoming traffic from clients, never outbound traffic from Unbound.

Action: Block or Reject

Quick: Checked [X] (Apply immediately)

Interface: Select your local Interfaces/VLANs (do NOT select WAN, WireGuard, or Loopback).

Direction: Change this to IN (Currently, it is set to OUT, which blocks Unbound from hitting WAN!).

Protocol: IPv4 TCP/UDP

Source: any (Do not invert!).

Port: *

Destination / Invert: Check the [X] (Invert) box.

Destination: Select This Firewall (self).

Port: 53 (DOMAIN)



By setting Source: ! This Firewall, your rule was trying to match packets where the sender wasn't the firewall. We need to match packets where the intended target (Destination) isn't the firewall.

Your Floating Rule had the <- arrow (Outbound). This meant whenever Unbound itself tried to send a DNS request out to the internet via WAN, the firewall blocked it. Changing the direction to IN ensures it only blocks clients trying to push unauthorized DNS traffic into your local interfaces.

OK here is my destination NAT rule now,

and here is the floating rule,

Are these correct now?  And this will force all clients to use Unbound as their DNS even if they set some custom DNS manually? Like android phones have hardcoded 8.8.8.8 DNS I think..  and the destination NAT rule will forward all the traffic for port 53 that we block via floating to Unbound?

[meyergru]

The rules look "O.K." now. I told you to first check if your rules cause the problems in my first answer, for somehow I guessed that you redirected "all" port 53 traffic, creating an endless loop like explained here.

What can you learn of this? Your rule of thumb should be: If you experience problems, show your rules, because often times, they are the cause of it. See also the "READ THIS FIRST" article in the tutorial section.

That being said, your current rules alone will not help you with either DoT or DoH, which are the default in many browsers now.
There is a discussion about this also in the tutorial section.

Basically, you can block port 853 for DoT, but you need a blocklist for known DoH services because you cannot block port 443.

Also, there are a few more kinks in your rules, because they apply to IPv6 as well, see this.

On a side note: I have given up on the "block any other DNS than my own" game, because you cannot win it.

[nero355]

I used to use Pi-Hole as my network wide ad-blocker and for local DNS so I can have some like nas.homeserver.lan for all my services I host at home, but I recently learned about Unbound DNS in OPNsense and switched to it

Why did you decide to do so ?

and I have various overrides mimicking what I had in Pi-Hole for all my services such as nas.homeserver.lan also added few of my domains for split horizon DNS so the traffic can stay local when I am at home. I also have a floating rule that blocks all port 53 traffic on all my interfaces/VLANs except WAN and and WG interfaces and I also have a destination NAT rule that forwards all port 53 traffic to 127.0.0.1 to force all traffic via Unbound basically.

To avoid any weird issues like the ones explaned in previous posts where your main DNS Resolver is not able to reach the Internet there is one simple solution :
Make sure the network it uses is not involved in the Redirecting NAT and Firewall Rules at all :)

Network used by Pi-Hole + Unbound : 192.168.x.x/24
Networks with active Redirecting NAT and Firewall Rules : 10.0.x.x/24

And if you need your Pi-Hole to contact OPNsense DNSmasqd for DNS Records then just use Conditional Forwarding and you are DONE! ;)

Like Android phones have hardcoded 8.8.8.8 DNS I think..

Actually that's a very weird story which seems to work like this as far as I have got to know it over the years :

- Give your Android Clients just 1 DNS IP Address and there is a huge chance that Android will attach 8.8.8.8 and 8.8.4.4 to the list.
So your DNS configuration looks like this eventually :
192.168.x.x
8.8.8.8
8.8.4.4

- Give your Android Clients 2 DNS IP Addresses and there is a huge chance that Android will just use those two.

- Give your Android Clients 4 DNS IP Addresses and it seems the Google DNS Servers are completely ignored.


But...


Should your DNS Server(s) go OFFLINE then it's right back to 8.8.8.8 and 8.8.4.4 and your Android Clients won't even notice the issue ?!?!

Just a suggestion, instead of redirecting all DNS queries to 127.0.0.1, you could create a VLAN interface and assign it a static IP address. Note, I've set this interface with a /32 network address.

I think you meant to say Virtual IP Address ?!

On a side note: I have given up on the "block any other DNS than my own" game, because you cannot win it.

Still no reason to do as much as we can and prevent the stuff we CAN prevent :)