how to stop logging blocked LAN IGMP?

[JeremyJ 0]

Hey all -
My Netgate 2100 is logging blocked outgoing LAN multicast packets several times a minute. These come from the wireless access points on my network and some Windows hosts.

The log entries list the block being performed by the default PASS rule for the interface, which seems odd on the surface, but it does look like that rule takes it on itself to block IGMP.

I believe this behavior is new since 24.03.

I don't want to log these blocks because it obscures more interesting log entries. Suggestions?

[dennypage]

@JeremyJ-0 Here are a few references:

https://docs.netgate.com/pfsense/en/latest/troubleshooting/log-filter-blocked.html#packets-with-ip-options

https://forum.netgate.com/topic/187316/multiple-users-24-03-r-20240410-1729-igmp-block-gets-logged
https://forum.netgate.com/topic/187663/just-installed-the-release-something-wrong-with-multicast

https://redmine.pfsense.org/issues/15400
https://redmine.pfsense.org/issues/15415

[JeremyJ 0]

@dennypage thanks for the information - looks like this has been thoroughly discussed but I can't replicate the resolution.

I tried checking the 'allow IP options' box in the advanced settings on the rule, saved and reloaded, and the behavior did not change. Apparently, the new code does not consider IGMP an IP option.

I tried copying the default pass rule, changing the protocol to IGMP and the action to block, and placing that rule above the default pass rule, and reloading (leaving the 'log packets' box unchecked, obv). The behavior did not change.

I think a code change that requires user action to preserve previous behavior deserves a mention in the release notes - and I don't see anything there to clue us in.

[dennypage]

@JeremyJ-0 said in how to stop logging blocked LAN IGMP?:

I tried checking the 'allow IP options' box in the advanced settings on the rule, saved and reloaded, and the behavior did not change. Apparently, the new code does not consider IGMP an IP option.

IGMP is a protocol above IP. The 'options' refer to options at the IP layer. IGMP packets require the use of IP options. By default, the firewall blocks packets that have options are the IP layer.

To allow IGMP, you will need to have a pass rule that specifies Protocol IGMP, and has "Allow IP options" checked in the Advanced section.

[JeremyJ 0]

@dennypage

Thanks, that explains it. I added 'allow IP options' to the new 'silent block IGMP' rule, and it works now.

[Bob.Dig]

@JeremyJ-0 said in how to stop logging blocked LAN IGMP?:

I added 'allow IP options' to the new 'silent block IGMP' rule, and it works now.

For me the IGMP-block-rule worked without the IP-options.

[johnpoz]

@Bob-Dig if you put in a rule to block igmp or destination before it hit your allow rule that would match on the traffic, like an any any where it would see the igmp, and say hey wait this has ip options set vs allowing this I am going to block it then yes your block rule without logging would work.

[dennypage]

IGMP isn't a bad thing. On LAN interfaces, it is something you should pass rather than block.

If you really don't want to use IGMP, you should turn it off in your switch or router rather than blocking it on the firewall.

[JeremyJ 0]

@dennypage good point.

I changed the 'silent block' to a 'silent pass', but it behaved the same as the default pass rule: it blocks IGMP (even though the rule is explicitly a pass) and logs each instance (even though the rule is set to not log).

It appears that the new release has some kind of special code path for this that defies normal handling.

So, back to blocking it. I don't have the skills or energy to turn off the IGMP sources on my LAN and I don't want those log entries.

[dennypage]

@JeremyJ-0 You have to have IP options enabled in the pass rule.

Edit: Mine is a floating rule, but here's what it looks like:

Spoiler

login-to-view
login-to-view
login-to-view

[JeremyJ 0]

@dennypage actually tried it both ways. same result. it's silent as a block rule, and noisy as a pass rule.

login-to-view

login-to-view

[dennypage]

@JeremyJ-0 Source should be any rather than LAN subnets.

I edited my post above and put in my floating rule which handles IGMP.

[JeremyJ 0]

@dennypage did my level best to match your rule: made mine floating, checked 'quick', changed direction to 'in'. It's not exact because I need it to apply to multiple sources where yours is specific to one so left source as 'all'.

Still getting deny entries in the log.

[dennypage]

@JeremyJ-0 You do not need to restrict it. You can, and should, use "any" unless you have a good reason not to.

Do exactly this:

login-to-view

login-to-view

Make sure the rule is above your default allow.

[dennypage]

@JeremyJ-0 Just to be sure, you are doing Apply Changes after modifying the rules, yes?

Btw, in Redmine 15415 there is a small patch that you can use to enhance the hover tooltip in the firewall log. It will show "block/ip-option" in the tooltip if the packet was blocked due to the presence of IP options.

[johnpoz]

@dennypage said in how to stop logging blocked LAN IGMP?:

It will show "block/ip-option" in the tooltip if the packet was blocked due to the presence of IP options.

Isn't that kind of obvious when the rule name is pass, but its a block and the protocol is IGMP ;)

[JeremyJ 0]

Yes, I 'apply changes' and wait for the filter to reload.

Update: after the last round of changes (moving rule to floating etc.) things were worse: the silent block rule was logging the blocked packets too.

I rebooted. The excess logging stopped.

Is there some part of the firewall that reads the rules on startup and does not re-read on a filter reload?

[dennypage]

@JeremyJ-0 said in how to stop logging blocked LAN IGMP?:

Is there some part of the firewall that reads the rules on startup and does not re-read on a filter reload?

Not that I am aware of.

The reload of rules failing would explain your results however.