Little cosmetic issue after upgrade to 25.1.1

[xavx]

As pointed by gpb, the incorrect logging is not limited to IPv6. Since 25.1.1, having IPv4 only and NAT redirection for ntp and dns, my 2 associated 'quick pass no log' firewall rules for ntp and dns generate wrong cosmetic block logs. This misbehavior was not present in 25.1.
My other pass rules don't generate any block logs

[franco]

As far as gpb's screenshot goes this could be a candidate https://github.com/opnsense/src/issues/242#issuecomment-2679069936

[gpb]

As far as gpb's screenshot goes this could be a candidate https://github.com/opnsense/src/issues/242#issuecomment-2679069936

Thanks @franco is that something you'd like me to try or should I just wait for the next iteration?  Always happy to help.

[franco]

Worth a try. I'm posting this here for more confidence of an eventual 25.1.x inclusion. Risk seems low given the patch scope and it would be nice to leave this half year old topic behind as finally fixed.


Thanks,
Franco

[gpb]

Worth a try. I'm posting this here for more confidence of an eventual 25.1.x inclusion. Risk seems low given the patch scope and it would be nice to leave this half year old topic behind as finally fixed.

Applied the patch.  As far as I can tell, that had no affect...thousands of firewall log messages scrolling past in the live log view at boot and no internet access for a couple minutes (no problem logging into opnsense itself).  Same as my screenshot earlier, these shouldn't be logged at all, but I assume that's coming from pf and has nothing to do with opnsense.  Now after a few minutes from boot, the logging stopped or slowed.  And it is indeed well over 1000 log entries inside of a minute, not sure in total how many messages were generated, but A LOT.  If I can provide more info, let me know.  Thx!

[gpb]

Worth a try. I'm posting this here for more confidence of an eventual 25.1.x inclusion. Risk seems low given the patch scope and it would be nice to leave this half year old topic behind as finally fixed.

Applied the patch.  As far as I can tell, that had no affect...thousands of firewall log messages scrolling past in the live log view at boot and no internet access for a couple minutes (no problem logging into opnsense itself).  Same as my screenshot earlier, these shouldn't be logged at all, but I assume that's coming from pf and has nothing to do with opnsense.  Now after a few minutes from boot, the logging stopped or slowed.  And it is indeed well over 1000 log entries inside of a minute, not sure in total how many messages were generated, but A LOT.  If I can provide more info, let me know.  Thx!

Edit: It does look like the errant log messages have fully stopped, that is different than prior where I would still get a couple periodically.  I'll give it more time and see that holds.

[franco]

It might just be the firewall killing the ICMP states that it deems as state violations because it has no prior knowledge about it.

This isn't a question of A LOT vs. a few... When it hits the default deny that is set to log it will log these packages now ever since the "security advisory" (it was an attempt at full scale state tracking for ICMP really) hit FreeBSD.


Cheers,
Franco

[gpb]

I see.  But this is different, these aren't ICMP nor default deny.  They are actually PASS type firewall rules.  Example, allow VLAN clients to access a DNS server on my primary LAN.  It does allow them to pass, but logs it as blocked.  Also, I have no logging enabled for firewall rules (including default deny).

See second attachment, after the update last night it seemed like the spurious log messages were stopped but they do still trickle through.  This is the example of PASS rules that are logged as blocked even though seem to pass.  I should also mention, typically when I update OPNsense that requires a reboot, my desktop (i.e., all hosts) would have internet access very quickly, i.e., as soon as I can log back into the GUI, WAN access is already available.  That's not what I'm seeing any longer.  It took a good couple minutes while all those log messages were flying by that WAN access just wasn't happening.  Odd not everyone is seeing this...or are they...?  Not a show stopper, just an observation.  Thx!

PS - Last screenshot is an example of some of the other blocks/messages during the reboot (not just ICMP), this is after the 1000+...so at the tail-end.  I redacted only my public IP.

[IsaacFL]

I see.  But this is different, these aren't ICMP nor default deny.  They are actually PASS type firewall rules.  Example, allow VLAN clients to access a DNS server on my primary LAN.  It does allow them to pass, but logs it as blocked.  Also, I have no logging enabled for firewall rules (including default deny).

See second attachment, after the update last night it seemed like the spurious log messages were stopped but they do still trickle through.  This is the example of PASS rules that are logged as blocked even though seem to pass.  I should also mention, typically when I update OPNsense that requires a reboot, my desktop (i.e., all hosts) would have internet access very quickly, i.e., as soon as I can log back into the GUI, WAN access is already available.  That's not what I'm seeing any longer.  It took a good couple minutes while all those log messages were flying by that WAN access just wasn't happening.  Odd not everyone is seeing this...or are they...?  Not a show stopper, just an observation.  Thx!

PS - Last screenshot is an example of some of the other blocks/messages during the reboot (not just ICMP), this is after the 1000+...so at the tail-end.  I redacted only my public IP.

Seeeing same here. Logging default pass rules as blocked.

[pfry]

[...]Odd not everyone is seeing this...or are they...?[...]

I am not, but I have all logging enabled. I see "RFC4890" (and IPv6 in general) packets once in a blue moon, and all appear to be logged correctly (pass and block) as well.

Have common (configuration/operation/etc.) characteristics been established for this (pass rules logged as blocked)? Are folks only seeing this with (default rule) logging disabled?

[IsaacFL]

[...]Odd not everyone is seeing this...or are they...?[...]

I am not, but I have all logging enabled. I see "RFC4890" (and IPv6 in general) packets once in a blue moon, and all appear to be logged correctly (pass and block) as well.

Have common (configuration/operation/etc.) characteristics been established for this (pass rules logged as blocked)? Are folks only seeing this with (default rule) logging disabled?

All of my default logging is disabled. And it is always auto generated rules that are pass rules but showing in log as blocked.

This started with 25.1.1 with no rule changes on my part. I did not have this with 25.1

I've been traveling so haven't been able to try debug much

[dracocephalum]

I have started seeing a huge bunch of "IPv6 RFC4890 requirements (ICMP)" being BLOCKED after upgraded to 25.1.1/25.1.2.

Code Select Expand

EGRESS0        2025-03-01T20:38:44    fd97:xxxx:xxxx:15::1    fd97:xxxx:xxxx:15::2    ipv6-icmp    IPv6 RFC4890 requirements (ICMP)
EGRESS0        2025-03-01T20:38:40    fd97:xxxx:xxxx:15::f0   fd97:xxxx:xxxx:15::2    ipv6-icmp    IPv6 RFC4890 requirements (ICMP)
(fd97:xxxx:xxxx:15::f0 is the OPNSense gateway)

Strangely, all "IPv6 RFC4890 requirements (ICMP)" rules are "Automatically generated rules", and apparently they are all first match ALLOWED rules.

Does it mean there are some hidden BLOCKED rules being generated and are not shown on the UI?

Also there is no way for me to workaround this at the moment, because I cannot create any rules that are applied before those "Automatically generated rules"... >_<

[gpb]

I have started seeing a huge bunch of "IPv6 RFC4890 requirements (ICMP)" being BLOCKED after upgraded to 25.1.1/25.1.2.

I'm getting those icmp block messages now, that's new for me.  I'm more concerned with the thousands of log messages for things that should not be logged including "let out anything from firewall host itself" appearing as blocked.  Very strange...this doesn't inspire confidence because I don't know what's actually happening here (hopefully just broken logging).  Internet connections don't seem impaired, so that's good.

[newsense]

Do you see these blocks on the latest kernel Franco built for this ? A reboot is required

Code Select Expand

opnsense-update -zkr 25.1.2-nd

[gpb]

Do you see these blocks on the latest kernel Franco built for this ? A reboot is required

No I hadn't..thanks!

Edit:  Post reboot the ipv6 icmp messages are now gone (as prior version) but the thousands of other f/w log messages remain (mentioned for clarify).