How does iptable work with linux bridge?
Linux’ bridge filter framework has available mechanisms where the layer 2 bridge code can do an upcall to iptables (as well as arptables or ip6tables ) and have filtering travel from layer 2 (bridged frames) through layer 3 ( iptables with packets) and then back to layer 2. This is much beyond the use the BROUTING chain which only gives the logical choice of staying at layer 2 or continuing at layer 3 (by doing a frame dnat / broute to local).
This layering violation allows for example to leverage the conntrack facility and have stateful firewalling available at layer 2.
It also caused troubles when people didn’t expect this to happen and got issues hard to debug, or hindered performances when it was (most of the time) not needed. So starting with kernel 3.18, the br_netfilter code was split from the bridge code and modularized and is not automatically loaded anymore.
To use this feature now with iptables, one has to modprobe br_netfilter and keep the sysconf parameter net.bridge.bridge-nf-call-iptables set to 1 (equivalent to echo 1 > /proc/sys/net/bridge/bridge-nf-call-iptables ). This will now allow all the wonderful complexity of OP’s link: ebtables/iptables interaction on a Linux-based bridge. Note that this module can also be automatically loaded when iptables uses the physdev ) match and this can subtly alter the whole firewall behaviour if not careful when using both ebtables and iptables .
Note: nftables (as well as iptables-nft ) is also affected. The current status is considered a bit messy (because of layering violations’ additional complexity) and some reorganization was done to have direct conntrack support in the bridge path without using br_netfilter anymore: since kernel 5.3 Linux provides the kernel module nf_conntrack_bridge allowing nftables to handle connection tracking directly in the bridge layer without reaching the ip (nor ip6 and inet) families: connection tracking support for bridge.
How does iptable work with linux bridge?
Setup: VM1 — Bridge — VM2 VM1 and 2 are on same subnet. Bridge has 2 interfaces added to brctl bridge. When I block VM2 ip using uptables -A FORWARD -s (VM1 ip) -j DENY it doesn’t work. I understand the packet never goes to network layer but this says «all iptables chains will be traversed while the IP packet is in the bridge code». Even MAC filtering doesn’t work on iptables. ebtables work fine. What is wrong?
As the linked ebtables documentation says (possibly on a different page), you need an ebtables DROP target in BROUTING table to make the packets go through iptables .
ebtables.netfilter.org/documentation/bridge-nf.html look at the blinking notice. Without this (and the knob described later) iptables works only when routing, not when switching
@A.B Yes. That’s exactly what I was looking for and filtering seems to work now. Could you add this as an answer for me to accept. It’s better if you answer it.
1 Answer 1
Linux’ bridge filter framework has available mechanisms where the layer 2 bridge code can do an upcall to iptables (as well as arptables or ip6tables ) and have filtering travel from layer 2 (bridged frames) through layer 3 ( iptables with packets) and then back to layer 2. This is much beyond the use the BROUTING chain which only gives the logical choice of staying at layer 2 or continuing at layer 3 (by doing a frame dnat / broute to local).
This layering violation allows for example to leverage the conntrack facility and have stateful firewalling available at layer 2.
It also caused troubles when people didn’t expect this to happen and got issues hard to debug, or hindered performances when it was (most of the time) not needed. So starting with kernel 3.18, the br_netfilter code was split from the bridge code and modularized and is not automatically loaded anymore.
To use this feature now with iptables, one has to modprobe br_netfilter and keep the sysconf parameter net.bridge.bridge-nf-call-iptables set to 1 (equivalent to echo 1 > /proc/sys/net/bridge/bridge-nf-call-iptables ). This will now allow all the wonderful complexity of OP’s link: ebtables/iptables interaction on a Linux-based bridge. Note that this module can also be automatically loaded when iptables uses the physdev ) match and this can subtly alter the whole firewall behaviour if not careful when using both ebtables and iptables .
Note: nftables (as well as iptables-nft ) is also affected. The current status is considered a bit messy (because of layering violations’ additional complexity) and some reorganization was done to have direct conntrack support in the bridge path without using br_netfilter anymore: since kernel 5.3 Linux provides the kernel module nf_conntrack_bridge allowing nftables to handle connection tracking directly in the bridge layer without reaching the ip (nor ip6 and inet) families: connection tracking support for bridge.