How to deal with [::] -> [ff02:: 16] log entries in firewall log

[fabnavigator]

Hi,

I've been trying to figure out if I can do anything to suppress these firewall log entries that are logged by the default rules.

Should they be blocked, and if so, can I create a rule to block them without logging?

Or should I create a rule to pass them?

[Uglybrian]

Hi, The red X shows that it is already being blocked. I would create a rule with no logging. You are not alone I also have the @4292967295 show up on my firewall logs periodically. Even less so now after tightening up some of my firewall rules.
In case you have not search the forums , here are a couple of threads that may give you some insight.

https://forum.netgate.com/topic/199774/what-is-rule-4294967295?_=1770073614763

https://forum.netgate.com/topic/184869/rule-4294967295?_=1770073614746

[fabnavigator]

@Uglybrian Thank you for your response. I didn't see anything in those links to help me create a rule to block these log entries. I've tried but no success. There must be something about the source "[::]" that causes it not to match "any".

[tinfoilmatt]

Looks this this should be resolved in 25.11.1:

https://redmine.pfsense.org/issues/16579

[fabnavigator]

@tinfoilmatt I'm not referring to how the log entries are parsed, but how to create a rule to prevent them from getting logged in the first place. I ended up unchecking the option to log packets blocked due to IP options.

[tinfoilmatt]

@fabnavigator It's a logging bug that's patched in the linked report.

[tinfoilmatt]

Source/destination, and protocol for that matter, are red herrings. If you hovered over the red X on one of these blocks, you'd likely see "Reason: fragment".

[fabnavigator]

@tinfoilmatt I got these on 25.11.1.

[tinfoilmatt]

Interesting. Not clear to me if this patch actually made it into 25.11.1 even though the bug report says that it's the targeted version.

Try to obtain these two things:

1.) Screencap of the red 'X' tooltip for one of these blocks.
2.) The full logging line for one of these blocks from /var/log/filter.log logfile.

[tinfoilmatt]

25.11.1 release notes confirm the patch from the linked bug report made it in.

[fabnavigator]

@tinfoilmatt

[tinfoilmatt]

Try to capture one of these packets to see if you can figure out what host on the same broadcast domain as the "LAN5_ANDROID" interface is multicasting these listener reports from a 'null' (i.e., "::") IPv6 address.

[fabnavigator]

@tinfoilmatt I'm not sure how to set that up. The packet capture would have to run for a day or so unattended in order to capture one of these.

[tinfoilmatt]

Like this but on interface "LAN5_ANDROID":

I'm not 100% sure on the IPv6 syntax there. So if you see a log entry but no packet appears in the capture, try ":: ff02::16" in both places instead of "::0 ff02::16". It's definitely one or the other.

[fabnavigator]

I think we are getting off track. I'm not necessarily looking for the source. I'm seeing these on three VLANS. I just wanted to create arule that would match these, and I've had no success.

[tinfoilmatt]

@fabnavigator Are you running Avahi, IGMP Proxy, or PIMD packages?

You don't want to clean up your network?

[fabnavigator]

@tinfoilmatt I am not using any of those. Yes. I do want to clean up my network. That's why I look at my firewall log.

[tinfoilmatt]

So then run the capture to get more detail about what's presumably multicasting MLD listener reports with a source IPv6 address of ::. It's really not a big deal.

[dennypage]

@fabnavigator This is MLD (the IPv6 equivalent of IGMP). Nothing to be alarmed about. If you want a more efficient network, pass them. If you don't care, you can block them.

A rule for these would look like this:

[tinfoilmatt]

Glad you chimed in on this point. In your extensive experience with multicast, is it normal for a network host to be broadmulticasting these MLD listener queries from a 'null' IPv6 address?