Regression #15400: IGMP packets are logged when the filter rule has logging disabled - pfSense - pfSense bugtracker

Actions

Copy link

Regression #15400

closed

IGMP packets are logged when the filter rule has logging disabled

Added by Marcos M about 1 year ago. Updated about 2 months ago.

Status:

Not a Bug

Priority:

Normal

Assignee:

Category:

Logging

Target version:

Start date:

Due date:

% Done:

Estimated time:

Plus Target Version:

Release Notes:

Default

Affected Version:

2.8.0

Affected Architecture:

Description

Example rules:

pass in quick inet proto igmp
pass in quick inet proto igmp allow-opts

On 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 log is added to the rule.

The log entry shows pass or 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

On 24.03:

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 block for 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

Actions

Copy link

Updated by Marcos M about 1 year ago

It may be this is intended behavior, though it's worth clarifying if so.

Actions

Copy link

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.

Actions

Copy link

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?

Actions

Copy link

Updated by Jim Pingle about 1 year ago

Related to Feature #15415: Enhanced firewall log action information display added

Actions

Copy link

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.

Actions

Copy link