Turned off logging for a rule but it still logs blocks

[iorx]

Hi!

I'm baffled.
Had logging turned on for this rule to check it. But now I've turned it off (cleared states and rebooted too, to be sure...) and still the log show a block for this rule.

Info:
Latest and greatest opnSense
3 LANs 192.168.32.1/24-LAN, 192.168.88.1/24-VLAN10IOT, 192.168.99.1/24-VLAN50GUEST
All network adapters here are virtual NICs in Hyper-V Guest. They're not "VLAN" in opnSense, the vm-nics are assigned to VLANs (this shouldn't matter, just to clarify how it looks)

What I'm trying to do here is a floating rule "in" for all local nets to allow it to reach DNS in 192.168.32.1 and 192.168.32.6.
Got it working. So I decided to turn off logging... but it's here I don't understand or something is "fishy".

In 192.168.88.1/24 I got a device, 192.168.88.30, which does everything it can to contact DNS-servers on the outside. It's from this device the block is logged even though it's turned off.

Port Forward rule
from: !hosts_lan_DNS (from everything that is not a DNS-server)
to: !net_IP_rfc1918 (not destined for a local network)
dest: 192.168.32.1
port: 53
Linked rule: none (I've tried with a linked rule too, same problem. So here I've created the rule separately)

Rule:
Int: all local networks are checked, the LANs.
Dir: in
Prot: UDP
Src: *
Dst: hosts_lan_DNS
Port range: 53
Log: Off (not checked, and anyhow I get a block logged)
Desc: "dns allow hosts_lan_DNS"

(i) on the block log entry.
__timestamp__   2025-03-29T18:11:54
action   [block]
anchorname   
datalen   85
dir   [in]
dst   192.168.32.1
dstport   53
ecn   
id   7191
interface   hn3
interface_name   VLAN10IOT_hn3
ipflags   DF
ipversion   4
label   dns allow hosts_lan_DNS
length   105
offset   0
protoname   udp
protonum   17
reason   match
rid   294333517bbb3bb08472917abb16ca16
rulenr   46
src   192.168.88.30
srcport   46731
subrulenr   
tos   0x0
ttl   64

I've attached to screengrabs.

Have I got this totally backwards or something "borken"?

Best Regards and thank you for reading this fellow experts and enthusiasts!

[patient0]

Did you change the floating rule from block to pass? Or do you have another rule with the same name?

A pass rule would not block, it eithers match and allows what it is supposed to allow. Or not match and not do anything.

[iorx]

Did you change the floating rule from block to pass? Or do you have another rule with the same name?

A pass rule would not block, it eithers match and allows what it is supposed to allow. Or not match and not do anything.

Hi!

Name/description. No, I've checked and also changed the description to be sure it this rule I see in the logs. Also click the RID-link opens up the correct/this rule, "dns allow hosts_lan_DNS".

Yes, the rule has been a PASS rule since the beginning. What I've toggled is logging on or off. But for this specific host, 192.168.88.30, it still shows a block in the log. I started out with a linked rule from the Port Forward, it showed the same behaviour.

The first three rules is behaving like this. Logging is off but log shows a block anyway. There should only be one of the three active, but as I'm troubleshooting this I've tried a some variations on it.

Also captured traffic from this specific host to try to see what's going on. Not sure what I'm looking at as I'm not the well versed in Wireshark.

Attached the rule set from VLAN10IOT

[patient0]

Port Forward rule
from: !hosts_lan_DNS (from everything that is not a DNS-server)
to: !net_IP_rfc1918 (not destined for a local network)
dest: 192.168.32.1
port: 53
Linked rule: ...

Maybe first another question: what is the point of this forwarding rule, you want to redirect external UDP/DNS queries to .32.1?

You have set no source proto & port, or are they set to UPD/53 for source and destination? (Sorry it's early) What I meant is you have set destination to !net_IP_rfc1918, port 53 and forward it to .32.1, port 53 - and proto for this rule is set to UDP, on what interface is this rule?

Addition: I see that in the first post, the blocked rule has the DF (dont-fragment) bit set. What is your setting in Firewall:Settings:Normalization IP Do-Not-Fragment ? DNS query is tiny, can't be.

I really don't know either, it turns out.

The order of the rules would be:
1) rdr/port forwarding (can you enable logging there to see the target the client tries to reach)
2) floating rule allowing (in theory) access to the DNS server .32.1

The port forwarding seem to work and at the second rules something goes wrong. The rule matches but it get blocked. For me that usually means that something with the state of the connection is not ok, asymmentric routing or similiar.

[iorx]

Sorry for my messy answer here. I've edited and added stuff while composing this.

Port Forward rule
from: !hosts_lan_DNS (from everything that is not a DNS-server)
to: !net_IP_rfc1918 (not destined for a local network)
dest: 192.168.32.1
port: 53
Linked rule: ...

Maybe first another question: what is the point of this forwarding rule, you want to redirect external UDP/DNS queries to .32.1?

You have set no source proto & port, or are they set to UPD/53 for source and destination? (Sorry it's early) What I meant is you have set destination to !net_IP_rfc1918, port 53 and forward it to .32.1, port 53 - and proto for this rule is set to UDP, on what interface is this rule?

The purpose is to block doh/dns to be accessed externally from any network on the inside. All resolves should go through internal DNS.
To allow two LAN DNS (.32.1 and .32.6) to access external doh and dns.
DHCP on all interfaces gives out two DNS .32.1 and .32.6.
Host 192.168.88.30 connected to VLAN10IOT_hn3 ignores this and tries to connect to a bunch of DNSs externally...

you have set destination to !net_IP_rfc1918, port 53 and forward it to .32.1, port 53 - and proto for this rule is set to UDP

I can't see that I have such rule or am I missing something here? What description do you see for the rule you're referring to here?
The Port Forward looks a bit what you referring to.
To my understanding this should Port Forward traffic that is not from my internal DNS and not having a destination to any internal address.

from: !hosts_lan_DNS (from everything that is not a DNS-server)
to: !net_IP_rfc1918 (not destined for a local network)
dest: 192.168.32.1
port: 53
 
hosts_lan_DNS is a host alias with internal dns addresses.
net_IP_rfc1918 is a net alias for private networks 10,127,192...

I have on the interface VLAN10IOT_hn3 just one rule that lets everything out if it's not rfc1918. It's the last rule on the interface.
"dns allow hosts_lan_DNS" is a floating rule for all internal interfaces.

It's an allow rule and it shows the block in logs. This role in combination with the Port Forward works as it should. Devices on any internal interface which tries to resolve names externally is redirected.

I don't get this log block message from other devices than this particular device 192.168.88.30 though... Which is strange.

As the logs fills up with this block message from "dns allow hosts_lan_DNS" I would really like to figure out why a PASS rule logs a block 😁

[patient0]

I can't see that I have such rule or am I missing something here? What description do you see for the rule you're referring to here?
The Port Forward looks a bit what you referring to.
To my understanding this should Port Forward traffic that is not from my internal DNS and not having a destination to any internal address.

I'm not making myself clear, no worries and your forwarding rules is probalby correct. What I meant is, does your port forwarding rule look similar to the following, second entry (interface would be different, of course)?

You cannot view this attachment.

[doktornotor]

The purpose is to block doh/dns to be accessed externally from any network on the inside. All resolves should go through internal DNS.

1/ You cannot block DoH (usually port 443) nor DoT (usually port 853) by redirecting port 53.
2/ You cannot redirect DoH/DoT in this way even by redirecting the proper ports - since it breaks the encryption (certificates).

Would suggest reviewing the following, e.g.:
https://developers.google.com/speed/public-dns/docs/dns-over-tls
https://developers.google.com/speed/public-dns/docs/doh

[iorx]

The purpose is to block doh/dns to be accessed externally from any network on the inside. All resolves should go through internal DNS.

1/ You cannot block DoH (usually port 443) nor DoT (usually port 853) by redirecting port 53.
2/ You cannot redirect DoH/DoT in this way even by redirecting the proper ports - since it breaks the encryption (certificates).

Would suggest reviewing the following, e.g.:
https://developers.google.com/speed/public-dns/docs/dns-over-tls
https://developers.google.com/speed/public-dns/docs/doh

Hi!
Thank you.

• I'm blocking known Do* servers not trying to redirect DoH or DoT. Purpose is to make the device resort to normal DNS-request and from there be redirected to internal DNS.
• Have that understanding

But the curiosity that made me start this subject was that I got block logging when not having a log enabled rule and on top of that it's a PASS rule.

[iorx]

I'm not making myself clear, no worries and your forwarding rules is probalby correct. What I meant is, does your port forwarding rule look similar to the following, second entry (interface would be different, of course)?

You cannot view this attachment.

Here is the port forward, attached png.
I've been toying around with like everything so maybe that alias for internal DNS contains to many IPs right now. It should be enough with .32.1 and .32.6

You cannot view this attachment.

[iorx]

As a test I created a rule directly on the interface, VLAN10IOT_hn3.
A PASS rule with logging enabled.
You cannot view this attachment.

Checking the log I get this. Something triggers a BLOCK.
You cannot view this attachment.

If turn off logging the PASS logging disappears but the BLOCKs are still generated.

Also tried replacing the rules destination from the alias to just the ip address. Same-same block are logged 🤪
Here I also turned on loggin for the Port Forward.
You cannot view this attachment.

I'm stuck. Don't know what else to try here.

[troplin]

Might be a coincidence but I've noticed that all the timestamps end in ~55s.
Could this be caused by some scheduled job that runs every N minutes, like the table update?

[iorx]

Might be a coincidence but I've noticed that all the timestamps end in ~55s.
Could this be caused by some scheduled job that runs every N minutes, like the table update?

Hi! Thank you for checking in on this.

The device to blame here looks like it do stuff at an interval, it's an IOT, solar panel central, which I don't have that much control over. As mentioned it hunts down external name resolving like a "mad man". It's in this "hunt" opnSense generates a block.

But the interesting thing is why opnSense generate a log at all when I have logging disabled (not checked) on all affected rules and forward... 😮
The logs above I have enabled logging to see what and when the block is shown. It's a PASS rule so shouldn't see block logging anyway (to  my understanding)

[patient0]

I think it's because of something is/was wrong with the state of the connection but I don't know right now how to replicate it.
E.g. with asymmetrical TCP connection, for a return package when the firewall has no matching state.

[keeka]

But the curiosity that made me start this subject was that I got block logging when not having a log enabled rule and on top of that it's a PASS rule.

Briefly during startup, I see a batch of firewall blocks logged for rules which have logging disabled and which are pass rules.
One of which is, 'let out anything from firewall host itself (force gw)'. I'm guessing this may be because the WAN gateway is not yet up and the rule's action cannot succeed.
Another pass rule, that gets logged as a block, is interestingly a rule associated with an internal DNS redirect. I forward udp:53 & udp:123 to the firewall 127.0.0.1.

However this behaviour stop once the firewall is up and routes are active.
I have the option 'skip rule creation when gateway down' enabled.

[iorx]

I think it's because of something is/was wrong with the state of the connection but I don't know right now how to replicate it.
E.g. with asymmetrical TCP connection, for a return package when the firewall has no matching state.

Thank you.

I've done captures and I can't see any asymmetrical traffic. Should be rather simple to see, traffic going out on one interface (mac) and in on another?
Is there a way to see if the "rouge" device is spoofing mac and be that creates asymmetrical traffic (this is way beyond my network experience and knowledge so guy-guessing i bit here.)

Question still remains. Why does it log it? 😁 As you can see in the logs it's like every minute this "rouge" device is "attacking" external name servers. Logs get pretty useless when spammed like this.