How to silence logging for packets dropped due to IP options?

beatvjiking

@johnpoz No pfblocker or UPnP. We have one URL alias rule that pulls in the emerging threats list and quickdrops anything bound to those IPs, but we also have that same rule in other locations that don't have this problem.

Come to think of it, (@4294967295) would indicate an overflow in a 32-bit value, right?

johnpoz

@beatvjiking seems something like that yeah.

ex1580

Thanks for posting this! I was seeing some IGMP packets at one of my clients sites and created a rule to suppress the logging. Then I came here to see if anyone else was seeing this. I still think it's odd that a rule with logging tuned off can still log. Anyway, problem solved.

SteveITS

@ex1580 said in How to silence logging for packets dropped due to IP options?:

still think it's odd that a rule with logging tuned off can still log.

It's a "feature" added in 24.03 I believe.
https://docs.netgate.com/pfsense/en/latest/troubleshooting/log-filter-blocked.html#packets-with-ip-options

ex1580

@SteveITS said in How to silence logging for packets dropped due to IP options?:

https://docs.netgate.com/pfsense/en/latest/troubleshooting/log-filter-blocked.html#packets-with-ip-options

Thanks for the link Steve! I normally expect a packet that doesn't match an allow rule to be passed on to the next rule. I suppose in this instance it "kinda" matches (source/destination match but the IP Option is not allowed).

I have not come across a reason to need to allow IP Options at the firewall on any of my networks so I guess the rule to block those packets will end up in my standard configuration less the firewall log get filled with garbage.

SteveITS

@ex1580 I suppose, if it didn't match the allow, it would fall through to the default block rule which could also be confusing because one might expect it to match the allow rule. Not logging a block might also be confusing. Adding a block rule to every interface on every router by default is probably also not great. I would guess, there wasn't a great solution.

We have also started adding the rule as we upgrade client routers.

johnpoz

What sort of devices are generating this traffic? I had to craft specific igmp traffic to see this rule kick in.. But yeah with @SteveITS not sure what other sort of way to do this that would be better.

Blocking the traffic that has IP options set unless specifically allowed is a good thing.. But how to show that in the log that wouldn't confuse the typical user is the hard part.

The only thing that might be an improvement.. Is a check box in the logging setup, you know where you can disable logging of say the default deny, rfc and bogon rules, etc. They could add say add a don't log block of igmp that has IP options set, or something like that.

SteveITS

@johnpoz said in How to silence logging for packets dropped due to IP options?:

What sort of devices are generating this traffic?

I have not tried to track it down, tbh, but it's on every network so far, that is on 24.03.

A checkbox would be handy. I think, it would always need to be the last rule? And/or hidden. And/or made clear it doesn't affect logging of not-the-last-rule rules.

The down side to all this is, the constant logging on eMMC storage which has a more limited write life than SSD. (which is why we always turn off the default block logging)

ex1580

I like the checkbox idea!

As for what is causing the traffic I do not know, but I would guess it's some sort of media software similar to bonjour.

johnpoz

Yeah I am not a fan of multicast noise to be honest, I have some stuff that generates it that I can disable it at the device - freaking plex! ;) so I block the noise makers at the switch level. But I don't block that specific igmp traffic - but yeah noise makers can be "noisy" ;)

I don't log default either - I have the rules in place to log what I want to log.. ie syn traffic to my wan for example, common udp ports.. Just because I am curious to see it..

But I would be curious to what is sending out igmp with options - since I don't see any of that on my network.. But yeah I am sure there could be many noise making applications or devices.. I can understand why unwanted things in the logs can be problematic - logs filled with noise make it harder to see the interesting log entries, etc.

ahking19

@johnpoz I found it on my network coming from my Unifi switch. Specifically the IGMP snooping setting under networks.

johnpoz

@ahking19 ah yeah that would do it ;) Since I don't use any multicast on my network - there is little reason to have switches and or AP be doing any snooping of it ;) heheh

beatvjiking

@johnpoz there are lots of bonjour devices that rely on this traffic. We use conference room presentation systems that rely on the traffic for clients to mirror screens wirelessly. Otherwise I'd block it at the switch level and forget about it :)

johnpoz

@beatvjiking said in How to silence logging for packets dropped due to IP options?:

lots of bonjour devices

Noise bots ;)