bridge-nf

Linux kernel 2.6 supports filtering on a bridge
All bridged packets pass through the FORWORD chain

1. Intro

   What is bridge-nf?

   It is the infrastructure that enables {ip,ip6,arp}tables to see bridged IPv4, resp. IPv6, resp. ARP packets. Thanks to bridge-nf, you can use these tools to filter bridged packets, letting you make a transparant firewall. Note that bridge-nf is also referred to as bridge-netfilter and br-nf, the term bridge-nf should be preferred.

   Why do I need bridge-nf?

   Ebtables only allows basic filtering of the IPv4 and ARP packets, for more advanced filtering you need to use the {ip,ip6,arp}tables applications. Iptables in combination with bridge-nf also allows you to do things like transparant IP NAT.

   ---

2. Connection tracking

   What happens when I enable connection tracking (for IPv4 traffic)?

   By default, when IPv4 connection tracking is loaded in the kernel (if your kernel is modular, it is the  nf_conntrack module), all IP packets will be seen by the connection tracking code. This code is called on the  PF_INET/PRE_ROUTING and  PF_INET/LOCAL_OUT hooks. For bridged packets, only the  PRE_ROUTINGconnection tracking is important.

   What are the disadvantages of connection tracking on a bridging firewall?

   1. For an IP packet entering a bridge device, connection tracking is called before the bridge code decides what to do with the packet. This means that IP packets that will be discarded by the bridge code are tracked by connection tracking. For a router, the same is true, but a bridge also sees the traffic between hosts on the same side of a network. It's possible to prevent these packets from being seen by connection tracking: you can either drop them in the ebtables nat PREROUTING chain or use the iptables NOTRACK target.
   2. Fragmented IP packets (typically UDP traffic like NFS) are defragmented by the connection tracking code and refragmented before sending them out. This slows down traffic, but the transparancy of the firewall isn't diminished.

   [Back to the top]

   ---

3. General

   What happens with IP DNAT on a to be bridged packet?

   If IP DNAT happened then the bridge-nf code asks the routing table where the packet should be sent. If it has to be sent over another device (not the bridge device) then the packet is routed (an implicit redirect). If the routing table sends the packet to the bridge device, then the packet is bridged but the MAC destination is correctly changed. To do IP DNAT, you therefore need a correct routing table.

   How can I disable bridge-nf?

   If you don't want iptables and arptables to see bridged traffic, you can disable bridge-nf in the 2.6 kernel at compile time by disabling "Bridged IP/ARP packets filtering".

   Can I disable/enable bridge-nf specifics on-the-fly?

   As of kernel version 2.6.1, there are three sysctl entries for bridge-nf behavioral control (they can be found under  /proc/sys/net/bridge/):

   • bridge-nf-call-arptables - pass (1) or don't pass (0) bridged ARP traffic to arptables' FORWARD chain.
   • bridge-nf-call-iptables - pass (1) or don't pass (0) bridged IPv4 traffic to iptables' chains.
   • bridge-nf-call-ip6tables - pass (1) or don't pass (0) bridged IPv6 traffic to ip6tables' chains.
   • bridge-nf-filter-vlan-tagged - pass (1) or don't pass (0) bridged vlan-tagged ARP/IP traffic to arptables/iptables.

   Do {ip,ip6,arp}tables see VLAN tagged IPv4/IPv6/ARP traffic on an untagged bridge?

   Yes. Kernel versions 2.6.0-test7 and above have this functionality. For disabling this, see the above question.

   How do I let vlan-tagged traffic go through a vlan bridge port and the other traffic through a non-vlan bridge port?

   Suppose eth0 and eth0.15 are ports of br0. Without countermeasures all traffic, including traffic vlan-tagged with tag 15, entering the physical device eth0 will go through the bridge port eth0. To make the 15-tagged traffic go through the eth0.15 bridge port, use the following ebtables rule:

   ebtables -t broute -A BROUTING -i eth0 --vlan-id 15 -j DROP
   

   With the above rule, 15-tagged traffic will enter the bridge on the physical device eth0, will then be brouted and enter the bridge port eth0.15, the vlan header will be stripped, after which the packet is bridged. The packet thus enters the BROUTING chain twice, the first time with input device eth0 and the second time with input device eth0.15. The other chains are only traversed once. All other traffic will be bridged with input device eth0.

   Do {ip,ip6,arp}tables see encapsulated 802.2/802.3 IP/ARP traffic?

   No. Adding this shouldn't be that hard, though.