how to stop logging blocked LAN IGMP?
-
@stephenw10 said in how to stop logging blocked LAN IGMP?:
If the traffic is blocked because ip options are not allowed it will always log that
if blocked because of options on an allow rule that doesn't have allow options.. I think the way you phrased that is not quite right - or maybe I am just being dense.
But see my post from above - I set a block rule for igmp above my allow (that was logging it because of the IP options) and no more logging of of the igmp becase ip option and allow doesn't allow that.
My block rule just blocks igmp completely, no matter what dest IP, or if options would be on it or not. The block rule just says hey you from this network, and you are igmp - your blocked, and its not logged.. So the allow rule would never see any igmp traffic.
I just do not see a reason to allow it - what would pfsense be doing with igmp traffic, I am not thinking of really any scenario.. Unless you were doing something with avahi, etc. which goes to 224.0.0.251, which you could just allow this block, or in a floating to that specific destination IP.
edit:
The ability to not log such blocks with a checkbox is nice, just like you can say don't log bogon/rfc1818, default, etc. To be honest such an option should of been included when they first started blocking ip options with an allow rule ;)An intelligent man is sometimes forced to be drunk to spend time with his fools
If you get confused: Listen to the Music Play
Please don't Chat/PM me for help, unless mod related
SG-4860 25.07.1 | Lab VMs 2.8.1, 25.07.1 -
Mmm, if it's blocked before it hits the pass rule then it should never hit it and hence you shouldn't see it blocked because of IP Options. As I understand it at least!
I recall being blown away seeing a log entry for traffic blocked by a pass rule. And fully expected confusion from users.
-
@johnpoz said in how to stop logging blocked LAN IGMP?:
I just do not see a reason to allow it - what would pfsense be doing with igmp traffic, I am not thinking of really any scenario.. Unless you were doing something with avahi, etc. which goes to 224.0.0.251, which you could just allow this block, or in a floating to that specific destination IP.
You might not use it, but others do. If you have a switch that does snooping, and block all IGMP traffic, you will loose everything in the Local Network Control Block with the exception of 224.0.0.1. This includes several routing protocols, HSRP & VRRP, mDNS & LLMNR. This may not be desirable for everyone.
-
@stephenw10 I'm no longer a good test case due to the workaround I chose last year: replacing the APs which generated the IGMP packets!
Maybe someone involved in this new flare-up can do it.
Glad to see new options on the table so admins can configure to suit local needs.
-
Mmmmkay...I made a new thread about the Multicast functions of the Netgear Access points and what to do about them, here.
-
@dennypage not saying it doesn't have uses - what are you doing specifically on pfsense with it? Sure you can do all kinds of stuff with at your switches - what does pfsense do with it?
What is pfsense going to do with traffic to 224.0.0.2?
An intelligent man is sometimes forced to be drunk to spend time with his fools
If you get confused: Listen to the Music Play
Please don't Chat/PM me for help, unless mod related
SG-4860 25.07.1 | Lab VMs 2.8.1, 25.07.1 -
@johnpoz I did a pcap on igco.50 this evening after shutting off all the Multicast stuff on the WAX610s including mDNS Gateway function and did not see any subnets other than the .50 and the multicast destinations.
Is this indicative of the traffic no longer showing up on the other interfaces as prescribed, or am I missing something in the Wireshark analysis of the pcap file?
-
@stephenw10 I've applied the patch to my 25.07.1 and disabled the logging from the logging config page.
However, logging had stopped anyway early this morning when the primary internet service, Starlink, rebooted, and had not resumed.
So, I can't tell if it works or not but it's enabled and if the logging never resumes then I could be working! Thank you!
-
@johnpoz said in how to stop logging blocked LAN IGMP?:
what are you doing specifically on pfsense with it? Sure you can do all kinds of stuff with at your switches - what does pfsense do with it?
What is pfsense going to do with traffic to 224.0.0.2?
Wait one...
-
The patch for IP options requires a binary change to filterlog, i.e. for it to work you need to update to 25.11.
-
Thanks. I’ll apply the update when it’s released into production.
-
@dennypage said in how to stop logging blocked LAN IGMP?:
Wait one...
Wait 1 week, 1 month, 1 year? hehehe ;) Its been over a week, so month? hahahah
-
@johnpoz said in how to stop logging blocked LAN IGMP?:
@dennypage said in how to stop logging blocked LAN IGMP?:
Wait one...
Wait 1 week, 1 month, 1 year? hehehe ;) Its been over a week, so month? hahahah
It was only a few days, but I forgot. Been real busy.
Multicast Bridge had been published, and I am working on the package to go with it.
-
@dennypage not really what I asked to be honest - out of the box what would pfsense do with traffic to 224.0.0.2 that someone would want to happen? bridging your multicast between networks that pfsense is connected to was not my question.
What use currently would some user have with allowing 224.0.0.2 to pfsense - for pfsense to process?
-
@johnpoz said in how to stop logging blocked LAN IGMP?:
not really what I asked to be honest - out of the box what would pfsense do with traffic to 224.0.0.2 that someone would want to happen? bridging your multicast between networks that pfsense is connected to was not my question.
Sigh. Out of the box, pfSense doesn't do a lot of things, so narrowing the question to 224.0.0.2 isn't meaningful. The high level question was about the value of IGMP.
I know that you hate multicast, and it's okay that you do. But that doesn't mean everyone else has to hate it as well. There are a lot of things in the world that depend upon multicast, including routing protocols, which means IGMP and MLD are important protocols in the network.
-
@dennypage not a fan no - but not really the point.. So pfsense doesn't do anything with it out of the box.. So your statement that you should allow vs block was my point. If there is nothing pfsense is going to do with it, and it cluttering up your logs anyway.. Why would you not just block it an be done.. And just prevent it from going any further up that stack that nothing is going to happen with anyway.
Again going to stress that multicast for sure has lots of benefit and uses - if your using it.. But more likely than not typical home user or smb is going to have little use for it.
An intelligent man is sometimes forced to be drunk to spend time with his fools
If you get confused: Listen to the Music Play
Please don't Chat/PM me for help, unless mod related
SG-4860 25.07.1 | Lab VMs 2.8.1, 25.07.1 -
Rewinding back a year to the start of this post: on my home network (single class C, no vlans) I don't care whether IGMP is passed, blocked or just plain ignored - but I don't want my logs cluttered. Until this promising new patch I was unable to silence those log entries via rules or UI changes, and ended up ditching perfectly good wifi access points just because they were IGMP chatbots even in AP mode.
-
@johnpoz said in how to stop logging blocked LAN IGMP?:
If there is nothing pfsense is going to do with it, and it cluttering up your logs anyway.. Why would you not just block it an be done.. And just prevent it from going any further up that stack that nothing is going to happen with anyway.
A good deal of home gear supports IGMP snooping these days, and some have it enabled by default now. Almost all smb gear support snooping.
As noted previously, if snooping is enabled and you block IGMP, some important things are not going to work correctly. mDNS is a shining example. VRRP and CARP are also good examples. It's true that a lot of home users don't run redundant setups needing VRRP or CARP, but smb certainly does.
Again going to stress that multicast for sure has lots of benefit and uses - if your using it.. But more likely than not typical home user or smb is going to have little use for it.
No, almost every home or smb user depends heavily on upon multicast, whether they know it or not. mDNS has become a critical network service for just about everything related to discovery or interoperability on the local network. Printing, file sharing, audio, home automation, etc. -- they all depend upon multicast.
There's a lot of desire out there to segregate various systems in to trusted and untrusted network segments, usually for good reason. When you segment like this, you also need to be able to route multicast between the segments or things break. This is where things like mdns-bridge and mcast-bridge become necessary.
