Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Can't stop VRRP from cluster on subnet from being logged to syslog

    Scheduled Pinned Locked Moved General pfSense Questions
    6 Posts 2 Posters 1.4k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • L
      linux203
      last edited by

      I have a single pfSense 2.3.2-RELEASE-p1 system.  pfSync is not configured as there is no other pfSense system.  All packets matching the default rule are logged to syslog (a SIEM), along with most of the rules.

      I have three clusters on other systems using keepalived.  These systems send multicast packets to 224.0.0.18.  These packets are logged to syslog, but I'm trying to not have them logged at all.

      If I look in the firewall logs in the GUI, I don't see the packets.

      If I add a rule to match CARP packets on the interface and block without logging, the rule never matches and logs are sent to syslog as "pass".  As a troubleshooting step, I changed it to an allow rule, without logging.  Still, the packets are not visible in the GUI but are logged to syslog.

      After a little research, I found two system tunables: net.inet.carp.log and net.inet.carp.allow.  Independently and concurrently, I've set these to 0.  Again, packets aren't visible in the GUI but are logged to syslog.

      Here's a log sample: (sip is redacted but NOT an IP on any pfSense interface)

      filterlog: 53,16777216,,1000000202,em0_vlan300,match,pass,in,4,0xc0,,255,23160,0,none,112,carp,40,<sip_redacted>,224.0.0.18,advertise,255,51,2,103,1</sip_redacted>
      

      I considered opening a bug, but thought I'd ask the community first.  Has anyone else encountered difficulties suppressing CARP packet logging?

      1 Reply Last reply Reply Quote 0
      • jimpJ
        jimp Rebel Alliance Developer Netgate
        last edited by

        Did you set the system to log default pass? That wouldn't normally be logged as a pass.

        The log shows it matched a rule with tracker id 1000000202. Look in /tmp/rules.debug and find the rule with id 1000000202. I suspect it's the rule that passes all carp traffic but it doesn't log by default.

        Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

        Need help fast? Netgate Global Support!

        Do not Chat/PM for help!

        1 Reply Last reply Reply Quote 0
        • L
          linux203
          last edited by

          Thank you for the reply.  I've been scratching my head, this definitely sheds light on the issue.

          Yes, the system will log matches to the default rule.

          2.3.2-RELEASE][root@<redacted>]/root: grep 1000000202 /tmp/rules.debug
          pass log quick proto carp tracker 1000000202 no state
          [2.3.2-RELEASE][root@<redacted>]/root:</redacted></redacted>
          

          The previous carp rule exists above my user created rule, which would be why my rule isn't working.

          block  in  quick  on $DMZ inet proto carp  from any to 224.0.0.0/8 tracker 1487559662  label "USER_RULE: Silenty drop CARP packets on DMZ interfaces"
          

          Is it possible to control the log output of the system created carp rule?

          1 Reply Last reply Reply Quote 0
          • jimpJ
            jimp Rebel Alliance Developer Netgate
            last edited by

            Yes, disable logging of the default pass rule and it won't log.

            You could add your own logging pass quick outbound rules on the floating tab if you have to log default pass traffic.

            Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

            Need help fast? Netgate Global Support!

            Do not Chat/PM for help!

            1 Reply Last reply Reply Quote 0
            • L
              linux203
              last edited by

              I added a quick pass floating rule and the carp packets are still logged to syslog.  Interestingly, the default rule is in the snort section of /tmp/rules.debug.  I looked through the snort config and nothing stood out.  The floating rule is still in the rules.debug after the system rule.

              I guess my next step will be to add a user defined default rule to log packets and turn off the logging of the system default rule.

              [2.3.2-RELEASE][root@<redacted>]/tmp: grep carp rules.debug
              no nat proto carp
              no rdr proto carp
              block in log quick proto carp from (self) to any tracker 1000000201
              pass log quick proto carp tracker 1000000202 no state
              pass  quick inet proto carp  from any to 224.0.0.0/8 tracker 1487608941 keep state  label "USER_RULE: pass, nolog carp from 224.0.0.0"
              [2.3.2-RELEASE][root@<redacted>]/tmp:</redacted></redacted> 
              
              1 Reply Last reply Reply Quote 0
              • L
                linux203
                last edited by

                Well, adding user defined default rules to each interface and removing the option for default rule logging has stopped the CARP packets from logging to syslog.

                [2.3.2-RELEASE][root@<redacted>]/tmp: grep carp rules.debug
                no nat proto carp
                no rdr proto carp
                block in  quick proto carp from (self) to any tracker 1000000201
                pass  quick proto carp tracker 1000000202 no state
                pass  quick inet proto carp  from any to 224.0.0.0/8 tracker 1487608941 keep state  label "USER_RULE: pass, nolog carp from 224.0.0.0"
                [2.3.2-RELEASE][root@<redacted>]/tmp:</redacted></redacted> 
                
                1 Reply Last reply Reply Quote 0
                • First post
                  Last post
                Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.