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 Expand

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

3. Interface Configuration

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

Code Select Expand

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 Expand

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 Expand

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

6. System Commands for Verification:

Code Select Expand

# 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 Expand

# 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 Expand

# Check interface status
ifconfig

# View system messages
dmesg | tail

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

Check Bridge:

Code Select Expand

# Bridge status
ifconfig bridge0

# Bridge statistics
pfctl -s info

Monitoring:

Code Select Expand

# Real-time traffic monitoring
tcpdump -ni bridge0

# System status
top

[Monviech (Cedrik)]

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 (Cedrik)]

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 (Cedrik)]

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

[abbrasamria1979]

Building a transparent bridge filter with OPNsense sounds like a solid project. I've worked with it before, and it's pretty straightforward once you get the hang of it. You'll be setting up OPNsense in bridge mode between your network interfaces. This will let you filter traffic without altering the routing. You can use the firewall rules to specify what to block or allow between the interfaces.
One thing I've found super helpful is running an ip stress test to make sure the bridge handles traffic well. It's a good way to gauge the performance and ensure everything's running smoothly without hiccups. I would suggest starting with a small test setup to play around with before going full-scale.

[jacobdrj]

Question: Can I run this OPNsense transparent filtering bridge (OTFB) between my GPON and my router?

Background: I just changed ISPs. The old ISP had an all-in-one PON/router/firewall/wireless AP. The new ISP setup I purchased my own separate GPON. The GPON requires that I have a PPPoE username and password input in my router to work properly.

For the moment, I'm using my own ole' reliable Google Wi-Fi mesh to act as my router/firewall/Wireless AP. However, I will eventually be replacing it with an OPNsense Router/Firewall and a separate wireless AP, like an Omada EAP 773 or Unifi 7 Pro. Until I actually get that AP hardware, I'll be keeping with the Google Wi-Fi mesh.

I already have the miniPC I plan to use as the OPNsense router in the future (an N100 based system with dual 2.5gb Intel NICs from Ali Express). Since I want to experiment with OPNsense while I'm waiting, and especially with this low-risk OTFB concept. This is also helpful because, like abbrasamria1979 mentioned, it can give me a low-risk way to stress test this CPU such that it is sufficiently beefy for my use case with Intrusion Detection and Intrusion Prevention enabled. (I currently have a 1000mbps up/250mbps down fiber connection)

To me, it makes more sense to put the OTFB between the GPON and router. But at that point, I suspect that means I'd need to turn it into a router anyways, maybe?

Do I need to run the OTFB attached to one of the LAN ports on one of the Google Wi-Fi mesh pucks OR can I put the OTFB in between the GPON and the router?

[Patrick M. Hausen]

You can but it won't do much. It cannot look inside the PPPoE data stream between your router amd the ONT. It's better to place it between the router and the internal LAN switch, so it can see actual Ethernet frames.

But OPNsense does support PPPoE so why not replace the router entirely?

[EricPerl]

OPN between GPON with PPPoE and router seems borderline useless.
GPON - OPN - Router is still not a great configuration because OPN will pretty much only see one source ("WAN" side of router) and matching that traffic back to the original source before NAT is cumbersome at best (not sure if Google Mesh HW even has that capability). It's low risk though (reverting back is easy, and clients don't know the difference).
GPON - OPN - AP is a more reasonable setup. An AP is a switch after all. You can lower you risk by configuring the LAN side of OPN the same way as the router is configured. Swapping routers can be a low disruption use case. In your case, because it involves reconfiguring the AP as a router (or the opposite), risk is a bit higher.

[rasculatul]

Hi,

I have a silly question since I do believe I am missing something. I am trying to determine the advantage of using a TFB (Transparent Filtering Bridge) if I have IDS, IPS and CrowdSec running on my OPNSense router. I have completed setting up a separate device as a TFB (using OPNSense) which works as expected but knowing that I already have those services enabled on the OPNSense router, I am not seeing the advantage of using the TFB (I was planning to put it between the OPNSense router and the internal network). The CPU on the router is more than capable running those services (i5-7500).

I guess running Zenarmor on the TFB could be one option since Suricata and Zenarmor don't work well together on the same machine.

That said, I do want to use a TFB, if it makes sense.

Any guidance/clarification on the above is extremely appreciated.

Thank you so much!

[EricPerl]

Crowdsec on the router is not going to be controversial.
IDS/IPS is more questionable, especially if you're blocking everything on the WAN side (why bother inspecting traffic that is going to be blocked).
Additionally, encrypted traffic can't be inspected anyway. What's left?

Sensei is facing the same issues. Sensei on a TFB behind OPN with Crowdsec and IDS/IPS looks overkill/redundant.
I've seen articles with proxies terminating SSL for inspection purposes. I have not bothered trying, but it could be better use of your HW IMO.