Last modified: April 15, 2003


  1. Intro
  2. Installation
  3. Usage
  4. Problems
  5. Other


  1. Intro
    What is ebtables?
    The ebtables project is the Linux 2.5.x (and above) Link Layer firewalling subsystem, a patch for 2.4.x is maintained too. It delivers for Linux the functionality of Ethernet frame filtering, all kinds of frame NAT (Network Address Translation) and frame matching. The ebtables infrastructure is a part of the standard Linux 2.5.x (and above) kernels.
    Why do I use it?
    To filter frames by MAC-address or frame type at Link Layer inside your Linux-based Ethernet bridge, to do some basic filtering of certain protocol headers, to make a Linux brouter.
    [Back to the top]
  2. Installation
    What should I know before ebtables installation?
    First step is to decide what kernel version to use. If you want to use a 2.5.x (or above) kernel, then just use the latest and greatest kernel version. You won't have to patch the kernel. Check out the submitted kernel patches, available through the sourcecode section of the ebtables homepage to see if there are any pending patches.
    If you want to use a 2.4.x kernel, then go to Ethernet bridge tables and download the br_nf_bds, ebtables_kernel and ebtables packages. Use the latest packages and use the kernel version for which the kernel patches were made. The ebtables_kernel patch has to be applied before the br_nf_bds kernel patch.
    What is the "ebtables_kernel" package and how do I install it?
    The ebtables_kernel package contains a patch against a Linux 2.4.x kernel. It allows filtering on the Link Layer (OSI Layer 2). It is well-known that iptables works on the Network Layer (OSI Layer 3) and on higher layers. For a bridging firewall it is important to be able to filter on the Link Layer as well.
    Copy the patch file to the kernel source (usually it is named /usr/src/linux or /usr/src/linux-2.X.YZ) and execute the following (use the correct file names and directories where necessary)
    # cp ebtables-v2.0.003_vs_2.4.20.diff.gz /usr/src/linux
    # cd /usr/src/linux
    # gunzip ebtables-v2.0.003_vs_2.4.20.diff.gz 
    # patch -p1 < ebtables-v2.0.003_vs_2.4.20.diff
    What is the "br-nf-bds" package and how do I install it?
    The br-nf-bds package contains a patch against a Linux kernel that is already patched with the ebtables_kernel patch. It adds the ability of iptables usage on bridge packets to make a bridging firewall. Most work on this patch was done by Lennert Buytenhek. The bridge-nf code is automatically compiled into the patched kernel if the bridge and netfilter support is enabled.
    # cp bridge-nf-0.0.10-against-2.4.20.diff.gz /usr/src/linux
    # cd /usr/src/linux
    # gunzip bridge-nf-0.0.10-against-2.4.20.diff.gz
    # patch -p1 < bridge-nf-0.0.10-against-2.4.20.diff
    What is the "ebtables" package and how do I install it?
    The ebtables package contains the ebtables userspace tool. This ebtables binary is used to make filtering rules for the Linux-based Ethernet bridge. All traffic entering or leaving on a bridge port will be seen by the rules. The ebtables usage is very similar to the iptables, so it should not be so hard. Of course, there is a man page supplied. Just gunzip and untar the package and read the INSTALL file.
    # make
    Copy the ebtables binary, man page and protocol file to the correct directory (see the INSTALL file for options):
    # make install
    [Back to the top]
  3. Usage
    Can I filter on ARP packets in the Linux bridge box using ebtables?
    Yes, it's possible to filter on the ARP header, using ebtables. See the ebtables manual page for details.
    Can I use ebtables with iptables? Are there any problems to use it together? How exactly the packet/frame traversing the ebtables/iptables?
    Yes, it's possible to use ebtables with iptables. Detailed info about ebtables/iptables interaction is explained at the "ebtables/iptables interaction on a Linux-based bridge" page.
    Does ebtables keep count statistics?
    Yes, it's possible to view the match and byte count for every rule, using
    # ebtables -L --Lc
    When using the option --Lc, what does the pcnt value represent?
    Normally, pcnt will represent the number of frames that matched this rule. However, if IP connection tracking is enabled, all fragmented IP packets will first be defragmented. Therefore, the pcnt value for IP packets will then represent the number of matched IP packets, not the number of matched frames containing IP fragments. In the BROUTING chain however, pcnt will always represent the number of matched frames, since the IP connection tracking is not done before this chain is traversed.
    What is this brouter stuff and when is it useful?
    The ebtables BROUTING chain gets traversed very early, namely right after a frame is received on a forwarding bridge port. If a rule's decision is to route the frame, the input device will remain the physical device of the bridge port and the bridge code won't touch the frame. The frame will be processed by the network stack. If the decision is to bridge the frame (the default behaviour), then the input device will become the bridge device on which the port is enslaved and the bridge code will decide what to do with the frame.
    So, what's the difference between the ebtables BROUTING and PREROUTING chains?
    The ebtables PREROUTING chain is only traversed when the bridge code is deciding what to do with the frame. So, if a BROUTING chain rule decided the frame should be routed, then the ebtables PREROUTING chain won't see it. See the "ebtables/iptables interaction on a Linux-based bridge" page for the details.
    I'm using a 2.5.x or higher kernel and my iptables rules won't match on the bridge port devices, what's wrong?
    There is one difference between the br-nf behaviour in the 2.5.x or higher kernels and the 2.4.x patch. To get the br-nf code accepted into the standard 2.5.x kernels, we had to remove the code that automatically checked on the bridge port in the iptables port checking code (options -i and -o). Instead there is now an iptables match module that you have to use to filter on the bridge ports. This kernel module is in the standard 2.5.x kernels and the corresponding userspace module is available in the iptables userspace tool. See the iptables man pages and
    # iptables -m physdev -h
    The kernel module has to be compiled in the kernel, the option ``physdev match support'' will appear under the ``IP netfilter configuration'' when the bridge is already enabled in the configuration.
    I want to use the most recent ebtables code, even if it's not yet in an official release. How do I do this?
    The most recent code is available at the sourceforge ebtables CVS repository. To get a copy of the repository, do the following:
    # cvs login
    # cvs -z3 co ebtables2
    The current userspace code is in the ebtables2/userspace/ebtables2 directory. To compile the CVS userspace tool you'll need to do the following:
    # make KERNEL_INCLUDES=/usr/src/linux/include/
    # make install
    Obviously you'll need to use the right kernel directory. Why is compiling the CVS different? Because the kernel include files are not maintained in the userspace directory of the CVS. When a new ebtables release is made, the kernel include files get copied in the tar file, so the standard installation knows where to get its kernel include files.
    To copy the ebtables kernel 2.4.x code to a full 2.4.x kernel tree, use this script:
    To copy the ebtables kernel 2.5.x code to a full 2.5.x kernel tree, use this script:
    You'll need to adjust the variables $FROM and $TO in the script, for more information: read the script.

    [Back to the top]
  4. Problems
    My bridging box seems to drop all IP packets, which is not what I want and I'm sure my ebtables rules don't drop them.
    Your iptables rules are probably dropping them then. On a Linux bridging firewall all bridge IP packets are seen by iptables, so you should take that into account.
    This stuff isn't working on my 64-bit machine with a 32-bit userspace (like the Sparc64)
    We know. It's kind of hard to fix this without access to such a machine. The problem is caused by the different word length between kernel and userspace.
    I'm getting this message when doing IP DNAT: ``Performing cross-bridge DNAT requires IP forwarding to be enabled''
    First make sure IP forwarding is enabled:
    # echo '1' > /proc/sys/net/ipv4/ip_forward
    If that's the case and the message doesn't go away, make sure your routing table has all necessary entries. For example, suppose we want to DNAT traffic on a bridge device that doesn't have an IP address to an IP address somewhere on the Internet.
    eth0 = connection to Internet
    br0 = eth1+eth2
    br0 has no IP address
    iptables -t nat -A PREROUTING -s -d -j DNAT --to-dest <destination>
    route -A -net netmask dev br0 is on the eth1 side, .4 on the eth2 side, the <destination> is somewhere on the Internet. Without the routing table entry (last line above), it is obvious that this DNAT wouldn't work (because the bridge/router wouldn't know where to send 172.16.1.xx traffic). It is possible that the mentioned error message gets printed on the screen or in your logs when this routing table entry is omitted.

    [Back to the top]
  5. Other
    I'm not a Linux system's programmer, but I need a feature, which is not (yet) implemented in ebtables. What should I do?
    Subscribe to the ebtables users mailing list. Then post a short and clean description of your wanted feature to this mailing list.
    I'm a C programmer and I want to add an ebtables feature by myself. Where should I begin?
    Subscribe to the ebtables developers mail list. Read the "Ebtables Hacking HOWTO" and have a look at the already implemented modules. You will find that adding a module is not very hard. Additional information is available at the ebtables homepage.

    [Back to the top]