Hi all
My update to 25.1.1 was smooth. Many thanks for your hard work.
After update and reboot i've noticed a small cosmetic issue. I've disabled logging of the default ruleset at Firewall: Settings: Advanced. But for a short period of time during a reboot, those matching packets are getting logged in the live log. After the rebooting procedure, everything is working as expected (no logging anymore).
Am I the only one with this behavior?
Many thanks for your replies.
Best regards,
Wrigleys
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?
Thanks for your reply. You're absolutely right. Those logged rules were (in my case) default ALLOW rules but it was logged as BLOCKED.
I'm seeing those BLOCKED logs for just a few seconds during booting up and it seems that the traffic went trought.
Interesting behavior.
Cheers,
Wrigleys
I'm seeing similar behavior with the IPv6 RFC4980 rules. I see a pass and then a block for each neighbor advertisement.
https://imgur.com/a/9ggqf4Y
I'm seeing the same issues with logging. Still seeing today after updating and rebooting yesterday. I would not call this cosmetic.
For those with unexpected logging: What are y'all seeing in the ruleset? (Easiest way to look is "Firewall: Diagnostics: Statistics" under "Rules".) Do the rules show up with the "log" option?
I have seen other log amplification in OPNsense, in my case tied to the "reject" action and multicast. pf logging seems to be screwy in general. But the above examples are new (to me).
I'm relatively sure this is the actual fallout from which we suffered consequences from in 24.7.x (but not 24.7 and 24.7.12):
https://www.freebsd.org/security/advisories/FreeBSD-SA-24:05.pf.asc
https://www.freebsd.org/security/advisories/FreeBSD-EN-24:16.pf.asc
Truth be told we raised the issue through the proper channels, but nobody cares as much.
So when we moved to FreeBSD 14.2 we took the FreeBSD code as is.
Now we are more or less where we were back then, but reverting it eternally is not going to be the solution.
https://github.com/opnsense/changelog/blob/2c7e4b3e94b61e2e40acdf40e6bf9ac83634d4c9/community/25.1/25.1#L116
Cheers,
Franco
To add to the previous: the issue is certainly not cosmetic as reports are piling up about IPv6 issues which is exactly what we see here: legit ICMP traffic being dropped.
If you see these "IPv6 RFC4890 requirements (ICMP)" related drops can you see in the details which "protonum" is affected? My bet is on 135 and 136. We don't show the ICMP type so this is futile and not useful for debugging, great.
Thanks,
Franco
Hi franco and all other contributors
Actually I'm sure that we have two issues on this topic. My initial observation was some BLOCKED FW-Logs (even IPv4 traffic) right after reboot.
I've made some investigations:
OPNsense Appliance finished booting at 2025-02-13T19:29:58 (last timestamp in Boot log).
Few seconds after, I see some BLOCKED FW-Logs which are affecting random FW-Rules which are configured to NOT log any matching traffic.
Picture of those FW-Logs which should not be logged: https://imgur.com/a/0uNIq6k (https://imgur.com/a/0uNIq6k)
After few seconds the issue is resolving itself (no logging anymore). This behavior started after Updating to 25.1.1, the initial 25.1 Upgrade was working fine.
Many thanks for your help.
Cheers,
Wrigleys
I see ICMP messages blocked with this log:
GAST 2025-02-14T18:47:57 fe80::d0e5:9fff:fe44:4af7 ff02::2 ipv6-icmp IPv6 RFC4890 requirements (ICMP)
GAST 2025-02-14T18:47:57 fe80::d0e5:9fff:fe44:4af7 ff02::2 ipv6-icmp IPv6 RFC4890 requirements (ICMP)
But the corresponding rule is an automatic allow-rule!
Quote from: franco on February 14, 2025, 09:23:19 AMI'm relatively sure this is the actual fallout from which we suffered consequences from in 24.7.x (but not 24.7 and 24.7.12):
https://www.freebsd.org/security/advisories/FreeBSD-SA-24:05.pf.asc
https://www.freebsd.org/security/advisories/FreeBSD-EN-24:16.pf.asc
Truth be told we raised the issue through the proper channels, but nobody cares as much.
So when we moved to FreeBSD 14.2 we took the FreeBSD code as is.
Now we are more or less where we were back then, but reverting it eternally is not going to be the solution.
https://github.com/opnsense/changelog/blob/2c7e4b3e94b61e2e40acdf40e6bf9ac83634d4c9/community/25.1/25.1#L116
Cheers,
Franco
I had a little time, yesterday, so tried looking at this a little bit more. The issue, is that it should not be showing in the log as the rule does not have logging enabled. Whether the ipv6 icmp is having issues or not, I don't understand how that forces logging on? Also I am seeing ipv4 improper logging also. "let out anything from firewall host itself (force gw)"
I have tried to attach a screen shot of the log and rules.debug that shows the relevant rules do not have logging enabled, yet logs are showing up.
Quote from: franco on February 14, 2025, 09:55:15 AMTo add to the previous: the issue is certainly not cosmetic as reports are piling up about IPv6 issues which is exactly what we see here: legit ICMP traffic being dropped.
If you see these "IPv6 RFC4890 requirements (ICMP)" related drops can you see in the details which "protonum" is affected? My bet is on 135 and 136. We don't show the ICMP type so this is futile and not useful for debugging, great.
Thanks,
Franco
Hi Franco,
is that the old issues from fall 2024 (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701) again popping up? Please tell me it is not and that upstream has not fixed 13.3 only... It would explain some reports about broken IPv6 connectivity, though.
Regards,
Uwe
P.S.: I have tested all FreeBSD 13.4, FreeBSD 14.2, OpnSense 24.7.x and OpnSense 25.1.1 with NS solicitation tests, all answered correctly.
Quote from: IsaacFL on February 15, 2025, 06:31:13 PMQuote from: franco on February 14, 2025, 09:23:19 AMI'm relatively sure this is the actual fallout from which we suffered consequences from in 24.7.x (but not 24.7 and 24.7.12):
https://www.freebsd.org/security/advisories/FreeBSD-SA-24:05.pf.asc
https://www.freebsd.org/security/advisories/FreeBSD-EN-24:16.pf.asc
Truth be told we raised the issue through the proper channels, but nobody cares as much.
So when we moved to FreeBSD 14.2 we took the FreeBSD code as is.
Now we are more or less where we were back then, but reverting it eternally is not going to be the solution.
https://github.com/opnsense/changelog/blob/2c7e4b3e94b61e2e40acdf40e6bf9ac83634d4c9/community/25.1/25.1#L116
Cheers,
Franco
I had a little time, yesterday, so tried looking at this a little bit more. The issue, is that it should not be showing in the log as the rule does not have logging enabled. Whether the ipv6 icmp is having issues or not, I don't understand how that forces logging on? Also I am seeing ipv4 improper logging also. "let out anything from firewall host itself (force gw)"
I have tried to attach a screen shot of the log and rules.debug that shows the relevant rules do not have logging enabled, yet logs are showing up.
+1
Thanks for following up. This is exactly my issue I've tried to explain :-) I'm still searching for the root cause, but I assume it's related to some backend changes (rule order change that maybe all rules are logged till our configuration will apply).
@IsaacFL: are your improper logs persistent or like in my case just for a short period of time after booting up OPNsense?
all the best,
Wrigleys
Quote from: Wrigleys on February 16, 2025, 01:49:38 PMQuote from: IsaacFL on February 15, 2025, 06:31:13 PMQuote from: franco on February 14, 2025, 09:23:19 AMI'm relatively sure this is the actual fallout from which we suffered consequences from in 24.7.x (but not 24.7 and 24.7.12):
https://www.freebsd.org/security/advisories/FreeBSD-SA-24:05.pf.asc
https://www.freebsd.org/security/advisories/FreeBSD-EN-24:16.pf.asc
Truth be told we raised the issue through the proper channels, but nobody cares as much.
So when we moved to FreeBSD 14.2 we took the FreeBSD code as is.
Now we are more or less where we were back then, but reverting it eternally is not going to be the solution.
https://github.com/opnsense/changelog/blob/2c7e4b3e94b61e2e40acdf40e6bf9ac83634d4c9/community/25.1/25.1#L116
Cheers,
Franco
I had a little time, yesterday, so tried looking at this a little bit more. The issue, is that it should not be showing in the log as the rule does not have logging enabled. Whether the ipv6 icmp is having issues or not, I don't understand how that forces logging on? Also I am seeing ipv4 improper logging also. "let out anything from firewall host itself (force gw)"
I have tried to attach a screen shot of the log and rules.debug that shows the relevant rules do not have logging enabled, yet logs are showing up.
+1
Thanks for following up. This is exactly my issue I've tried to explain :-) I'm still searching for the root cause, but I assume it's related to some backend changes (rule order change that maybe all rules are logged till our configuration will apply).
@IsaacFL: are your improper logs persistent or like in my case just for a short period of time after booting up OPNsense?
all the best,
Wrigleys
They are persistent.
Tracking this here now, someone already confirmed the ND state tracking is wrong https://github.com/opnsense/src/issues/242
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
As far as gpb's screenshot goes this could be a candidate https://github.com/opnsense/src/issues/242#issuecomment-2679069936
Quote from: franco on February 24, 2025, 08:33:28 PMAs 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.
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
Quote from: franco on February 24, 2025, 09:16:19 PMWorth 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!
Quote from: franco on February 24, 2025, 09:16:19 PMWorth 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.
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
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.
Quote from: gpb on February 25, 2025, 02:23:14 PMI 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.
Quote from: gpb on February 25, 2025, 02:23:14 PM[...]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?
Quote from: pfry on February 26, 2025, 08:33:20 PMQuote from: gpb on February 25, 2025, 02:23:14 PM[...]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
I have started seeing a huge bunch of "IPv6 RFC4890 requirements (ICMP)" being BLOCKED after upgraded to 25.1.1/25.1.2.
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"... >_<
Quote from: dracocephalum on March 01, 2025, 08:49:36 AMI 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.
Do you see these blocks on the latest kernel Franco built for this ? A reboot is required
opnsense-update -zkr 25.1.2-nd
Quote from: newsense on March 01, 2025, 05:46:41 PMDo 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 did the update to 25.1.3 and still seeing the ipv4 log entries.
Same, I posted a message on reddit here (https://www.reddit.com/r/opnsense/comments/1j8pq51/comment/mh8bi22/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button).
Are we sure we are not looking into depleted states? Just double-checking as promised on Reddit.
Cheers,
Franco
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...?
Quote from: franco on March 11, 2025, 07:50:28 PMAre we sure we are not looking into depleted states? Just double-checking as promised on Reddit.
Cheers,
Franco
It may be, but it shouldn't be showing in the logs as I don't have any of the default logging enabled.
This started after the update from 25.1 to 25.1.1. With no changes on my side. I don't log blocks normally just a few pass rules on local traffic so my logs usually have only a few entries per day until whatever changes.
Quote from: gpb on March 11, 2025, 08:00:01 PMNot 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...?
My functionality has not been impacted, just items in the logs that should not be showing.
Quote from: IsaacFL on March 11, 2025, 08:07:08 PMMy 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.
If it was introduced in 25.1.1 it's most likely https://github.com/opnsense/src/commit/1a2a481ca
I can build a 25.1.3 kernel with that commit reverted, but going forward revert is not an option, because that commit is required for certification to pass, otherwise these packets actually being dropped are only logged as "pass", which is a general issue with the pf(4) code.
Cheers,
Franco
Quote from: franco on March 11, 2025, 07:50:28 PMAre we sure we are not looking into depleted states? Just double-checking as promised on Reddit.
Perhaps something similar/same (following update to 25.1.3 and reboot):
Int Dir Proto Source Nat Destination State Rule
all -> tcp 47.190.83.191:42238 47.190.83.194:110 ESTABLISHED:ESTABLISHED EDGE: Block any from any to EDGE address
all <- tcp 47.190.83.191:42238 47.190.83.194:110 ESTABLISHED:ESTABLISHED block all targeting port 0
all -> tcp 47.190.83.194:49188 47.190.83.191:110 ESTABLISHED:ESTABLISHED EDGE: Block any from any to EDGE address
all <- tcp 47.190.83.194:49188 47.190.83.191:110 ESTABLISHED:ESTABLISHED block all targeting port 0
all -> tcp 10.101.11.160:58500 20.10.31.115:443 ESTABLISHED:ESTABLISHED TRUST: Pass any from TRUST net to any
all <- tcp 47.190.83.202:4330 10.101.11.160:58500 20.10.31.115:443 ESTABLISHED:ESTABLISHED let out anything from firewall hos
Looks like the first few states were a bit confused as to the allow-out rule.
Edit: Preceding message explains it. Aside: Prior reboots must have gone by with short-lived states. Interesting.
@pfry technically this is about the log producing spurious messages, not about actual state handling
Here is a test kernel with the reverted patch:
# opnsense-patch -zkr 25.1.3-nolog
(reboot)
Also, I think I know what's wrong here. Will tinker with it.
Cheers,
Franco
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
Quote from: franco on March 12, 2025, 02:50:25 PMI 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! :)
I just applied the # opnsense-update -zkr 25.1.3-fixlog with reboot and so far seems like it has fixed it.
Nice, thanks. I'll pass this on to FreeBSD then and it should land in 25.1.4.
Cheers,
Franco
The question in FreeBSD came up why these state creations are rejected. The other half of the story is the log does not actually record this at the moment either way. I wrote a small patch to diagnose: https://github.com/opnsense/src/commit/6f18c3b0164689d5cc83206499ade2f4f4016c6e
Would someone with the issue here try this kernel build and send in the plain filter log for the entries that cause spurious block log messages after boot?
# opnsense-update -zkr 25.1.3-reasonlog
(reboot)
Thanks in advance,
Franco
I'm out of town until Friday so can't try the patch yet.
The things that seemed to trigger from my memory:
I had a NAT forward rule to forward DNS port 53 to my local piholes. I could disable the port forward and the log entries would go away
Another ipv4 log entry was ping to 1.1.1.1 from the WAN address. I am mostly ipv6 network and have Tayga plugin. Some Apple clients like to ping 1.1.1.1 via CLAT and so they go thru the Tayga
Thanks for the details. For now we're looking for the internal error code ("reason") which indicates the nature of the code problem, it may or may not be related to the rule content.
Just to reiterate. The actual fix will go into 25.1.4 as planned, but we still need the additional data to have the right approach in FreeBSD eventually.
Appreciate the help. :)
Cheers,
Franco
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.
The output of
# opnsense-log filter
may be enough after reboot when you saw the bad entries appear with that specific kernel.
You can also share it privately via franco@opnsense.org
Thanks,
Franco
Quote from: franco on March 18, 2025, 02:59:16 PMYou can also share it privately via franco@opnsense.org
Thanks,
Franco
Sent.
Thanks! Based on the data we're looking at state creation failure here, which may be perfectly normal on bootup:
https://github.com/opnsense/src/blob/ba418a9ea69182d01a12e39f0a76a6b4ca9a99bd/sys/netpfil/pf/pf.c#L5330
(it's going to be reviewed by FreeBSD so we'll know for sure soon enough)
Cheers,
Franco
Quote from: franco on March 17, 2025, 05:25:30 PMThe question in FreeBSD came up why these state creations are rejected. The other half of the story is the log does not actually record this at the moment either way. I wrote a small patch to diagnose: https://github.com/opnsense/src/commit/6f18c3b0164689d5cc83206499ade2f4f4016c6e
Would someone with the issue here try this kernel build and send in the plain filter log for the entries that cause spurious block log messages after boot?
# opnsense-update -zkr 25.1.3-reasonlog
(reboot)
Thanks in advance,
Franco
Im back in town and will try this patch today.
Update: Installed, can see the unexpected log entries again. Let me know when you would like me to send output of opnsense-log filter
Can you try this kernel as well ?
opnsense-update -zkr 25.1.3-states
Nope, not this kernel ;)
Ah sorry, think I know now what that's for
Quote from: IsaacFL on March 21, 2025, 07:33:22 PMQuote from: franco on March 17, 2025, 05:25:30 PMThe question in FreeBSD came up why these state creations are rejected. The other half of the story is the log does not actually record this at the moment either way. I wrote a small patch to diagnose: https://github.com/opnsense/src/commit/6f18c3b0164689d5cc83206499ade2f4f4016c6e
Would someone with the issue here try this kernel build and send in the plain filter log for the entries that cause spurious block log messages after boot?
# opnsense-update -zkr 25.1.3-reasonlog
(reboot)
Thanks in advance,
Franco
Im back in town and will try this patch today.
Update: Installed, can see the unexpected log entries again. Let me know when you would like me to send output of opnsense-log filter
Franco, I emailed you a copy of the filter logs and my rules.debug
I noticed after updating to 25.1.4_1 that this issue is still active.
Did the patch not get put in this update?
# opnsense-update -zkr 25.1.3-fixlog had fixed it prior
We didn't update the kernel yet for unrelated reasons. It probably reverted back to 25.1.3. Next kernel with the fix will be 25.1.5.
I got your mail, but was a bit swamped this week. Will reply next week.
Cheers,
Franco
Quote from: IsaacFL on March 28, 2025, 06:32:30 PM# opnsense-update -zkr 25.1.3-fixlog had fixed it prior
It is expected that an update will revert to the latest released kernel - so when running a custom version with a particular patch you need to either confirm the new one has the fix included or get in the GUI and lock the kernel before the updates.
The good news here is that the patched kernel is still available and you can simply run the command and reboot