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

    Help clarify my understanding of the net.link.bridge.pfil* tunables please.

    Scheduled Pinned Locked Moved Firewalling
    4 Posts 4 Posters 7.9k 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.
    • R
      ryan87
      last edited by

      Hi,

      I have a question about bridging interfaces and changing the net.link.bridge.pfil_member and net.link.bridge.pfil_bridge system tunables.  I'm configuring a 3 port + wireless (ALIX) device and I've set it up as follows:

      • WAN on PORT1 (ALIX WAN)

      • LAN A on PORT2 (ALIX LAN)

      • LAN B on BRIDGE0 created from PORT3 (ALIX OPT1) + Wireless (ALIX PCIe Wireless)

      To isolate LAN A from LAN B I set up some simple firewall rules (ex: LAN B):

      | Action | ID | Proto        | Source  | Port | Destination     | Port      | Gateway | Queue | Schedule | Description            |
      |--------|----|--------------|---------|------|-----------------|-----------|---------|-------|----------|------------------------|
      | Pass   |    | IPv4 TCP/UDP | LAN net | *    | LAN address     | 53 (DNS)  | *       | none  |          | Local DNS              |
      | Block  |    | *            | *       | *    | privateNetworks | *         | *       | none  |          | Block RFC1918 Networks |
      | Pass   |    | IPv4         | LAN net | *    | *               | *         | *       | none  |          | Allow All              |
      

      The docs for the mentioned tunables say:

      By default, traffic is filtered on the member interfaces and not on the bridge interface itself. This behavior may be changed by toggling the values of net.link.bridge.pfil_member and net.link.bridge.pfil_bridge under System > Advanced on the System Tunables tab. With them set at 0 and 1, respectively, then filtering would be performed on the bridge only.

      I initially interpreted that to mean traffic between member interfaces would not be filtered.  However, that seems incorrect since traffic between my wireless interface and PORT3 gets blocked.  I assume it's blocked by my rule to block RFC1918 networks.

      Would it be correct to say that I should be thinking of traffic between bridge member interfaces as entering on the bridge interface and leaving on the bridge interface?  Put another way, since the traffic is entering the bridge interface, while flowing from one member interface to the other, it's going to be subject to the firewall rules for the bridge interface.

      If that's correct, I end up with firewall rules that look like this:

      | Action | ID | Proto  | Source  | Port | Destination     | Port      | Gateway | Queue | Schedule | Description            |
      |--------|----|--------|---------|------|-----------------|-----------|---------|-------|----------|------------------------|
      | Pass   |    | *      | LAN net | *    | LAN net         | *         | *       | none  |          | Local Subnet           |
      | Block  |    | *      | *       | *    | privateNetworks | *         | *       | none  |          | Block RFC1918 Networks |
      | Pass   |    | IPv4   | LAN net | *    | *               | *         | *       | none  |          | Allow All              |
      

      The LAN net –> LAN net rule seems a bit weird to me because once I set the  tunables mentioned above, I don't intend to filter traffic between bridge members.  Having to explicitly allow that traffic caught me off guard.  I'm not saying it should work differently, just that it was easy to make an incorrect assumption about how it works.  I'd much rather have traffic unexpectedly blocked than unexpectedly allowed.

      So, assuming I've set the tunables above:

      net.link.bridge.pfil_member=0	
      net.link.bridge.pfil_bridge=1
      

      … I have 2 questions:

      • Is it correct that traffic between members of the bridge interfaces is going to be subject to the firewall rules of the bridge interface?

      • Why isn't DHCP traffic blocked with the firewall rules in my first example?  I know I figured this out once.  If I remember correctly, DHCP requests use 0.0.0.0 and 255.255.255.255 which aren't included in my alias for RFC1918 networks.  Does that sound correct?

      1 Reply Last reply Reply Quote 0
      • B
        bkraptor
        last edited by

        I too had the same expectations when it comes to bridges being transparent. Most docs and forum threads recommend flipping the two tunables below together: either member on/bridge off or member off/bridge on. This makes it sound like if you want to have any sort of control over traffic flows (e.g. with firewall rules) you need either one to be on - this is not true. You can have both tunables off, which results in a transparent L2 bridge, just like a plain old switch. In my case I apply firewall rules to the bridge interface and they work as expected - rules will apply only to traffic transiting the firewall at L3.

        net.link.bridge.pfil_member=0
        net.link.bridge.pfil_bridge=0
        
        G 1 Reply Last reply Reply Quote 2
        • K
          kpa
          last edited by

          @ryanjaeb:

          … I have 2 questions:

          • Is it correct that traffic between members of the bridge interfaces is going to be subject to the firewall rules of the bridge interface?

          • Why isn't DHCP traffic blocked with the firewall rules in my first example?  I know I figured this out once.  If I remember correctly, DHCP requests use 0.0.0.0 and 255.255.255.255 which aren't included in my alias for RFC1918 networks.  Does that sound correct?

          Any traffic traversing a two interface bridge will pass trough three points where the traffic can be filtered, the in-interface, the bridge interface and the out-interface. The bridge interface sits between the two other interfaces so it's only natural that filter rules on it will see all traffic traversing the bridge.

          DHCP is a special case on pfSense, it is allowed with hidden rules that are activated when DHCP is used on an interface.

          1 Reply Last reply Reply Quote 0
          • G
            gremblin @bkraptor
            last edited by

            @bkraptor Super helpful!! Thank you! It makes sense to me now.

            1 Reply Last reply Reply Quote 0
            • MrPeteM MrPete referenced this topic on
            • MrPeteM MrPete referenced this topic on
            • First post
              Last post
            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.