["solved"] IGMP w options blocked on lo0 interface, filling the log, can't be silenced

stephenw10

But what's in your MulticastMediaServer alias? Since it's matching the default LAN rule below that.

johnpoz

@stephenw10 exactly - asked the same question, just because you clicked off ip options, and want this media server(s) to see this traffic doesn't mean that rule actually matched if you put in the servers actual IP address, vs the multicast addresses..

louis2

@johnpoz

dennypage

IGMP should be allowed to all.

Try this rule on the “Local” interface:

johnpoz

@louis2 well that last one is wrong.. its 239.255.255.250

so yeah its still going to log that traffic as blocked.

louis2

@johnpoz said in ["solved"] IGMP w options blocked on lo0 interface, filling the log, can't be silenced:

239.255.255.250

John you are right, I should have added that address. The problem is that '239.255.255.0' is a range not an address. I do not know the exact usage of 239.255.255.250 however it is a used control address.

However, adding that address does not solve the problem. Below a small part of my actual log

At this particular moment the log shows 244.0.0.1 Note that the shown rule set was already in place when created the picture of the log somewhat higher (showing addresses being filtered)

PIMD not yet working properly, could be due to the fact that I did not recompile it yet for FreeBSD15 current, but I am not sure about that.

Next to that I really and fully stick to my vision that rules should do what they say what they do !!!

Not logging pass rules turning in block rules and start logging ....... terrible ...

Rules affecting traffic not selected by that rule .... terrible

I really really can not accepted that as being OK !!

stephenw10

You have that rule duplicated on both those interfaces?

louis2

@stephenw10

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.

stephenw10

Are you adding it as a floating rule? It doesn't look like that but...

dennypage

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.

louis2

@dennypage @stephenw10

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

dennypage

@louis2 have you tried the simple Local rule that I posted?

louis2

@dennypage

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 !!

dennypage

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.

louis2

@dennypage

NOP !

dennypage

Please show the entire page on the Floating tab, and the entire page on the Local tab which includes the rule above.

stephenw10

Mmm, for some reason that's not matching.

Make sure that rule is actually loaded: pfctl -vsr | grep IGMP

Then grab a packet in a pcap and compare that with the running rule.

louis2

@dennypage

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

louis2

@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 1750075686

Note 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

dennypage

@louis2 said in ["solved"] IGMP w options blocked on lo0 interface, filling the log, can't be silenced:

@dennypage

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.