| <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> |
| <HTML> |
| <HEAD> |
| <TITLE>Ebtables (Ethernet Bridge Tables) Frequently Asked |
| Questions</TITLE> |
| <LINK rel="SHORTCUT ICON" href=""> |
| <LINK rel="STYLESHEET" type="text/css" href="ebtables.css"> |
| <META name="description" content= |
| "Ethernet Bridge Tables Frequently Asked Questions"> |
| <META name="author" content="Nick Fedchik"> |
| <META name="keywords" content= |
| "Linux, netfilter, firewall, bridge, brouter, ebtables, iptables"> |
| <META name="keywords" content= |
| "FAQ, kernel, ebtables, br-nf, br-nf-bds, ethernet, nat, chains, rules, tables"> |
| </HEAD> |
| <BODY> |
| <DIV class="banner" align="center"> |
| <H1>Ebtables (Ethernet Bridge Tables) Frequently Asked Questions</H1> |
| </DIV> |
| <A name="top"></A> |
| <P>Last modified: April 15, 2003</P> |
| <H2>Questions</H2> |
| <OL> |
| <LI><A href="#quiz0">Intro</A></LI> |
| <LI><A href="#quiz1">Installation</A></LI> |
| <LI><A href="#quiz2">Usage</A></LI> |
| <LI><A href="#quiz3">Problems</A></LI> |
| <LI><A href="#quiz4">Other</A></LI> |
| </OL> |
| <H2>Answers</H2> |
| <OL> |
| <LI> |
| <B><A name="quiz0">Intro</A></B> |
| <DL> |
| <DT>What is ebtables?</DT> |
| <DD>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.</DD> |
| <DT>Why do I use it?</DT> |
| <DD>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.</DD> |
| </DL> |
| <A class=navbar href="#top">[Back to the top]</A> |
| <HR> |
| </LI> |
| <LI> |
| <B><A name="quiz1">Installation</A></B> |
| <DL> |
| <DT>What should I know before ebtables installation?</DT> |
| <DD>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 |
| <A href="http://ebtables.sourceforge.net/sourcecode.html"> |
| sourcecode</A> section of the ebtables <A href="http://ebtables.sourceforge.net"> |
| homepage</A> to see if there are any pending patches.</DD> |
| <DD>If you want to use a 2.4.x kernel, then go to |
| <A href="http://sourceforge.net/projects/ebtables/">Ethernet bridge |
| tables</A> and download the <B>br_nf_bds</B>, <B>ebtables_kernel</B> |
| and <B>ebtables</B> packages. Use the latest packages and use the |
| kernel version for which the kernel patches were made. The |
| <B>ebtables_kernel</B> patch has to be applied before the <B>br_nf_bds</B> |
| kernel patch.</DD> |
| <DT>What is the "ebtables_kernel" package and how do I install it?</DT> |
| <DD> |
| The <B>ebtables_kernel</B> 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.</DD> |
| <DD>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) |
| <PRE> |
| # 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 |
| </PRE> |
| </DD> |
| <DT>What is the "br-nf-bds" package and how do I install it?</DT> |
| <DD> |
| The <B>br-nf-bds</B> package contains a patch against a Linux |
| kernel that is already patched with the <B>ebtables_kernel</B> |
| 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. |
| <PRE> |
| # 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 |
| </PRE> |
| </DD> |
| <DT>What is the "ebtables" package and how do I install it?</DT> |
| <DD> |
| The <B>ebtables</B> 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.<BR> |
| |
| <PRE> |
| # make |
| </PRE> |
| Copy the ebtables binary, man page and protocol file to the correct |
| directory (see the INSTALL file for options): |
| <PRE> |
| # make install |
| </PRE> |
| </DD> |
| </DL> |
| <A class=navbar href="#top">[Back to the top]</A> |
| <HR> |
| </LI> |
| <LI> |
| <B><A name="quiz2">Usage</A></B> |
| <DL> |
| <DT>Can I filter on ARP packets in the Linux bridge box using |
| ebtables?</DT> |
| <DD>Yes, it's possible to filter on the ARP header, using ebtables. |
| See the <A href="http://ebtables.sourceforge.net/ebtables-man.html">ebtables manual page</A> for |
| details.</DD> |
| <DT>Can I use ebtables with iptables? Are there any problems to |
| use it together? How exactly the packet/frame traversing the ebtables/iptables?</DT> |
| <DD>Yes, it's possible to use ebtables with iptables. Detailed |
| info about ebtables/iptables interaction is explained at the |
| <A href="http://ebtables.sourceforge.net/br_fw_ia/br_fw_ia.html"> |
| "ebtables/iptables interaction on a Linux-based bridge"</A> page.</DD> |
| <DT>Does ebtables keep count statistics?</DT> |
| <DD> |
| Yes, it's possible to view the match and byte count for every rule, using |
| <PRE> |
| # ebtables -L --Lc |
| </PRE> |
| </DD> |
| <DT>When using the option --Lc, what does the pcnt value represent?</DT> |
| <DD> |
| 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. |
| </DD> |
| <DT>What is this brouter stuff and when is it useful?</DT> |
| <DD> |
| 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.</DD> |
| <DT>So, what's the difference between the ebtables BROUTING and PREROUTING chains?</DT> |
| <DD>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 |
| <A href="http://ebtables.sourceforge.net/br_fw_ia/br_fw_ia.html"> |
| "ebtables/iptables interaction on a Linux-based bridge"</A> page for the details.</DD> |
| <DT>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?</DT> |
| <DD> |
| 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 |
| <PRE> |
| # iptables -m physdev -h |
| </PRE> |
| 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. |
| </DD> |
| <DT>I want to use the most recent ebtables code, even if it's not yet in an official release. |
| How do I do this?</DT> |
| <DD> |
| The most recent code is available at the <A href="http://sourceforge.net/projects/ebtables"> |
| sourceforge ebtables</A> CVS repository. To get a copy of the repository, do the following: |
| <PRE> |
| # cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/ebtables login |
| # cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/ebtables co ebtables2 |
| </PRE> |
| The current userspace code is in the ebtables2/userspace/ebtables2 directory. To compile the |
| CVS userspace tool you'll need to do the following: |
| <PRE> |
| # make KERNEL_INCLUDES=/usr/src/linux/include/ |
| # make install |
| </PRE> |
| 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.</DD> |
| <DD>To copy the ebtables kernel 2.4.x code to a full 2.4.x kernel tree, use this script: |
| <PRE> |
| ebtables2/kernel/scripts/CopyRep |
| </PRE> |
| To copy the ebtables kernel 2.5.x code to a full 2.5.x kernel tree, use this script: |
| <PRE> |
| ebtables2/kernel/scripts/CopyRep2.5 |
| </PRE> |
| You'll need to adjust the variables $FROM and $TO in the script, for more information: read the |
| script.</DD> |
| </DL> |
| <BR> |
| <A class=navbar href="#top">[Back to the top]</A> |
| <HR> |
| </LI> |
| <LI> |
| <B><A name="quiz3">Problems</A></B><BR> |
| <DL> |
| <DT>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.</DT> |
| <DD>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.</DD> |
| <DT>This stuff isn't working on my 64-bit machine with a 32-bit userspace (like the Sparc64)</DT> |
| <DD>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.</DD> |
| <DT>I'm getting this message when doing IP DNAT: ``Performing cross-bridge DNAT requires IP |
| forwarding to be enabled''</DT> |
| <DD>First make sure IP forwarding is enabled: |
| <PRE> |
| # echo '1' > /proc/sys/net/ipv4/ip_forward |
| </PRE> |
| 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. |
| <PRE> |
| 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 |
| </PRE> |
| 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. |
| </DD> |
| </DL> |
| <BR> |
| <A class=navbar href="#top">[Back to the top]</A> |
| </LI> |
| <LI> |
| <B><A name="quiz4">Other</A></B><BR> |
| <DL> |
| <DT>I'm not a Linux system's programmer, but I need a feature, which |
| is not (yet) implemented in ebtables. What should I do?</DT> |
| <DD>Subscribe to the <A href= "https://lists.sourceforge.net/lists/listinfo/ebtables-user"> |
| ebtables users mailing list</A>. Then post a short and clean description of |
| your wanted feature to this mailing list.</DD> |
| <DT>I'm a C programmer and I want to add an ebtables feature by |
| myself. Where should I begin?</DT> |
| <DD>Subscribe to the <A href= |
| "https://lists.sourceforge.net/lists/listinfo/ebtables-devel">ebtables |
| developers mail list</A>. Read the <A href= |
| "http://ebtables.sourceforge.net/ebtables-hacking/ebtables-hacking-HOWTO.html">"Ebtables Hacking HOWTO"</A> 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 <A href="http://ebtables.sourceforge.net"> |
| homepage</A>.</DD> |
| </DL> |
| <BR> |
| <A class=navbar href="#top">[Back to the top]</A> |
| </LI> |
| </OL> |
| <HR> |
| </BODY> |
| </HTML> |