A bridging firewall (sometimes called a transparent firewall) is a security appliance that does NOT actively participate in the routing of packets that are allowed by the policies in place to pass through the device. Typically firewalls are actively participating in the routing configuration for the networks that they protect.
Firewalls that protect a single lan are usually the default gateway for servers and workstations on that LAN. Enterprise or service provider firewalls that protect multiple subnets/customers are usually placed close to the upstream egress routers and are fed outgoing traffic by routers that aggregate all the internal traffic. Inserting a routing firewall into a network will always require routing changes; routing firewalls require a unique subnet on each interface that processes IP packets. A bridging firewall does not require any IP routing changes or subnetting to be inserted into place. It processes incoming frames on one interfaces; performs the policy checks,and then passes the frames on the output interface with layer2 (MAC) src and dst addresses unaltered. This means that a bridging firewall could be added to a network to implement controls on internal traffic when the egress router is for example under control of a 3rd party that does not or cannot provide controls. A bridging firewall can still examine the information in the data flow at any layer and make decisions based on IP src/dest, port, application type, or other more complicated rules but the key is that the traffic that passes the policy is send out as if it passed through a switch on the LAN, NOT a router or routing firewall.
Often times a customer will sign a contract for a "managed network offering" with a vendor that provides a core service to to the customer; the network is in essence bundled with the service. This is typical for community banks that sign on with a core processing vendor for their banking applications, auto dealerships that sign on with the manufacturing company, etc. The vendor assigns the IP subnet, all ip addressing of network gear, controls the router and the internet or WAN connection, etc. The customer usually has some amount of control over the servers and applications, but typically has very little or no access at all to any network gear. In addition, the kinds of controls that the vendors are willing to implement that are custom to that customer's needs are usually very limited or very expensive and difficult to accomplish. Basically the vendors manage their customers as cookie-cuttter sites and no variation from the norm is allowed or certainly encouraged. Because a bridging firewall can be slipped into place without changing any layer 3 (ip) routing, gateways, or subnet masks it is an excellent way to build in security for a network managed by a vendor unwilling or unable to make and manage the changes. Another excellent use of a bridging firewall is to provide security on a legacy LAN that was not properly carved up (VLANned and subnetted) originally. I see this a lot at small ISPs, small private datacenters, small corporate datacenters and multi-tenant buildings with shared internet access. In each case, customers or applications with competing security requirements are mixed onto the same layer2 LAN (i.e. same ip subnet) and moving the applications to different vlans for whatever reason is not easy to get approved, too expensive, or too risky. In some cases the servers or firewalls that need to be split up happen to fall on different base 2 boundaries. For example the first customer has its firewall on a.b.c.12 and the 2nd customer or business unit has an AS400 on a.b.c.150. By subnetting the a.b.c.x network into 2 /25s (a.b.c.d.1-127 on net A and a.b.c.128-254 in net B) it would be possible to put a routing firewall in the middle of the 2 devices, change just the gateway and mask on one side and just the mask on the other and have the firewall manage traffic and restrict access as needed. But in almost all real-world situations its not this easy to insert a layer3 device. A bridging firewall could be placed into the mix with each customer or business unit moved to a different bridge interface as needed, with security policies added as needed all with zero changes to any server or firewall needed. Performance: OpenBSD pf and bridging code will be able to handle 100Mbit full duplex bridging on basic hardware with releases 4.5 and up.