Unable to stop IGMP traffic logging
-
Hello,
version pfSense+ 23.05
hardware : Netgate 1537Logs are flooded with IGMP traffic, there are hundreds of records, as shown below :
LAN Default allow LAN to any rule (100000101) 192.168.20.145 224.0.0.22 IGMP
LAN Default allow LAN to any rule (100000101) 192.168.20.71 224.0.0.22 IGMP
LAN Default allow LAN to any rule (100000101) 192.168.20.167 224.0.0.22 IGMP
LAN Default allow LAN to any rule (100000101) 192.168.20.72 224.0.0.22 IGMP
LAN Default allow LAN to any rule (100000101) 192.168.20.171 224.0.0.22 IGMP
LAN Default allow LAN to any rule (100000101) 192.168.20.150 224.0.0.22 IGMP
LAN Default allow LAN to any rule (100000101) 192.168.20.146 224.0.0.22 IGMP
LAN Default allow LAN to any rule (100000101) 192.168.20.207 224.0.0.22 IGMP
LAN Default allow LAN to any rule (100000101) 192.168.20.189 224.0.0.22 IGMPI do not log traffic in pass filter rules
"Log packets matched from the default pass rules put in the ruleset" is not checked under 'System Logs/Settings'
Adding a filter rule to block IGMP traffic on the LAN interface or in floating rules doesn't change anything (IGMP is still logged as Pass traffic, rule as no impact ..)I've done a lot of research but I can't find anything to solve this problem, any idea ?
Thanks for your help :)
-
@jch can you post your rules?
What is set here.. Your saying this is not checked..
Is it set on the rule itself, or on a rule in floating? Please post screenshot of your lan and floating rules.
-
Here are the screenshots :
What i did :
Status / Filter reload
System log / Settings / Reset log FilesSame result, IGMP flow are still logged :
-
Did you ever have logging enabled on the default rule?
When you ran Status > Filter Reload does it complete without error? Do you have any alerts/notices showing?
Steve
-
Yes, I had activated it at the beginning for debugging purposes, then i disabled it.
Filter reload do not produce any error as you can see :
And there is nothing relevant in the system logs either
-
Ok, and no alerts showing after running that?
Check the ruleset file dircetly:
grep 100000101 /tmp/rules.debug
Does it show logging on that rule?
-
yes, i confirm there is no alert after running 'Reload filter' and no logging option on this rule :
-
Hmm, OK. And just to confirm you are still seeing new entries being logged in the firewall log for that?
Just for completeness check:
pfctl -vsr | grep 100000101
Make sure that actual running rule also shows that.
Also check the IGMP block rule you added is present there. That should prevent anything hitting the pass rule anyway.
-
Also to confirm can I assume you did not see these logged before you enabled logging n the rule during testing?
And that you have rebooted the firewall since this started and it makes no difference?
-
-
Right, it was after using the logging options in the rules that the logs appeared.
I haven't performed a reroot or reboot since the production deployment, but i can't do it now, i have to wait until tonight, i'll let you knowMany thanks for your help !
-
The floating rule is not set as quick so it would still hit the pass rule on LAN after that. Though it shouldn't because the block rule on LAN should catch it.
Try setting that floating rule to 'quick' though.
-
@jch have you tried removing the destination in the rule, it is a broadcast address? Your rules shows that the the the IGMP rule is never triggered, states = 0/0. I found an old and disabled IGMP reject rule among my rules and I remember that one working. It is defined without destination address.
-
I added the 'Quick' option but the problem remains :
-
Same result :
-
Hmm, try enabling 'IP Options' in the advanced settings on that floating block rule.
Normally you would need to enable IP Options to pass multicast traffic like that.
-
Thanks for this advice, i checked this option but IGMP flows continue to be logged as 'Pass' traffic.
I'm going to do a reboot later, i'll let you know, Thanks ! -
Problem solved, IGMP logs flooding disappeared after reboot, it's some kind of bug ..
Thanks again for your help :) -
Hmm, bizarre! Glad it was solved.