how to stop logging blocked LAN IGMP?
-
@johnpoz thanks for the detailed post. It gave me a couple of ideas but it's getting late here too so I didn't do too much. It's a fascinating, if frustrating, problem.
I created a blocking rule at the top of the 50 VLAN blocking IGMP with allow ip options to no effect. There are a few packets and kb showing up in the block rule but the logs keep coming from my pass rule. The pass rule is set to not log. I made sure all the pass rules in the 50 VLAN have allow ip options enabled, to no effect. The logs just keep coming.
I tried a similar fast floating block rule on all VLAN interfaces to no effect.
I unplugged the HDHomeRun box associated with all this starting (but not apparently causing it) to no effect.
So I finally tried going nuclear and put a block any protocol, any source, any destination with allow ip options at the top of the 50 VLAN rule set and the logs keep coming. From the PASS rule at the bottom of the list! No effect.
Theoretically, that block should block all 50 VLAN traffic. Full stop. Right? It shows zero states and a couple of kb.
Something funky going on...
I'll try reboot(s) again next chance I get, but that won't really diagnose what's going on even if it works.
-
@Mission-Ghost said in how to stop logging blocked LAN IGMP?:
50 VLAN blocking IGMP with allow ip options to no effect
There shouldn't be any reason to set that if your blocking igmp before it gets to your allow rule. my rule is just block igmp, I set no advanced options in the rule.
If you put in a nuclear block rule like any any at the top, keep in mind states would still allow traffic. But a block that would match for igmp wouldn't create a state. So yeah that should have stopped igmp traffic from getting to any allow rules that would of allowed it and said hey wait that is ip options set and shown the block log.
If you put in a nuclear rule at the top - and your still seeing log, kind of points to the rules are are not actually loading.
-
@johnpoz I haven't been clearing the state table, so that's something I should try. I always forget about states of the living dead. While it shouldn't wreck everything like a reboot I'll need to do it during a more quiet time.
I have been watching the rule reload to be sure it's done before checking the logs. I haven't read the whole rule reload output but maybe there's something in there.
This isn't an awful problem, but it adds wear to the SSD and fills up the firewall log with nothing useful and it should be something I should have easy control over. Coulda shoulda woulda.
-
@Mission-Ghost said in how to stop logging blocked LAN IGMP?:
fills up the firewall log with nothing useful
exactly - a full log, makes it hard to spot problems that could/should be addressed, etc.
And with seeing traffic on multiple interfaces that shouldn't be there - its clear your network is not running optimally that is for sure. In a proper setup you should never see such traffic.. There should be no way traffic from X network shows up as source into the Y network interface..
With that much multicast - I can't believe your wifi is running the best it could.. Multicast/Broadcast is not wifi friend.. This sort traffic runs at much lower speed (basic rate). Which slows down the whole wifi network..
If you looking for the best wifi - you would look to minimize/remove any multicast or broadcast that is not actually required. This is why many wifi AP have the ability to actually block multicast, or convert multicast to unicast..
While you might not notice it on a wired network if you have a ton of multicast - you will notice it on your wifi that is for sure.
-
Interesting end to this chapter: unbidden logging stopped early this morning when Starlink forced a reboot of our dish. At the same second pfsense killed the states during failover to the THMI backup.
-
@Mission-Ghost I would still look into why your seeing traffic on different interfaces, even if not logged. Just not logging noise doesn't mean its still not happening. You should never see traffic from vlan X as source into vlan Y interface.. Unless vlan Y interface was a transit/connector network and you had a router downstream that these networks were attached too.
And that wouldn't be multicast that is for sure.
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 said in how to stop logging blocked LAN IGMP?:
I would still look into why your seeing traffic on different interfaces, even if not logged. Just not logging noise doesn't mean it's still not happening. You should never see traffic from vlan X as source into vlan Y interface..
Absolutely. Until that is understood and fixed, from a security pov I would assume that VLAN segregation is not working, and everything is just one big happy network...
Unless vlan Y interface was a transit/connector network and you had a router downstream that these networks were attached too.
On Netgear?
-
The special issue with igmp is what's discussed here: https://redmine.pfsense.org/issues/15400
If the traffic is blocked because ip options are not allowed it will always log that. So if it hits that policy routing rule it will log a block. That is the expected behaviour. Even if most users don't expect it! (including me).
Try adding a pass rule for that traffic without logging and make sure that prevents the logs.
-
@stephenw10 following the trail from the referenced issue we find a commit to the pfSense repo: commit link.
This includes code and configuration changes to allow the user to inhibit these log entries directly and explicitly.
I don't know what pfSense release this applies to or whether it can be applied as a patch to 25.07.1.
-
It's in the 25.11-beta images if you're able to test that. Let me check the patch....
-
@JeremyJ-0 In the context of IGMP, that is obviated by this which automatically enables IP options when the rule is for IGMP.
-
You can apply that commit against 25.07.1 and you can just fetch it using the commit ID. If you want to test that.
-
With that new option unchecked you should not longer see the traffic logged as dropped by the pass policy routing rule. If it hits that.
-
@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?
