How to stop logging of blocked IGMP packets



  • My router is connected to a bridged port of a gateway that is also used for IPTV so there is a lot of other traffic on the link. In particular, IGMP packets are being broadcasted and these packets are being blocked by pfSense. That's exactly what I'd like it to do, but I'd like to eliminate the log entries because there are a lot of them. This has been brought up before but unless I've missed something, there hasn't been a clear fix for this that doesn't involve preventing other messages from being logged. I'd like to do this selectively. If it's not possible, I'd appreciate comments on a sensible mechanism to put into redmine as a feature request. (I searched redmine but didn't see anything.)

    I tried to add a rule to block the packets without logging, but the rule never fired. I've attached a screen capture of the log which shows that the log entry is caused by a built-in rule. I don't like the idea of disabling this particular rule from being logged because the rule is much more broad than IGMP. There either needs to be a way to filter messages and selectively block them from being logged or alternatively to put a user-defined rule ahead of the built-in rule. Are there any other ways to prevent this?



  • As you can see in the log, the rule is triggered by the "Block private networks from WAN" rule. You may deactivate logging of this rule in the system log settings.




  • Your rule didn't fire because the IGMP packets are using what are called "IP options". You need to check the option in the rule advanced options that says "Allow IP options".



  • @viragomann:

    As you can see in the log, the rule is triggered by the "Block private networks from WAN" rule. You may deactivate logging of this rule in the system log settings.

    I don't want to not log all cases of this rule being triggered, only this particular case.



  • @kpa:

    Your rule didn't fire because the IGMP packets are using what are called "IP options". You need to check the option in the rule advanced options that says "Allow IP options".

    I'm not clear how that will help. The description of that option is, "Allow IP options Allow packets with IP options to pass. Otherwise they are blocked by default. This is usually only seen with multicast traffic." I don't want these packets to pass. I want them to be blocked, just not logged, because the log is being flooded with these messages.



  • @bimmerdriver:

    @kpa:

    Your rule didn't fire because the IGMP packets are using what are called "IP options". You need to check the option in the rule advanced options that says "Allow IP options".

    I'm not clear how that will help. The description of that option is, "Allow IP options Allow packets with IP options to pass. Otherwise they are blocked by default. This is usually only seen with multicast traffic." I don't want these packets to pass. I want them to be blocked, just not logged, because the log is being flooded with these messages.

    The wording of the option is slightly wrong. What it should say is "match packets that have IP options set". If you don't set the option your rule will never match packets that have IP options set and you won't be able to silence the log noise with your rule.

    What I mean with this is that normally in order to silence log noise you write a rule that matches the offending traffic and has logging turned off for the rule. This will silence the log noise because the rule matches the traffic before the default deny rule. This doesn't work for IGMP traffic unless you turn on the misnamed "Allow IP options" option for the rule.



  • @bimmerdriver:

    @viragomann:

    As you can see in the log, the rule is triggered by the "Block private networks from WAN" rule. You may deactivate logging of this rule in the system log settings.

    I don't want to not log all cases of this rule being triggered, only this particular case.

    Create a new firewall rule on your WAN link, that matches all statements. Disable logging of this firewall rule.
    In this case, other traffic will match a different WAN rule and therefore will be logged. Make sure the new firewall rule is above a "general match all".


  • LAYER 8 Global Moderator

    Other option is to turn off default logging and create a block rule that only logs the traffic you want to see in the log.  For example I don't care to see udp noise, nor do I care to see out of state tcp, etc.

    So my wan has default block logging off, I then create a block rule at the bottom that logs only tcp with syn set.  So if its blocked because its out of state then not logged, if its UDP not logged or any other protocol for that matter.

    If you want to be specific with that is not logged via rule then you need to make sure you write the rule to trigger on that specific something correctly.



  • Thanks everyone for your replies.

    I created another rule. I put it as high as possible in the list of rules. Maybe I'm missing something, but I don't see any settings to match above "general match for all". I also checked "allow ip options". It did not make any difference. The messages appearing in the log are being blocked by rule 12000. After I checked "allow ip options", a "settings widget" appeared in the rules list. I'm not clear why or what it's for.

    Screen captures are attached.

    I'm wondering if a work-around for this would be to include a field in a rule that specified any rule that should be processed before or after. In this case, since I know that rule 12000 is being triggered before this rule, if the firewall processed this rule before 12000, it would work exactly as required without changing any other behavior. Maybe it's just an ugly hack, but it seems like an easy work-around.

    UPDATE: The first screen capture was the wrong one. Fixed.

    ![Capture 3.PNG_thumb](/public/imported_attachments/1/Capture 3.PNG_thumb)
    ![Capture 3.PNG](/public/imported_attachments/1/Capture 3.PNG)
    ![Capture 2.PNG_thumb](/public/imported_attachments/1/Capture 2.PNG_thumb)
    ![Capture 2.PNG](/public/imported_attachments/1/Capture 2.PNG)


  • LAYER 8 Global Moderator

    You need to uncheck block private if you want your rule that doesn't log to be seen.

    If you want you could always create your own block private below your igmp block rule.



  • @johnpoz:

    You need to uncheck block private if you want your rule that doesn't log to be seen.

    If you want you could always create your own block private below your igmp block rule.

    Just to be clear, when you say uncheck block private, are you referring to this WAN setting:

    Reserved Networks
    Block private networks and loopback addresses
    Blocks traffic from IP addresses that are reserved for private networks per RFC 1918 (10/8, 172.16/12, 192.168/16) and unique local addresses per RFC 4193 (fc00::/7) as well as loopback addresses (127/8). This option should generally be turned on, unless this network interface resides in such a private address space, too.


  • LAYER 8 Global Moderator

    Yes that setting is on any interface to be turned on or off.

    The rule you posted as logging that traffic is that rule - which is above any rule you create on the interface.  So that rule will be seen before your rule that blocks and does not log it.

    Or looks like you can just turn off logging of this rule.  And that should stop it from flooding your logs

    Under system logs, settings




  • @johnpoz:

    Yes that setting is on any interface to be turned on or off.

    The rule you posted as logging that traffic is that rule - which is above any rule you create on the interface.  So that rule will be seen before your rule that blocks and does not log it.

    Or looks like you can just turn off logging of this rule.  And that should stop it from flooding your logs

    Under system logs, settings

    Good catch. I didn't see that setting. Much appreciated. I'll give it a try.

    Since there isn't a direct and specific way to prevent entries from blocked packets from flooding the log, I created a redmine feature request for it, https://redmine.pfsense.org/issues/6839.


Log in to reply