Building a Transparent Bridge Filter with OPNsense

[rgnldo]

This how-to aims to guide you through the easy configuration of a Transparent Filtering Bridge on the OPNsense firewall, as explained below.


1. Hardware Initial Setup

Ensure you have at least 3 network interfaces:

LAN (internal network)
WAN (internet connection)
Additional interface for bridge

2. Bridge Configuration

Access Interfaces → Other Types → Bridge
Click "+" to add a new bridge
Configure the following parameters:

Code: [Select]

Description: Bridge_LAN_WAN
Member interfaces: [Select your interfaces]
Enable: checked
Advanced options: Keep default settingsClick "Save"

3. Interface Configuration

Go to Interfaces → Assignments
Add the newly created bridge
Configure member interfaces:

Code: [Select]

IPv4/IPv6 Configuration Type: none
IP address: leave empty
MTU: default
Device Configuration:
- Promiscuous mode: checked
4. Firewall Configuration

Access Firewall → Rules
Configure bridge rules:

Code: [Select]

Action: pass/block
Interface: [your_bridge]
Direction: in/out
Protocol: any/specific
Source/Destination: as needed
5. Enable Filtering

Go to System → Settings → Tunables
Add or verify these parameters:

Code: [Select]

net.link.bridge.pfil_member=1
net.link.bridge.pfil_bridge=0
6. System Commands for Verification:

Code: [Select]

# Check bridge status
ifconfig bridge0

# Verify interface status
ifconfig em0
ifconfig em1

# Check system logs
tail -f /var/log/system.log

# Monitor bridge traffic
tcpdump -i bridge0
7. Network Testing Commands:

Code: [Select]

# Test connectivity
ping 1.1.1.1

# Check routing table
netstat -rn

# View bridge status
pfctl -s state

# Monitor interface traffic
tcpdump -ni em0

Important Tips

- Back up the configuration before starting

- Maintain physical access to the equipment during configuration

- Document all changes made

- Test in a controlled environment before deploying to production

Common Troubleshooting

Check Connectivity:

Code: [Select]

# Check interface status
ifconfig

# View system messages
dmesg | tail

# Check firewall logs
tail -f /var/log/filter.log
Check Bridge:

Code: [Select]

# Bridge status
ifconfig bridge0

# Bridge statistics
pfctl -s info
Monitoring:

Code: [Select]

# Real-time traffic monitoring
tcpdump -ni bridge0

# System status
top

[Monviech]

This kinda looks like AI generated content at first glance, especially the Key Benefits section.

[Patrick M. Hausen]

This kinda looks like AI generated content at first glance, especially the Key Benefits section.

And I cannot see any added benefit compared to the official guide:

https://docs.opnsense.org/manual/how-tos/transparent_bridge.html

[Monviech]

I have no issue with it. If it was a genuine effort, thank you.

If one of your steps here are different or improve the original documentation, please feel free to improve that guide on github.

As reference, some people have issued with the original guide, so if you can improve it: https://github.com/opnsense/docs/issues/614

[rgnldo]

This kinda looks like AI generated content at first glance, especially the Key Benefits section.

My language is Portuguese, and I'm not fluent in written English. I used some correction and suggestion tools for the introduction of the how-to and chose to publish it in English.

[rgnldo]

This kinda looks like AI generated content at first glance, especially the Key Benefits section.

And I cannot see any added benefit compared to the official guide:

https://docs.opnsense.org/manual/how-tos/transparent_bridge.html

I hope this helps in some way.

[EricPerl]

Coming from someone who started on OPNsense with a transparent filtering bridge a few weeks back:

Neither of the guides makes recommendations with regards to physical implementation on the existing network, specifically in relationship with an existing router.

The OPN guide disables bogons/privates on the WAN side, merely implying the bridge is within a private network.

This guide says nothing about bogons/privates BTW.

In https://github.com/opnsense/docs/issues/614, the author has it between modem and router, which could actually explain why he has issues accessing the bridge (presumably from the LAN side of the router) depending on the IP used on the management interface. Step 4 in the OPN guide is light on details for noobs.
With a 3rd physical interface used for management, it's my understanding that the bridge could be accessed more naturally from the LAN side.

Another guide I found when I started mentioned that a big drawback of using the bridge on the WAN side of the router meant it would only be exposed to NAT traffic from the main LAN, making correlation to LAN traffic painful at best. That made sense to me.

[rgnldo]

Coming from someone who started on OPNsense with a transparent filtering bridge a few weeks back:

Neither of the guides makes recommendations with regards to physical implementation on the existing network, specifically in relationship with an existing router.

The OPN guide disables bogons/privates on the WAN side, merely implying the bridge is within a private network.

This guide says nothing about bogons/privates BTW.

In https://github.com/opnsense/docs/issues/614, the author has it between modem and router, which could actually explain why he has issues accessing the bridge (presumably from the LAN side of the router) depending on the IP used on the management interface. Step 4 in the OPN guide is light on details for noobs.
With a 3rd physical interface used for management, it's my understanding that the bridge could be accessed more naturally from the LAN side.

Another guide I found when I started mentioned that a big drawback of using the bridge on the WAN side of the router meant it would only be exposed to NAT traffic from the main LAN, making correlation to LAN traffic painful at best. That made sense to me.

The suggestion of a dedicated third physical interface for management appears to be a logical solution, as it would allow more direct access from the LAN side without NAT restrictions.

Another important point you raised is about exposing the bridge to NAT traffic when placed on the WAN side of the router—a configuration that can complicate detailed LAN traffic analysis and monitoring. This reinforces the need for an implementation where LAN traffic can be easily correlated, perhaps making it more practical to place the bridge on the internal network side.

This could provide good feedback. If there’s a practical effect, we can improve this how-to further.

[Monviech]

It looks like the Zenarmor guide for this goes with 3 interfaces by default.

https://www.zenarmor.com/docs/network-security-tutorials/how-to-configure-transparent-filtering-bridge-on-opnsense