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 :)

[lmoore]

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 ?!

For now it is. I plan to make changes down the track and have some services on a DMZ network. I moved the DNS block lists from an internal server to OPNsense and as I don't want to be using redirection for DNS requests, it was assigned to a dummy DMZ interface. The DNS servers in DHCP were updated.

I only redirect Googles DNS IPv4 address to an internal DNS server. This is to cater for an entertainment device that when viewing content always queries 8.8.8.8, even though it has a valid DNS server entry from DHCP.

I've noticed that when my Internet stops working, for example when the local utility power goes out and the batteries for the vDSL equipment have been exhausted, Windows 10 &  11 detect a failure to resolve names via the configured DNS servers and attempt to connect to 8.8.8.8 & 8.8.4.4.

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

The easiest way to block ports 53 & 853 is to create rules which blocks connections to a negated (Invert Destination) destination address to ExternalTrustedIPv4DNSServers.

Firewall rules to block Internal & firewall itself to External untrusted DNS servers - ports 53 & 853;



Firewall rules to allow connections to Internal DNS servers and Internal DNS servers to trusted External servers;



Firewall rules to block connections to DNS servers using port 443 (DOH) - I think the last Group rule was made redundant.



I don't know how best to measure the effectiveness of blocking connections to DOH, however, I have noticed iPhones getting blocked when they attempt to connect to Apple's DOH servers.

One user on my network has decided to use another DNS server geographically located a very long way away - the device fails to connect to the DNS server via my network so it is taken off the network and connected via the devices mobile network.

[lmoore]

For completeness, the redirection of Google DNS;



Also, the Source NAT rule for outbound DNS queries, note the use of a tag. The appropriate rule will add the tag to the traffic going to the trusted external DNS servers.

[nero355]

Windows 10 &  11 detect a failure to resolve names via the configured DNS servers and attempt to connect to 8.8.8.8 & 8.8.4.4.

That's funny because there is some Cloudflare DNS registered somewhere in the Registry of Windows 10 that contacts it from time to time for whatever reason...

I guess they could not decide which competitor they liked more ?! :P

[lmoore]

That's funny because there is some Cloudflare DNS registered somewhere in the Registry of Windows 10

Perhaps its not Windows itself but some other application installed on the computer which has hard coded DNS server entries to use.

To satisfy my curiosity I will at some point perform a packet capture of the two Google DNS server addresses and then drop the Internet connection and flush DNS caches and wait to see what happens.

[nero355]

Perhaps its not Windows itself but some other application installed on the computer which has hard coded DNS server entries to use.

No it's really Windows 10 itself but I can't remember what it was about...

Grab a Window 10 PC or Laptop and search for it with regedit.msc and you will probably find it :)

[lmoore]

No it's really Windows 10 itself but I can't remember what it was about

I've not found anything on Windows 10, however, Windows 11 has 'DoHWellKnownServers' in the registry. Perhaps this is what you are thinking of.

Last night I blocked connections on one of my networks to the DNS server address on OPNsense. Checking this morning, there were no queries either from Windows-10 or Windows-11 to the Google DNS servers.