IGMP strangeness

[beerguzzle]

In the past week or so, my 1100 (pfsense 24.03) has developed a problem with IGMP. It does one allow and two denys. This pattern repeats in my logs, see attached example.

I do not use IGMP proxy and I have only one rule that references IGMP, an allow IPv4+6 any-to-any with logging, in my internal interface group. That rule shows no traffic, see attached.

Is this a new feature/bug of 24.03? Or is something else going on that I don't understand?

[stephenw10]

There s a change to the way multicast is handled in pf, yes. Traffic matching the pass rule but not passed because IP options are set will be blocked by that rule rather than a default rule. That's actually the correct behaviour but was broken in previous versions.
So first make sure you have IP options enabled on that IGMP rule.

https://docs.netgate.com/pfsense/en/latest/firewall/configure.html#ip-options

Steve

[johnpoz]

@stephenw10 But what is weird with this one is his rule is showing no hits. I would think if the rule is trigger it should how hits, even if doesn't actually allow because of IP options on the traffic. But the one it allowed per his rule, I take it without IP options, that should of shown in the rule as hits.. Maybe he put in the rule and posted the screen shot before it actually triggered.

@beerguzzle does your rule now show hits, ie not 0/0 in the states column?

But yeah you should go into advanced on that rule and allow for IP options.

[stephenw10]

Yeah I would expect to see something there given it does have some pass hits. Maybe the timeline of the screenshots is off.

The fact it's on an interface group could mean the interface state binding has some affect there.

[dennypage]

@stephenw10 There is also an assertion here that something prevented the options setting from taking effect without a restart. I've not experienced this myself, but it's worth noting. Perhaps there is some underlying issue?

[stephenw10]

Hmm, that's weird. It's just an option in pf. As long as the ruleset is reloaded after enabling it that should work fine. Nothing there should require a reboot.

[beerguzzle]

stephanw10 et al, thank you for the clue that fixed this issue, ie the "Allow IP Options".

Before I clicked this option on, I checked the state details on my rule to see what happened today while I was out hiking. Short answer, nada. No hits.

So then I turned on "Allow IP Options", reloaded the rules and watched the logs for a while. All of the IGMP traffic started logging as "pass", yippee. The state details for the rule also started clicking:

[dennypage]

@stephenw10 said in IGMP strangeness:

As long as the ruleset is reloaded after enabling it that should work fine. Nothing there should require a reboot.

Agreed. Only thing I could think of is that something prevented the reload from completing…

[Bob.Dig]

Just for completeness, here is my block rule for not "polluting" my log.

[SteveITS]

The setting page was linked above but since I just pasted it for someone else here is the troubleshooting page:
https://docs.netgate.com/pfsense/en/latest/troubleshooting/log-filter-blocked.html#packets-with-ip-options

[louis2]

@stephenw10

Note that I did reboot the system. Thinking that that may reset states.
And did use options
And put it on the first line of the floating rules
And Never the less, it does not work !!
The IMGP package are denied in state of passed
PIMD is telling me that the message was refused, which is in line with that blokking

See also my this afternoon for you morning post!

[stephenw10]

This is your first post in this thread I'm not sure what you're seeing or referring to.

[dennypage]

@stephenw10 First post is here. @bmeeks had pointed him at this thread to read.

[stephenw10]

Ah, OK. Do you have an example screenshot of the blocked rules?

You would still have needed IP Options set to pass that in 23.09.1. But the floating state binding probably passed it somewhere it now doesn't.

If you set the global state bindign back to floating does it work as before?

[johnpoz]

@louis2 also would really suggest you actually post the rules you have vs just saying you have this..

Users quite often say they did X, but then find out they did (Y^3+42)/12 etc.. Could be as simple as rule set to tcp vs any or igmp, etc. Or rule in floating set to outbound vs inbound or quick not selected on it

Picture can say 10k words in such cases.

[dennypage]

@stephenw10 said in IGMP strangeness:

You would still have needed IP Options set to pass that in 23.09.1. But the floating state binding probably passed it somewhere it now doesn't.

IGMP is not required for multicast to work, it just makes it more efficient. I think what is very confusing to folk is that they didn't know that IGMP was being dropped previously, and since it isn't required they saw no adverse effects. Now they are seeing IGMP drops in the logs, and on a pass rule no less. Very confusing. Many will probably not know anything about IGMP until they search the term.

I guess it's a great opportunity for folk to improve the efficiency of their networks.

[johnpoz]

@dennypage said in IGMP strangeness:

Many will probably not know anything about IGMP until they search the term.

They most likely won't know much more even after doing that ;) hehehe

[dennypage]

@dennypage said in IGMP strangeness:

@stephenw10 said in IGMP strangeness:

As long as the ruleset is reloaded after enabling it that should work fine. Nothing there should require a reboot.

Agreed. Only thing I could think of is that something prevented the reload from completing…

@stephenw10, In the other recent thread, the user indicated that after defining the rule, they needed to perform a state reset before the rule worked. Worth noting. This would also explain the situation with the user who asserted that they had to reboot.