["solved"] IGMP w options blocked on lo0 interface, filling the log, can't be silenced
-
@louis2 well that sure looks like just not having ip options set. Create a rule above the default allow that either blocks or allows that traffic and don't log it.
Or allow ip options on your default allow rule.
Pfsense more likely than not isn't going to do anything with that traffic anyway.. Not unless you want avahi or pimd running and doing something.
There should prob be a log setting not to log such noise.. How you turn off logging bogon/rfc and default deny, etc. I haven't looked in 2.8 or the 25.03 better - maybe there is?
-
John we had that discussion before. But two things here (also see Sevire issues related to IGMP multicast traffic)
- pass rules without logging should never ever become block rules with logging
- and yep despite that an knowing this completely wrong behavoir I did put a rule in front of other rules WITH options set, but even that does not help !!!
- and apart from that what really happens is completely unclear!
So .... really nothing is behaving here like it should !!
The title in the bar is not completely valid, but that is not important here. (example copied from my pclan ruleset)
-
@louis2 and what cidrs do you in that alias? I take it you have ip options selected in that rule? since see the gear on it. If it includes the multicast destinations being sent, then I agree that shouldn't log.
I also agree that blocking on an allow rule especially if any any rule is bit odd, and can be confusing. if the ip options doesn't match the allow rule - then it should fall through and be logged by default deny.
If have any any, with ip options not allowed - and traffic has ip options the traffic should just not match and fall through.
-
@louis2 The important thing to keep in mind is that you must have allow IP options set in the rule if you expect it to match a packet with the router alert flag set.
Suggest an “Allow” from all rule for IPv4/IPv6 and protocol IGMP on the “Local” interface.
-
Yup the change in behaviour there is confusion I agree. It logs on whatever matched the traffic, even if that was pass rule, if IP options are no allowed. This is the correct behaviour now, it was broken for years!
-
IMHO the behavoir is fully incorrect! But apart from that I have options set.
Also see part of my rule stack higher up.
Note I am running pfSense+ latest beta
-
But what's in your
MulticastMediaServeralias? Since it's matching the default LAN rule below that. -
@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..
-
-
IGMP should be allowed to all.
Try this rule on the “Local” interface:
-
@louis2 well that last one is wrong.. its 239.255.255.250
so yeah its still going to log that traffic as blocked.
-
@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 !!
-
You have that rule duplicated on both those interfaces?
-
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.
