Last modified: November 09, 2003

Questions

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

Answers

  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 would 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
    How do I install the kernel part?
    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.
    If you want to use a 2.4.x kernel, then go to Ethernet bridge tables and download the latest patch from the 2.4-ebtables-brnf package. Apply the patch as follows (substitute "linux" for the appropriate directory): 
    # cp ebtables-brnf-3_vs_2.4.22.diff.gz /usr/src/linux
# cd /usr/src/linux
# gunzip ebtables-brnf-3_vs_2.4.22.diff.gz
# patch -p1 < ebtables-brnf-3_vs_2.4.22.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 is the packet/frame traversing order for ebtables/iptables?
    Yes, it's possible to use ebtables together with iptables, there are no incompatibility issues. 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, called 'physdev', that can be used to filter on the bridge ports. This match module has some extra options and is in the standard 2.6 kernels, 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 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/ebtables login
# cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/ebtables 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.
    The ebtables CVS tree has its own kernel tree with ebtables related files (for 2.4 and 2.6). The CVS directory (base_dir)/ebtables2/kernel/linux2.5/include/ can be used for compiling the userspace tool.
    New ebtables modules might not yet be in the standard kernel. The CVS directory (base_dir)/ebtables2/kernel/linux2.5/net/bridge/netfilter/ contains the not yet submitted modules. The modules that are already in the standard kernel are also in this directory and they are normally in sync with the latest kernel release.

    [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. By default, on a Linux bridging firewall all bridged 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)
    As from ebtables v2.0.5, ebtables-brnf-2_vs_2.4.21.diff.gz and above 2.6.0-test1, it should work on a Sparc64. In case it doesn't, please notify the ebtables-devel mailing list. Making it work on a different 64/32 processor should be easy, but we'll wait for someone to come along who asks for this and who can consequently test the fix.
    I'm getting a message that looks like: ``br_netfilter: Argh!! : bad mac.raw pointer''
    We sometimes get reports about this message occurring. The bridge-nf code reports this message when a specific irregularity is observed, in technical terms: the mac.raw pointer of the sk_buff isn't set properly. The most likely cause of this is the network device driver. Since this only happens for a few persons, the only way to debug this is if those persons are willing to try patches. Up until now this has not been the case.
    The easiest solution is to try a different type of network card or a different device driver.
    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 172.16.1.2 -d 172.16.1.4 -j DNAT --to-dest <destination>
route -A -net 172.16.1.0 netmask 255.255.255.0 dev br0
    172.16.1.2 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.
    I'm trying to create a brouter that routes all IP traffic using the command "ebtables -t broute -A BROUTING -p IPv4 -j DROP", but it's not working...
    The DROP target in the BROUTING chain doesn't change the MAC destination to the bridge device, by default. You need to explicitly do this by using the redirect target: 
    ebtables -t broute -A BROUTING -p IPv4 -j redirect --redirect-target DROP

    [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]