IGMP strangeness
-
@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?
-
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.
-
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:
-
@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…
-
Just for completeness, here is my block rule for not "polluting" my log.
-
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 -
B bmeeks referenced this topic on
-
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 blokkingSee also my this afternoon for you morning post!
-
This is your first post in this thread I'm not sure what you're seeing or referring to.
-
@stephenw10 First post is here. @bmeeks had pointed him at this thread to read.
-
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?
-
@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.
-
@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.
-
@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 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.
-
S SteveITS referenced this topic on
-
S SteveITS referenced this topic on
