Okay, I know this is a bit outside my usual CRM-hopping wheelhouse, but I've been deep in a side project involving a legacy on-premise app server that absolutely cannot be touched. Sound familiar? 😅
The problem: This old beast handles some critical internal data but has zero modern security. It's on an isolated VLAN, but we needed to insert inspection and access controls without changing a single IP on the server or the clients. The answer? A transparent bridge firewall.
I went with pfSense for this (though OPNsense or a Linux box with `iptables`/`nftables` would work too). Here’s the basic blueprint:
* **Hardware:** Used a Protectli box with four NICs. Two NICs for the bridge (WAN-side facing the core switch, LAN-side facing the legacy server switch), one for management, one spare.
* **Configuration:** In pfSense, you create a **Bridge Interface** grouping the two physical ports. The key is that the bridge itself gets the management IP, while the member interfaces have *no IP* assigned. The firewall rules are then applied directly to the bridge.
* **Rule Design:** Since it's Layer 2, you're filtering based on MAC addresses as well as IPs. My ruleset focused on:
* Allowing only specific source IPs (modern app servers) to talk to the legacy server on its handful of ports.
* Blocking the legacy server from initiating *any* outbound connections except for a single NTP server.
* Logging all denied packets for auditing.
The cool part? The app server and the clients never knew anything changed. No gateway updates, no ARP spoofing. Failover planning was tricky—I set up a cold spare with an identical config because a true HA transparent bridge gets messy with MAC learning.
Anyone else tried this? I'm especially curious about real-world throughput on these setups. The datasheet said 1Gbps, but with all rules enabled and logging on, I saw about 650Mbps, which was fine for this app. Would love to hear comparisons with Fortinet's transparent mode or a PAN VM Series in virtual wire.
Still looking for the perfect one
The bridge configuration in pfSense is a solid approach for Layer 2 insertion. A critical nuance people often miss is the interaction between bridge rules and stateful filtering when dealing with non-IP traffic. If your legacy app uses any raw Ethernet protocols or IPv6 link-local discovery, the default state table behavior can silently drop frames.
You mentioned rule design based on MAC and IP. For a truly transparent setup, consider creating an alias for the server's MAC address and binding your rules to that. This prevents any accidental leakage if the server's IP ever changes via DHCP or manual misconfiguration. Also, verify the bridge's "block non-IP" and "block bogon" options are disabled, as they can cause mysterious failures with older industrial protocols.
What's your plan for monitoring throughput and latency on the bridge? The lack of an IP on member interfaces means you can't use typical SNMP polling on them. You'll need to rely on the bridge interface stats or use a mirrored span port for packet analysis.
—BJ