how can i stop logs for ipv4 IGMP but still log default deny
-
Used pfSense at home for years. Squid and ACL's, lots of cool stuff. Recently I put in a netgate device for a friend. It's multi wan and my first time doing that. Also fun stuff. Anyway, the static IP interface is fine, but the PPPOE interface (ix0) is creating a log that looks like this
Feb 13 17:13:42 ix0 Default deny rule IPv4 (1000000103) 0.0.0.0 224.0.0.1 IGMP
at a rate of about 100 a second. Turning off bogon or private network logging does not affect it. Turning off the default deny rule does stop it. I've tried blocking all IGMP to that address on floating and ix0 interface.
I've read a lot of threads about it, and the concensus seems to be that the default deny are last in order, so creating a proper block prior should work.
I cannot play with it remotely like this though as it's in a business and I only have limited time after work at the location. If it were at my house it would be different.
Anyone have a solution? And please, if you mention turning logging off for default deny and making your own logging rules, please give a resource that goes into some detail about what sort of rules one would make, even if you don't need them. It's nice to know why rather than just doing, IMHO.
Thanks to any help.
-
Sorry, I should be more clear in the objective. I do not want this traffic logged, but I do want the default deny logged, or a resource on how to create my own logging rules. Default deny becomes a useful tool when doing things such as opening ports for inbound comms, as I can see if the default deny is the culprit or not. But when it's flooded with hundreds a second, it's about useless as a tool.
-
Hey
The simplest thing is to make a separate rule to block IGMP traffic on WAN interface without logging . Then this rule will be triggered earlier than rule 103 and there will be nothing in the logs
-
Thanks for taking the time to reply, I appreciate that. I already made that rule, reset States, but it did not stop the logging. I deleted the rule, reboot device, and made it again. Rebooted device, still did not work. I've been at a loss to explain the traffic in the first place let alone why it isn't blocked by an igmp rule. I tried the same thing on floating rules too.
If I unplug that wan the logs are what I'm used to seeing in about 8 years of using pfSense, there's some traffic, obviously some people knocking on your door, but not hundreds a second.
I've had pppoe connections and not seen this traffic before. I'm wondering if I should call the ISP and ask about it. If it's on the wan interface, I wonder how it originates at 0.0.0.0, I don't have any igmp service turned on in the device
-
@mrwaltman
Show log , please ) -
I can show you a log, but that one line that I put in my initial post is repeated with a different time stamp thousands of times over. If I turn default logging off and then I block igmp packets with an igmp rule, and tell it to log, it does not. I would be happy to give you a screenshot of the log but will it matter if every line is exactly the same?
-
@mrwaltman
If not difficult, show 2-3 lines of the firewall log
I want to see what's going on. -
Hmm, tried to format this as code, but the website said it was flagged as spam. Here it is without formatting, sorry it's ugly.
Feb 14 10:52:45 ix0 Default deny rule IPv4 (1000000103) 0.0.0.0 224.0.0.1 IGMP
Feb 14 10:52:45 ix0 Default deny rule IPv4 (1000000103) 0.0.0.0 224.0.0.1 IGMP
Feb 14 10:52:45 ix0 Default deny rule IPv4 (1000000103) 0.0.0.0 224.0.0.1 IGMP
Feb 14 10:52:45 ix0 Default deny rule IPv4 (1000000103) 0.0.0.0 224.0.0.1 IGMP
Feb 14 10:52:45 ix0 Default deny rule IPv4 (1000000103) 0.0.0.0 224.0.0.1 IGMP -
Settings for log is to show 250 entries, and all 250 are with that time stamp. Doing a refresh of the log repeats this, all 250 are in the same time stamp.
-
@mrwaltman
Ok
ix0 is the WAN interface ??
If you create a rule like the one in the picture, will it block IGMP ?
-
I just saw a single log that blocked an incoming ipv4 address to the wan. It was interesting that the default deny logs show the interface as ix0, which is correct, but that the default deny for a tcp address inbound to the wan showed the interface as what I named it rather than ix0. Might be nothing, but I hadn't seen that. Should have copied it before I looked at the interface assignment to verify it, duh.
-
Yes, ix0 is the wan for sure (wan2 actually). I don't think I want to create that kind of rule without being on site. I will try it, but don't want to cause any undue issues while they are working and I am off site.
-
https://forum.netgate.com/topic/82519/0-0-0-0-igmp-spam-in-wan-log-lan-traffic-being-blocked/23
-
Interesting. It's a WiFi connection from the business to the ISP so I have no access to a dsl modem, bit I will pass this along to the ISP and see what they say.
Thanks again for your help and time. Much appreciated.
-
I contacted the ISP. They have no idea, but it is clearly coming from their side.
On a side note, maybe there is a bug in this version of pfSense (2.4.4-RELEASE-p2 (amd64) ) or the device (SG-5100). I tried adding an easy rule, but it was invalid. Turns out I had renamed the interface WAN2, but the logs only show ix0. I changed the name back to ix0, and then the easy pass rule could be made. I enabled logging of the rule, reset states, but no difference. Default Deny still flooded logs. I rebooted device, same thing.
I would seem that if an easy rule made on that inferface cannot actually pass the IGMP packets and log them, that there is a problem. Or I could be in error somehow.
-
Can anyone explain this?
By following this thread
https://forum.netgate.com/topic/106133/how-to-stop-logging-of-blocked-igmp-packets/12I created a (block and log) floating "quick" rule on wan2 (ix0), ipv4, IGMP protocol for any source and destination, and as suggested checked "allow ip options". The interface has bogon and privates checked, the logs has only log default rule, all others are disabled (unchecked).
The only rules on that interface are to allow remote webgui and icmp.
So, if what I read is correct, it should match prior to the default deny. However, it is not doing this, at all. Reset states, reboot device, still no go.
So, is this a bug? If I literally have no rules on the interface, and unplugging every other cable so no IGMP sources could possibly exist, why is the rule not firing? If there is something else to do, it isn't referenced in that thread I pasted above.
Any thoughts? I could remove the two rules on the interface for webgui and icmp but I cannot imaging they are having an effect.
Thanks to any takers.
-
Wow. Was on site tonight. Pull WAN2 (ix0) cable, all IGMP packets stop, no logs obviously. Bogon/private logging turned off, Default deny logging was on.
Only when WAN2 cable plugged in do the IGMP blocks fill the logs at more than 250 per second.
I have only one rule now, a floating rule
States Protocol Source Port Destination Port Gateway Queue Schedule Description Actions 0 /377 KiB IPv4 IGMP * * * * * none block IGMP floatThis rule does not fire at all.
If I disconnect WAN2 interface (pppoe over wifi dsl) then the default deny logs stop, and the floating rule above starts!
It makes sense now, that the default deny rule is seeing ix0 as the INF name, not WAN2 as I've named it. It also makes sense that if I disconnect the PPPOE connection, the port is still active and the packets are still coming in, regardless of whether PPPOE has authenticated. It also would be expected I guess that the floating rule sees ix0 as the INF. On the occasion that I see a regular tcp block in the log on WAN2, it is referred to correctly (meaning not ix0).
What's odd, and maybe someone can explain, is why would the interface being authenticated to PPPOE cause the floating rule to not work at all, and indeed it would seem no IGMP rule has any effect either floating or on the WAN2 interface, while PPPOE is in connected state.
Does anyone know why or know how to alleviate this issue?
-
Seems I found a partial solution. I think the problem is that the ISP has a dsl modem somewhere prior to my wifi connection that is broadcasting IGMP packets to verify a connection with clients. I found if I disconnect the PPPOE on that interface, the IGMP packets still flood me but that the floating rule to block them applies rather than the default deny.
So, I made that floating block rule into a floating pass rule and logged it. One packet was all it took to quell the flood of IGMP multicasts. When I bring the PPPOE connection back up, the IGMP packets are gone for a given time period.
What was interesting is that if I created the same rule that was on floating (witout quickset obviously) on the interface in question, it never fires, ever. So to recap, allow or block IGMP rule on ix0 will never fire, always default deny, regardless of whether PPPOE is up or down. Floating allow or block IGMP rule on ix0 only fires when PPPOE is down, when up only Default Deny fires.
Searched and searched for PPPOE affecting interface logging or rule firing/order, could not find anything of relevance.
Sharing here for future posterity? lol.
-
After a lot of monitoring, I've concluded the physical interface (ix0) cannot filter an IGMP packet from the ISP side of the WAN when the interface is connected via PPPOE. It also will not pass it by default. Since you cannot filter it to apply a rule, it always gets blocked.
As soon as the PPPOE connection goes down, a rule on the interface works and the IGMP packet can be passed. No more IGMP packets for a day or so.
Can anyone help me build a script in chron that will simple disconnect and reconnect the interface on a schedule?