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

    Understanding Firewall Between LAN and OPT1

    Scheduled Pinned Locked Moved Firewalling
    4 Posts 2 Posters 2.7k 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.
    • M
      msalvatore
      last edited by

      Hi Everyone,

      I'm very new to PFSense and I'm loving it so far. I don't have much experience with firewalls, so this may be standard behavior that I'm just not familiar with. I've also read some conflicting information on the matter so I would appreciate if someone could set the record straight.

      pfSense Version: 2.4.2
      Setup: I have a network on the LAN interface (172.25.50.0/24) and a network on the OPT1 interface (192.168.25.0/24).
      Expectation: Traffic between LAN <-> OPT1 is subject to firewall rules for both interfaces. For example, if LAN allows ping to any destination, but OPT1 blocks pings from all sources, hosts on LAN should not be able to ping hosts on OPT.
      Behavior: Traffic coming into the OPT1 interface from LAN net gets evaluated against LAN's firewall rules, but it does not get evaluated against OPT1s firewall rules. In other words, LAN net hosts can ping OPT1 hosts even though OPT1 blocks all ICMP traffic.

      Question 1: Is what I'm observing the expected behavior?
      Question 2: I found this post (https://forum.pfsense.org/index.php?topic=39826.0) where the author states "I just read that normally all traffic from opt1 to lan is blocked." Is all traffic between OPT1 < -> LAN normally blocked?
      Question 3: It's simple enough to put a rule on LAN that blocks all traffic destined for OPT1 net (and vise versa), but maybe someone can explain to me the reason why traffic from LAN to OPT1 doesn't obey the firewall rules on OPT1.
      Question 4: Is there just a checkbox somewhere that I missed that enables/disables this behavior?

      Thanks in advance!
      Mike

      1 Reply Last reply Reply Quote 0
      • DerelictD
        Derelict LAYER 8 Netgate
        last edited by

        pfSense interface rules process traffic inbound on that interface. That is the expected behavior. Once the traffic is allowed in, it is allowed out the destination interface.

        If you wish to have rules that act on traffic going out an interface, you need to use a floating rule.

        https://doc.pfsense.org/index.php/Firewall_Rule_Basics

        https://doc.pfsense.org/index.php/Firewall_Rule_Troubleshooting

        https://doc.pfsense.org/index.php/Firewall_Rule_Processing_Order

        Chattanooga, Tennessee, USA
        A comprehensive network diagram is worth 10,000 words and 15 conference calls.
        DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
        Do Not Chat For Help! NO_WAN_EGRESS(TM)

        1 Reply Last reply Reply Quote 0
        • M
          msalvatore
          last edited by

          Thanks! I think the gap in my knowledge was that "incoming" means "from outside the router". So once traffic enters the router, it can exit through any interface. I guess I was confused because traffic from LAN -> OPT1 is incoming from the perspective of the OPT1 network, but not from the perspective of the firewall.

          I'll play around a bit with the floating rules when I get a few minutes.

          1 Reply Last reply Reply Quote 0
          • DerelictD
            Derelict LAYER 8 Netgate
            last edited by

            Why? Most people do not need floating rules.

            If you don't want traffic to go from LAN to OPT1, block it on LAN dest OPT1 network.

            Chattanooga, Tennessee, USA
            A comprehensive network diagram is worth 10,000 words and 15 conference calls.
            DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
            Do Not Chat For Help! NO_WAN_EGRESS(TM)

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