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

ryan87

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?

bkraptor

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

kpa

@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.

gremblin

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