Regression #15400
closed
IGMP packets are logged when the filter rule has logging disabled
0%
Description
Example rules:
pass in quick inet proto igmp pass in quick inet proto igmp allow-optsOn 23.09.1:
- IGMP packets are matched by the first rule; if the first rule is removed, the second rule will match.
- Logging is respected for both the first and second rule - i.e. a log entry is only created if
logis added to the rule. - The log entry shows
passor block as determined by the rule action:
Apr 12 10:24:55 router filterlog[89591]: 89,,,1712938789,vmx1,match,pass,in,4,0x0,,1,61477,0,none,2,igmp,32,10.0.5.50,224.0.0.251,datalength=8
- IGMP packets are matched by the first rule; if the first rule is removed, the second rule will match.
- Logging is only respected for the second rule; a log entry is always created for the first rule.
- The log entry always shows
blockfor the first rule:
Apr 12 09:56:49 gw filterlog[8789]: 338,,,1712937337,igc0.5,ip-option,block,in,4,0x0,,1,32022,0,none,2,igmp,32,10.0.5.50,224.0.0.252,datalength=8
Related issues
Updated by Marcos M about 1 year ago
It may be this is intended behavior, though it's worth clarifying if so.
Updated by Kristof Provost about 1 year ago
- Status changed from New to Not a Bug
This is intentional, in the sense that it was always meant to log, but didn't due to a bug that's now been fixed.
Specifically, the code to check for options is this: https://cgit.freebsd.org/src/tree/sys/netpfil/pf/pf.c#n8312
It forces logging to be enabled if it drops a packet due to IP options. This used to be overwritten again so no logging happened, but that's been fixed in https://cgit.freebsd.org/src/commit/sys/netpfil/pf/pf.c?id=5f840a1758b4bbb4892118f43f40c6487c17aeba
This is similar to a number of other cases, e.g. for short packets or memory allocation failures. In other words: this is intentional, and is not a bug but a bug fix.
Updated by Denny Page about 1 year ago
Kristof Provost wrote in #note-2:
This is intentional, in the sense that it was always meant to log, but didn't due to a bug that's now been fixed.
I think that fixing the missing logging is a good thing. Thanks.
I fear however that this is going to end up generating a lot of confusion. Two questions arise:- Is it possible to add some form of indicator in the firewall log as to why the packet was dropped?
- Is it possible to add a notice in the UI when selecting IGMP that allowing IP options is also required?
Updated by Jim Pingle about 1 year ago
- Related to Feature #15415: Enhanced firewall log action information display added
Updated by Andrew Almond 3 months ago
While this behavior may be intentional, it is confusing if it is caused by the default ruleset, and disabling the options "Log packets matched from the default block rules in the ruleset" and "Log packets matched from the default pass rules put in the ruleset" does not stop the log messages.
This fix/new behavior can create a lot of noise in the logs, which also results in increased disk writes.
There is the document Troubleshooting Blocked Log Entries for Legitimate Connection Packets, but it is not easy or intuitive to locate when faced with this issue.
I suggest adding a setting to not "Log packets with IP options" which either modifies the default ruleset or creates the necessary floating rules. This behavior should also be mentioned and linked on the Log Settings page.
Updated by Marcos M about 1 month ago
Is it possible to add some form of indicator in the firewall log as to why the packet was dropped?
See https://redmine.pfsense.org/issues/15415
Is it possible to add a notice in the UI when selecting IGMP that allowing IP options is also required?
Updated by Marcos M about 1 month ago
- Related to Feature #16110: Automatically check ``Allow IP options`` when IGMP is selected added
Updated by Marcos M about 1 month ago
- Related to Bug #16068: Logging of packets with IP options cannot be disabled added