Project

General

Profile

Actions

Regression #15400

closed

IGMP packets are logged when the filter rule has logging disabled

Added by Marcos M 8 months ago. Updated 8 months ago.

Status:
Not a Bug
Priority:
Normal
Assignee:
-
Category:
Logging
Target version:
-
Start date:
Due date:
% Done:

0%

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

Related to Feature #15415: Enhance the firewall log action hover information view, show reason infoNew

Actions
Actions #1

Updated by Marcos M 8 months ago

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

Actions #2

Updated by Kristof Provost 8 months 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 #3

Updated by Denny Page 8 months 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 #4

Updated by Jim Pingle 8 months ago

  • Related to Feature #15415: Enhance the firewall log action hover information view, show reason info added
Actions

Also available in: Atom PDF