Ineffective DNS Firewall Rule?

Started by Drake, January 18, 2026, 09:54:59 PM

Previous topic - Next topic
Hello OPNsense friends;

Over Christmas I decided to take the plunge and step up to OPNsense from my consumer-level router.  It has been quite the learning curve and I am still struggling to reach the layman's level of competence.  I have searched around the forum but haven't quite found any answers so I hope someone can help explain what is going on.

I am running version 25.7.10, and while everything is pretty stable and working, I have noticed in Zenarmor that my old LG Smart TV is direct-querying dns.google on Port 53.  Seems to be the Netflix app on the TV.  This is in defiance of a Firewall Rule I have set up that should Block any DNS request that does not go to my redundant PiHole(s):

Action - Block
Interface - LAN
Direction - in
TCP/IP Version - IPv4+IPv6
Protocol - TCP/UDP
Source - LAN net
Destination/Invert - Checked (Use this option to invert the sense of the match)
Destination - PIHOLE_DNS (An alias I set up that contains the IPv4 and IPv6 addresses of my two PiHole instances)
Destination Port Range (DNS)

To me, this seems like the Firewall should block any port 53 DNS query that isn't going to my PiHoles, but the LG TV seems to bypass this.

I also have two other related Rules, one Pass Rule which allows IPv4 & IPv6 traffic to get to the Piholes, and another Pass Rule to allow recursive DNS queries from the PiHoles to UnboundDNS.  UnboundDNS takes it from there.  They are both ahead in the order from the Block Rule.  There is also an unrelated Rule that is fourth in the order, which is a Block Rule for any query on Port 853 (DoT blocking effort).

So, that's the story.  Have I set this up wrong?  Any advice appreciated.  Thanx.

Quote from: Drake on January 18, 2026, 09:54:59 PMTo me, this seems like the Firewall should block any port 53 DNS query that isn't going to my PiHoles, but the LG TV seems to bypass this.

Is this rule a "quick" rule, i.e. applied on first match? Is this rule located above all other allow rules in the table view?

Rules are applied in order, for quick rules (the sensible default in almost all cases) first match wins.
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)

Hello - yes the Quick box is checked for this Rule, which is 3rd in the batting order.  It is below two Allow Rules that I described above, for traffic to the PiHoles and to UnboundDNS on the OPNsense box.

It is sitting above the two general Allow Rules at the bottom, which just passes all IPv4 and IPv6 traffic respectively.

I can change the Rule order to put this Block Rule first... will that make a difference?  It doesn't seem like it would be important.

For the record, the LG Smart TV network settings shows one of the PiHole DNS IP addresses for its DNS, so it seems like everything is set up right.  OPNsense seems to be pretty good at cramming the PiHole DNS addresses down the throat of every LAN client so they behave.

After adding the rule, clear the firewall states. If that TV was running all the time, probably there is an active state with "allow" from before you added your rule.

Firewall: Diagnostics: States: Actions
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)

Quote from: Drake on January 18, 2026, 09:54:59 PM[...]
Destination/Invert - Checked (Use this option to invert the sense of the match)
Destination - PIHOLE_DNS (An alias I set up that contains the IPv4 and IPv6 addresses of my two PiHole instances)
[...]

I may be off here, but in my experience the inversion operator does not work as (may be) expected on multiple-entry IP aliases. You could try creating (and using) an alias that has individual inverted elements... but that construct is a bit vague, too. I avoid the inversion operator because of that; for this type of scenario I use two rules (pass what I want, block everything else). YMMV.