Rules to reduce logging noise



  • In order to reduce the number of log entries coming from the default block rules, I created some rules to block multicast and broadcast traffic without logging.  The majority of the log noise went away but there's still one log entry sneaking by that I can't seem to catch:

    Interface: LAN
    Source: 169.254.165.6:1400
    Destination: 239.255.255.250:1900
    Protocol: UDP
    Ruleset: Block IPv4 link-local (1000000101)

    When I look at my rules on the LAN, I have the following rule that should apply:

    Action: Block
    Interface: LAN
    TCP/IP Version: IPv4 + IPv6
    Protocol: any
    Source: any
    Destination: Alias "Multicast" (contains 224.0.0.0/4 and ff00::/8)
    Log: not checked

    This block rule is first in the list of LAN rules.

    I've tried creating various rules to explicit block the culprit entry (e.g. IPv4, UDP, source any, destination 239.255.255.250), and tried adding 239.255.255.250/32 IP to my Multicast alias, but it always matches to this Block IPv4 link-local rule and logs it.

    Does anyone have any ideas why this packet is sneaking through?


  • Banned

    @jhuntitg:

    In order to reduce the number of log entries coming from the default block rules



  • I don't want to remove the default logging because I want to log what's being blocked.

    Why doesn't the rule I created catch this particular multicast packet?  It caught all the other ones that were coming through …


  • Banned

    @jhuntitg:

    I don't want to remove the default logging because I want to log what's being blocked.

    That's being done by default… Kinda the opposite of the goal in the OP.

    @jhuntitg:

    Why doesn't the rule I created catch this particular multicast packet?  It caught all the other ones that were coming through …

    No idea. You could instead focus on why isn't that host getting a proper IP and falls back to APIPA.



  • @doktornotor:

    @jhuntitg:

    I don't want to remove the default logging because I want to log what's being blocked.

    That's being done by default… Kinda the opposite of the goal in the OP.

    Ok, let's phrase it another way; I want to log all blocked packets except broadcast and multicast.

    @doktornotor:

    @jhuntitg:

    Why doesn't the rule I created catch this particular multicast packet?  It caught all the other ones that were coming through …

    No idea. You could instead focus on why isn't that host getting a proper IP and falls back to APIPA.

    The question is why this rule worked for the majority of the multicast and broadcast packets, except the one I posted about.  I really don't care why that host isn't getting a proper IP address and shouldn't have anything to do with this rule not capturing the packet.



  • if you ssh to your pfSense box, get to the command line and enter:
    pfctl -sr

    you'll get the list of rules in the order of evaluation.  Your rule on LAN is after the userrules anchor.  There are other rules above that anchor.  That traffic is likely being caught and logged by a rule that is above the anchor.  That goes back to what dok pointed out, so I'm guessing he understood just fine.



  • Yes, I see the "Block IPv4 link-local" rules at the beginning.

    So I guess if I really want to log all blocked packets except broadcast and multicast, then I need to remove the "log packets match from the default block rules" and create my own "block all" rule at the end of the ruleset with logging



  • @jhuntitg:

    So I guess if I really want to log all blocked packets except broadcast and multicast, then I need to remove the "log packets match from the default block rules" and create my own "block all" rule at the end of the ruleset with logging

    This ended up working as desired



  • Yes, that's exactly what I'd expect.  Sometimes the help here can seem cryptic, but if you keep in mind that the web gui is layered on top of the pf portion of FreeBSD, then all the documentation available for pf can help you understand what's going on.  when in doubt, pfctl, packet captures and a picture with blocks, arrows, and addresses can help make sense of things.


Log in to reply