Little cosmetic issue after upgrade to 25.1.1

[Wrigleys]

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

[gpb]

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?

[Wrigleys]

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

[epyon9283]

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

[IsaacFL]

I'm seeing the same issues with logging. Still seeing today after updating and rebooting yesterday. I would not call this cosmetic.

[pfry]

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

[franco]

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

[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

[Wrigleys]

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

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

[mschaeffler]

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!

[IsaacFL]

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

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.

[meyergru]

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,


is that the old issues from fall 2024 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.

[Wrigleys]

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

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

[IsaacFL]

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

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.

[franco]

Tracking this here now, someone already confirmed the ND state tracking is wrong https://github.com/opnsense/src/issues/242