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

    Allowed traffic showing as blocked by non-active Firewall in 2 firewall config

    Scheduled Pinned Locked Moved HA/CARP/VIPs
    2 Posts 1 Posters 1.8k 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.
    • S
      saxd40
      last edited by

      I have 2 pfSense 1.2.3-RELEASE firewalls set up with CARP.  Config:

      LAN 172.20.0.0/16
      DMZ 172.19.0.0/16

      the LAN has full access to initiate connections to the DMZ and everything appears to work fine.  I compared the firewall rules on the primary and secondary pfSense boxes and they are identical.

      I have "Log packets blocked by the default rule" turned on on both pfsense boxes.

      Everything looks fine in the firewall log on the primary pfSense box, but the odd thing I see is that the non-active pfSense box firewall log is showing traffic from the LAN to the DMZ as being blocked by:

      Source: 172.20.x.y (LAN)
      Destination: 172.19.a.b (DMZ)

      @220 block drop in log quick all label "Default deny rule"

      Is this some hidden rule that keeps the non-active pfSense box from duplicating the traffic onto the DMZ?  Seems like if that was the case there would be a similar rule and weird entries for the WAN interface (which I'm not seeing).

      Thanks,
      Sam

      1 Reply Last reply Reply Quote 0
      • S
        saxd40
        last edited by

        Ah, I think I have a better understanding of what is really happening here.

        The only IP addresses that are showing up are ones that are for a Microsoft Load Balanced IP with two members.  I guessing what is getting blocked are the packets that are viewed as out of order by the non-active based on the fact that the primary firewall has already gotten past the part of the connection setup that a given packet type would be expected.

        So sorry for the false-alarm.  I just noticed when I went back through the logs that it was only happening on the LB IPs.

        The more I'm exposed to this implementation of load balancing the less I like it–unfortunately, we are committed to this at least for the near future.

        1 Reply Last reply Reply Quote 0
        • First post
          Last post
        Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.