["solved"] IGMP w options blocked on lo0 interface, filling the log, can't be silenced
-
Please show the entire page on the Floating tab, and the entire page on the Local tab which includes the rule above.
-
Mmm, for some reason that's not matching.
Make sure that rule is actually loaded:
pfctl -vsr | grep IGMPThen grab a packet in a pcap and compare that with the running rule.
-
Denny, I really see no reason to do so. I all ready published the relevant part of the PCLAN and I do have not any floating rule related to IGMP.
If a reason to publish more, OK but I do not see any at the moment
-
@stephenw10 said in ["solved"] IGMP w options blocked on lo0 interface, filling the log, can't be silenced:
pfctl -vsr | grep IGMP
stephen here the actual rules as associated with IGMP
[25.03-BETA][admin@pfSense.lan]/root: pfctl -vsr | grep IGMP
pass in quick on GRF_Privileged inet proto igmp from any to <MulticastMediaServer> keep state (if-bound) allow-opts label "USER_RULE: Allow IGMP3 (Twonky)" label "id:1750076107" ridentifier 1750076107
pass in quick on mlxen0.16 inet proto igmp all keep state (if-bound) allow-opts label "USER_RULE: TEST TEST Allow IGMP3 (Twonky)" label "id:1750102422" ridentifier 1750102422
pass in quick on mlxen0.16 inet6 proto igmp all keep state (if-bound) allow-opts label "USER_RULE: TEST TEST Allow IGMP3 (Twonky)" label "id:1750102422" ridentifier 1750102422
pass in quick on mlxen0.16 inet proto igmp from any to <MulticastMediaServer> keep state (if-bound) allow-opts label "USER_RULE: Allow IGMP3 (Twonky)" label "id:1747646074" ridentifier 1747646074
pass in quick on mlxen0.26 inet proto igmp from any to <MulticastMediaServer> keep state (if-bound) allow-opts label "USER_RULE: Allow IGMP3 (Twonky)" label "id:1750076219" ridentifier 1750076219
pass in quick on lagg0.100 inet proto igmp from any to <MulticastMediaServer> keep state (if-bound) allow-opts label "USER_RULE: Allow IGMP3 (Twonky)" label "id:1750075686" ridentifier 1750075686Note that PCLAN is NOT a member of GRF_Privileged
PCLAN10G is.mlxen0.16= PCLAN
mlxen0.26= GUESTS
lagg0.100= Virtual Machines among them Twonky media server -
@louis2 said in ["solved"] IGMP w options blocked on lo0 interface, filling the log, can't be silenced:
I really see no reason to do so.
Oh, okay.
Here an explanation of the reason to do so:
Using the rule I gave you above should prevent any of the rules on any of your local interfaces from seeing IGMP traffic. That you indicate that they (PCLAN/PRIV10G) do still see the IGMP traffic does not add up.
I can think of 5 possible causes for this:
- The rule was not input correctly.
- The changes were not applied.
- The interfaces, PCLAN & PRIV10G, are not actually local interfaces. I.E. they have gateways on them.
- A bug in pfSense.
- A bug in the kernel.
It makes sense to eliminate 1-3 prior to considering 4 or 5. They are the most likely explanations, otherwise many others, including myself, would be experiencing problems with IGMP.
The request to provide a complete posting of the Local tab was to provide concrete verification that neither 1 & 2 are the case. I had assumed that #3 is not the case, or you would have raised this when I asked you to put a Local rule in. However, maybe I should not have assumed that... Are PCLAN and PRIV10G local interfaces?
You have come here for help. But you are only providing select snippets of information. Things you consider relevant. But it just hasn't been enough. It's very likely that something you do not consider to be relevant is in fact very relevant. I don't understand why you are being so unwilling to provide information, but it actively getting in the way of us helping you.
-
Note that I do not like the whole IGMP behavoir at all as it is now, even it hopefully works ... a bit.
But apart of all the alarms terrible, I have to recompile pimd to be sure if there is yes or no next to the rule and messages problem there is a further issue to pfSense.
I need to find an opportunity to recompile pimd (the perfectly good working beta at least on freebsd 14) and do testing
-
Hmm, well the rule looks good.
Can we see a pcap of the traffic that's triggering it?
-
Also check:
pfctl -vsr | grep -A 3 IGMPso you can see the state/evaluations on each rule.Check the actual rule number and tracker ID of the rule triggering the log by mousing over the red X in the log.
-
Sorry, I can do that now. However I know the rule which did cause the logging a couple of weeks ago.
I am very restricted at this moment because I have guests which makes it very hard to test things and I am also very busy.
I plan to recompile pimd packages (based of what is formally a beta, however which is working perfectly (I used it for years)) as soon as possible, however that will not be this week perhaps next one.
-
If you mouse over the rule you can check the actual rule number and tracker ID and then compare that with the output from pfctl -vsr:
