how to stop logging blocked LAN IGMP?
-
@dennypage I did apply the rule.
Here's something interesting. I just went back and put a new rule in at the top of the interface 50_ENT list, ending in 718, to block IGMP any any and LOG it.
It did log it, but it ALSO logs the 2040 rule being activated. (Fig. 1) So how is a top rule on an interface taking effect AND an invisible rule I can't find anywhere (including floating) both take effect? Interesting, too, that my rule is prefaced with USER_RULE and the 2040 rule is not.
Then I edited rule 718 and just changed it to PASS instead of BLOCK, and I get BOTH a PASS and BLOCK USER_RULE (in the same second of time) log in addition to the mystery rule 2040 block log entries, which keep going on. (Fig 2)
My understanding of how rules work suggests this is not consistent with how the system is documented to work...
Fig 1:
Fig 2:
-
@johnpoz it appears not.
I now have a floating and interface rule to block these and log and both show 0 packets but a handful of state creations.
The floating rule (...5020) appears to be taking precedence of any activity and logging on the interface rule, as I would expect it to. Floating rule is logging both passes and blocks as the interface rule did in a previous experiment.
-
@Mission-Ghost We can't fully see your rules, as they are blocked by the pop-up. Does the floating rule have IP options enabled? If not, then it isn't going to match.
-
@dennypage Good catch. I think I forgot them. Hang on...
-
-
Curiously, the switch that the Roku box (and the router-on-a-stick) plug into reports no Multicast packets. The Roku box is on Port 4.
Is pfSense hallucinating?
-
@Mission-Ghost so it prob just not logging 224.0.0.2 which is all routers.
edit:
Curious what settings you have in your roku - because I am sniffing on interface my rokus are on - and not seeing any 224.0.0.2 traffic. I have 2 ultras currently being used, and they are not sending that.
-
@johnpoz said in how to stop logging blocked LAN IGMP?:
Curious what settings you have in your roku - because I am sniffing on interface my rokus are on - and not seeing any 224.0.0.2 traffic. I have 2 ultras currently being used, and they are not sending that.
IGMP v2 leave messages are sent the all routers group. You will see it only when a host turns off a multicast subscription.
Edit:
And just to be clear, all IGMPv2 and IGMPv3 messages, whether queries, reports or leaves, are sent with the router alert option. They will all trigger the rule.
-
@Mission-Ghost Can you do a quick packet capture?
Something like this:
tcpdump -i igc0 -w /tmp/igmp.pcap igmpwhere igc0 is the interface in question.
Be sure that the packet capture includes a time during which you are seeing entries logged.
-
Try to edit your rule again an add this into the advanced session:
I don't use floating rules on this one. This is just from one of my vlan interfaces.
-
@dennypage said in how to stop logging blocked LAN IGMP?:
You will see it only when a host turns off a multicast subscription.
Why is his doing it every few seconds?
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 -
original poster here. love when an old thread comes back to life!
I resolved my problem by replacing all of my Dlink access points with other brands.
-
@johnpoz said in how to stop logging blocked LAN IGMP?:
@dennypage said in how to stop logging blocked LAN IGMP?:
You will see it only when a host turns off a multicast subscription.
Why is his doing it every few seconds?
A good question. There are a couple of things that can be at play here.
The first is that IGMP requires all packets to be sent multiple times with a short interval in-between. This is how IGMP deals with lost packets. The number of times is the "robustness" value and defaults to 2, but implementations are allowed to choose any value of 2 or above.
The other is that some systems simply frequently join and leave groups on a frequent basis. Apple devices do this frequently on 224.0.0.251 (mDNS). I don't know if this is an attempt to force mDNS rediscovery (doubtful), service restarts, or some other thing I don't know of. Pretty inefficient in my book, but it only happens with mDNS --they don't do it on other addresses.
-
@Mission-Ghost said in how to stop logging blocked LAN IGMP?:
Curiously, the switch that the Roku box (and the router-on-a-stick) plug into reports no Multicast packets. The Roku box is on Port 4.
Is pfSense hallucinating?
FWIW, I would trust pfSense a lot more than I would trust multicast accounting of consumer grade switches.
-
Good morning!
I had a short service window this morning. The logs citing a nonexistent rule had continued overnight.
So I rebooted and the log entry attribution switched to my policy routing rule on the Ent vlan, which was not set to log. So I toggled the log checkbox on, saved, applied, and then repeated turning it off. No change…still log entries kept coming from it for igmp. Rebooted again. No change.
I then enabled my igmp rule at the top of the Ent vlan to pass igmp packets without logging and I got one pass log entry for that rule and the block log entries attributed to my policy routing rule resumed. So I copied the policy routing rules to a new one and deleted the one being attributed in the logs as blocking when not set to block nor log. The logs continued and were still being attributed to the now-deleted rule.
I rebooted again but the problem continued. So I then shut off udpbroadcastrelay but the logs continued. I rebooted again and the logs stopped. I then turned udpbroadcastrelay back on and the logs have remained stopped. I’m leaving my igmp pass rule in place and not changing its logging option (currently off) for now. I don’t know if the pass rule is now working or something else happened with the last reboot. Nothing obvious is apparent.
Note I have not made any changes to the roku box to which the mystery logs attribute the igmp packet. I have never seen a roku option related to igmp. Recall this all started when i was setting up the broadcast tv reciever/streamer (the HDHomeRun box) on that vlan.
In this case I don’t have D-Link access points. I have netgear. The roku and hdhomerun box though are ethernet, not wireless.
Clearly there is something screwy and buggy going on with rules, logging and igmp. I have no idea how to reproduce the problem and can’t easily experiment because it’s a production system. I’ll try the suggested packet capture later when I get a chance.
However, we should not overlook that the logs have been coming from nonexistent end-user rules or rules set to pass and not log, and rules set to capture these packets get substantially ignored.
-
@dennypage Thank you for the thoughtful response.
I ran (I have an 4200 so my interface was igc0):
tcpdump -i igc0 -w /tmp/igmp.pcap igmpfor about a full minute, and this is all I got:
I also ran it with igc0.50 for a couple of minutes to try to account for the VLAN and the results were:
Is this meaningful?
-
Can you open it in wireshark?
-
@Mission-Ghost It's a binary file. Can you post or PM it please?
-
@stephenw10 I'm getting Wireshark on my Linux box and will attempt to open the tcpdump file in due course. Thanks!
-
PMs with igmp.pcap sent with my thanks.
This afternoon I removed the two disabled IGMP pass rules, which I had set up to try to stop this logging, from pfSense and the mysterious logging still has not returned.
This seems to indicate the disabled (and even when enabled) pass rules were having no discernible effect on the logging of IGMP packets from a Roku box on the Ent network attributed to, at varying times, a non-existent or previously deleted rule, or, this morning after a reboot, the policy routing rule (!) of all things, which also was configured to not log.
This may be one of those things that is very difficult to catch and fix given it will probably happen on a production system that cannot be experimented with easily and given I don't know what triggered this to begin with. However, the three reboots seem to have cleared it for now, much like the OP discovered cleared his issue as well.
