Stop the Linux bridge from leaking traffic to your physical interface

Technical Briefing | 10/8/2026

You probably set up a bridge for your containers or VMs because it was the simplest way to get them talking to the world. It works, and for a long time, you forget it exists. But then you realize that packets destined for your bridge-local services are somehow showing up on your physical NIC’s tcpdump captures or, worse, getting blocked by the physical firewall rules you applied to the WAN interface. This bit me in prod when a simple container migration caused a routing loop that brought down the entire VLAN.

The kernel is making decisions behind your back

Most sysadmins assume bridge traffic stays in the layer 2 domain of the bridge device. In reality, the netfilter hooks for bridges exist independently of the global iptables hooks. When you have br_netfilter loaded, the kernel starts pushing bridge traffic through the standard iptables chains. If you aren’t explicitly telling the kernel to ignore bridge traffic in your forward chain, you are running a high risk of hairpining traffic through interfaces you never intended to touch.

sysctl -w net.bridge.bridge-nf-call-iptables=0

• Disable br_netfilter if you do not strictly require ebtables-style filtering on the bridge.
• Check your current bridge status using bridge link show to verify traffic isn’t bypassing your intended path.
• Use nftables ‘bridge’ family tables if you must filter at layer 2 instead of trying to hack it into the ip filter table.

If you really need the bridge to be visible to the firewall, be explicit about your interface matching. Never rely on default policies when dealing with bridges because the kernel will happily route traffic across interfaces you thought were isolated. Keeping your bridge configuration distinct from your physical egress rules is the only way to sleep soundly when the traffic spikes.