["solved"] IGMP w options blocked on lo0 interface, filling the log, can't be silenced
-
No, I had it only enable on the PCLAN, since it is still in an experimental stage. However I see the behavoir on multiple vlans including the PCLAN.
I did add the rule now to the guest vlan and my privileged vlan as well. To keep them equal, not that I expect it to change something.
-
Are you adding it as a floating rule? It doesn't look like that but...
-
The rule to allow IGMP must come before the default rule you have at the end of the interface. The log entries you posted show that this is not the case.
You can either use a floating rule with quick, or you can use Local. Try what I showed above. You can tighten it up later if you feel the need, but get it working first.
-
To answer your questions
Floating
No it am not using floating rules here. In short I only use floating for reasons of security or high performance.Rule position
There are a couple of things which determs the order I place rules. In short- security
- performance
- logic
Below the first part of my rule set as related to my PCLAN
-
@louis2 have you tried the simple Local rule that I posted?
-
Do you refer to
^suggest an “Allow” from all rule for IPv4/IPv6 and protocol IGMP on the “Local” interface.^No I did not yet but that rule is much wider than I like, and why should that make a difference !!???
Never the less I will add the rule for now for the PC-lan. However what ever the result is, I will remove it later on !!
-
Yea, there really is no need/reason to restrict IGMP in the local network. Especially if you are actually using IGMPv3.
Btw, your comments indicate IGMPv3, but are you actually using v3? And joining toward a specific source? IGMPv2 is much more common as a default, and many devices and software do not implement v3 correctly. FWIW, unless you really know what you are doing with multicast, and really need v3 due to the number of available/conflicting sources, you should stick with v2.
YMMV.
-
-
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.
-
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.
