Messages

You can also share it privately via franco@opnsense.org

Thanks,
Franco

Sent.

I can do this later today but I need to understand exactly how to extract the logs to get them to you (I want to get it right the first time).  BTW, I have similar NAT rules as IsaacFL indicated for DNS and NTP...but I'm sure a lot of people do.

I don't want to interrupt the hot discussion but I think https://github.com/opnsense/src/commit/2a564b0b652 should address this. You can try this kernel now:

# opnsense-update -zkr 25.1.3-fixlog
(reboot)

It would be *really* nice to get feedback on this.


Cheers,
Franco

Perfect timing, I was logged in ready to apply the first patch when my browser alerted you replied.  I applied the latest patch and that looks to resolve the issue.  That odd delay I mentioned remains but ultimately not a problem, just an observation.  My logs are completely empty post boot and tested to make sure normal logging from my geoip rules works and it does.  Thanks for the fast turn-around!  :)

My functionality has not been impacted, just items in the logs that should not be showing.

OK, maybe I'm being impatient or my memory is bad here, but as I remember it, once I could log back in I had full network functionality.

Not sure who you're asking.  Here's my take...it seems like while these thousands of log messages are showing up (I have all logging disabled) I should still have connectivity and trying to hit a web page fails.  My VLANs can't talk to my LAN.  While some could be invalid states, as soon as we hit a certain elapsed time post-boot, suddenly all of them work and the logging stops (for the most part).  It's more like the interfaces in opnsense are failing to initialize or something in the core functionality (log messages aside).  So to be clear, I see two different symptoms.  Much delayed connectivity (2 to 3 minutes) and log messaging that is unwanted/unselected.  I haven't the first clue how to even try to debug this.  This is a home network, so the thousands of messages seem excessive even if they were non-valid states...?

Same, I posted a message on reddit here.

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

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.

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.

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.

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!

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.

I have some firewall rule logging issues I reported on reddit.  I wouldn't call this cosmetic.  What happened here was after the update and reboot, the firewall logs started spitting out what looks like incorrect messages.  For example, I have a rule from a VLAN to LAN to allow DNS access to a pihole and it was being logged as BLOCKED but it was getting through (or at least it appears to be).  In that sense I guess it could be cosmetic.  I also went to Firewall Settings Advanced and re-saved settings there and that seemed to solve the problem EXCEPT I still have default rules logging.  This is primarily the IMCP rule for ipv6, but this block message is showing up for one of my vlans for which I don't even have ipv6 enabled.  This is the only message that continues to show with label "IPv6 RFC4890 requirements (ICMP)".

Glad I'm not the only one seeing this...but also want to know if I should roll-back or this is in fact just cosmetic.

Are you sure you're not still seeing some logging?

To be honest, it was a pain to even find the htop binary/package.  I'm not going to be any help unfortunately...I could never find an easy way to do this either.

pkg add https://pkg.freebsd.org/FreeBSD:14:amd64/quarterly/All/htop-3.3.0_2.pkg also works...for the current version.