Last modified: November 09, 2003
[Back to the top]
- 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]
- 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
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.
Copy the ebtables binary, man page and protocol file to the correct
directory (see the INSTALL file for options):
# make install
- Can I filter on ARP packets in the Linux bridge box using
- Yes, it's possible to filter on the ARP header, using ebtables.
See the ebtables manual page for
- 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
- 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:firstname.lastname@example.org:/cvsroot/ebtables login
# cvs -z3 -d:pserver:email@example.com:/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
[Back to the top]
- 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]
- 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
[Back to the top]