The tunnable for traffic to be filtered at the member interface makes all the sense to me.
I put WAN side rules on the OPT1 interface, and a OPT1_net to any rule on the OPT1 interface. OPT1 and OPT2 are bridged so the DHCP server configured at OPT1 will send broadcasts to all members.

So I did that. Configured the /28 on the OPT1 interface, enabled and configured the DHCP server. I also removed the net.link.bridge.pfil_bridge: 1 back to 0.

On the firewall added a rule with OPT1 net to any on the OPT2 interface.

After configuring OPT1 and DHCP Server, I created a new bridge with OPT1 and OPT2, assigned to a new interface and enabled.

After that and inspecting the traffic I saw two things:

1. a rule was needed at OPT2 to allow DHCP traffic;
2. the bridge interface was actively blocking traffic even tho the tunnable is set to zero.

Just to make sure, I enabled the DHCP rule on OPT2 first, and waited to see if it would still be blocked on the bridge, and it was. So seems like the option for the bridge doesn't work very well or didn't here. But anyway, after allowing any to any on the bridge, everything is working.

So the final config is:

opt1 (external)---¡ -> Static IP & DHCP Server enabled
                  |
                  | bridge0 -> firewall allow any to any
                  |
opt2 (internal)---! -> Allow DHCP traffic and OPT1_net to any

or more granular if preferred. Other rules go on the OPT1 interface like normal

In the end I don't know why I overcomplicated cause the final config seemed fairly simple, not sure what was missed before.

Actual config is

opt1 (external)---¡
                  |
                  | bridge0
                  |
opt2 (internal)---!

opt1 and opt2 have ip config to none.
bridge0 has ip config and dhcp server enabled

I changed pfil_bridge to 1 while keeping pfil_member 1

net.link.bridge.pfil_member: 1
net.link.bridge.pfil_bridge: 1

traffic started flowing, rules for incoming traffic set at the OPT1 interface. adding rules at the OPT1 interface do control access to hosts on OPT2.
Also added an any to any rule on the OPT2 interface.

Well looking at your post does look at least a bit similar. You're also bridging two interfaces an internal and an external and trying to pass traffic through it.

I have to say that in my example

opt1 (external)---¡
                  |
                  | bridge0
                  |
opt2 (internal)---!

putting the config on the internal (opt2) interface didn't sound that bad either.
I would (in my mind) take a opt2 network to any rule on the firewall at the opt2 interface, and rules for incoming traffic put at opt1 ...

My problem is, I did test that already and also failed miserably.

I've been killing my head trying to figure out why this isn't working. In the end feels like should be a simple task. Like let's say your ISP router that allows bridge, you enable the bridge and voila get connectivity directly to the outside when you connect to the bridged port. I've been wondering "should the bridge0 interface be unassigned?" that doesn't feel right to if an interface isn't assigned and enable how could it work?

The truth is, I mean, the strong suit of pfSense is being a firewall ... so how is it so hard and user unfriendly to configure it as a firewall without routing?

So, resuming ...
bridge0 = opt1 + opt2
opt1 is external
opt2 is internal
tests doing Diagnostics > Ping - destination 1.0.0.1

objective: transparent firewall

I tried 3 scenarios:

configured IP on the opt1 interface

could reach target from the opt2interface only.
so with the IP config on the external member, I could reach outside from the inside member. selecting bridge as the source interface also failed.
...

configured IP on the opt2 interface

the same as before except now the IP config was in the internal interface.
can reach test target from opt1 - the external interface no ip config,
not from the bridge interface or the opt2 where the IP config was this time.
...

configured IP on the bridge0 interface

can reach test target from opt1 and opt2 interfaces but not from bridge.
I'm thinking sure, my machines are in opt2 internal and the outside is opt1 so let's go. (never mind this was the first config anyway)

clients on opt2 get ip's from dhcp ... mtu value ... provided by pfsense
ip route show shows the default gateway as the correct gateway for the subnet ...

pinging from client returns:
From 192.0.20.1 icmp_seq=... Destination Host Unreachable
From 192.0.20.1 icmp_seq=... Destination Host Unreachable
From 192.0.20.1 icmp_seq=... Destination Host Unreachable

Testing from client to bridge IP address on the pfsense interface: success

Firewall logs ... nothing. I am unable to find anything useful on the firewall logs. got an email server unreachable bc of this >:( driving me nuts.

edit ... never mind, I think in the meanwhile I lost the ability to ping the firewall from the client. I'm clueless.

So I would set an IP first on the device in the /28 on your lan side of pfsense. Can you ping the /28 gateway this is upstream?

If I find some time after real work, I have a 3100 laying about here, that I have been meaning to upgrade anyway to 22.01, was going to just wait til 22.05 came out. But I could then lab exactly what your doing..

Might take me a bit.. Still got a couple of hours of work, etc. Wife isn't here - so don't have anything else to do ;) other than continue binging the flash hehehe

/28 subnet ISP side <-> OPT1 pfsense bridge0 OPT2 <-> /28 inside

I have OPT1 and OPT2 with IP config set to none, and bridge0 with the IP config & DHCP enabled. Am I looking at this wrong?

EDIT: for the life of me I can't get connectivity with this configuration on the OPT2 vm's ...
I've added firewall rules to all interfaces involved ... bridge and members ... allow traffic any to any ...
I've moved the IP configuration from the bridge to the OPT2 member ... nothing.

As just a transparent firewall there really wouldn't be a reason to.. if you wanted to say put .2 out of the /28 on pfsense so you could route some downstream clients to other pfsense networks - ok. Then your devices on the downstream of the /28 bridge could have a route to use this IP to get to other networks via pfsense. But you you stated the gateway would be upstream on the /28

But if you just want to firewall on the bridge, pfsense doesn't need an IP on the bridge. In transparent mode pfsense really has nothing to do with the traffic, its not natting, its not routing - it just inspects the traffic if allowed or not..

But you would create firewall rules on the "bridge" interface..

/28 network --- opt1 pfsense opt2 -- devices in /28

Where you have bridged opt1 and opt2, you can then filter on this bridge to only allow specific ports, etc.

Ok so ... that's making sense... you mean

I must add a new interface let's say OPT2 ... the public subnet is delivered at OPT1 ... I bridge the OPT2 and OPT1 into bridge0, and connect the OPT2 to the clients. Cause if they're all connected to the switch/L2 of OPT1 it will go directly out ... right. That's it right? Cheers!

My upstream gateway IS one of the IP's on that subnet.

The you would create a bridge sure, this is a transparent firewall. The bridge would have to contain both the interface that pfsense uses to talk upstream to this /28, and the interface on pfsense where your downstream devices connected that are also in this /28

Ok, so, my goal is to "route" the subnet? Doesn't feel like it:

1. Already have a WAN connection on its own interface;
2. the IP subnet is delivered on an independent interface and is not routed through the WAN IP;

I had already read that article you provided, but it seems to me that article assumes the second subnet (192.0.2.128/29 in the provided example) is routed through WAN. But that is not the case here.

I have a cable from a switch and the /28 is delivered through that connection. My upstream gateway IS one of the IP's on that subnet.

https://docs.netgate.com/pfsense/en/latest/recipes/route-public-ip-addresses.html#routing-public-ip-addresses

To "bridge" you would need at least 2 interfaces.. And the networks would have to be the same on both sides of the bridge.

I found this at the docs:

Internal/External Bridges

An Internal/External type bridge, also known as a “transparent firewall”, is used to insert a firewall
between two segments without altering the other devices. 
 => Most commonly this is used to bridge a WAN to an internal network
so that the WAN subnet may be used “inside” the firewall <=,
or internally between local segments as an in-line filter. Another common use is for devices behind the firewall 
to obtain IP addresses via DHCP from an upstream server on the WAN.

In a transparent firewall configuration the firewall does not receive the traffic directly or act as a 
gateway, it merely inspects the traffic as it passes through the firewall.

Note - Devices on the internal side of this bridge must continue to use the upstream gateway as their 
own gateway. Do not set any IP address on the firewall as a gateway for devices on a 
transparent bridge.

NAT is not possible with this style of bridge because NAT requires the traffic to be addressed to the 
firewall’s MAC address directly in order to take effect. Since the firewall is not the gateway, this 
does not happen. As such, rules to capture traffic such as those used by a transparent proxy
do not function.

From: https://docs.netgate.com/pfsense/en/latest/bridges/index.html

Hence adding the bridge.

I tried to highlight this part: "Most commonly this is used to bridge a WAN to an internal network so that the WAN subnet may be used “inside” the firewall"

Which is what I was looking to achieve, and putting the DHCP directly on OPT1 did not filter any traffic.

Saying this because before I had the same config on the interface directly, without any bridge, and pfSense was not firewalling anything.

So, let me try this again in a simpler manner....

I have a dedicated interface with a /28 subnet.
I want clients to get an IP from that /28 and have traffic being filtered by pfSense.

What's the approach? Thank you.

so I created a bridge (bridge0) with the interface where the /28 is as member.

Huh? Why would you think you need a bridge with 1 interface?