docs/how_it_works.html - external/ebtables - Gitiles

 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3c.org/TR/1999/REC-html401-19991224/loose.dtd">
 <HTML><HEAD><TITLE>How bridge/ebtables/iptables interaction works</TITLE>
 <META http-equiv=Content-Type content="text/html; charset=iso-8859-15">
 <STYLE type=text/css>H1 {
 	FONT: bold 25pt Times, serif; TEXT-ALIGN: center; TEXT-DECORATION: underline
 }
 P {
 	FONT: 20pt Times, serif
 }
 LI {
 	MARGIN-BOTTOM: 2em; FONT: 22pt 'Times New Roman', serif
 }
 PRE {
 	FONT: 18pt Courier, monospace
 }
 .statement {
 	TEXT-DECORATION: underline
 }
 .section {
 	FONT: bold 22pt Times
 }
 .case {
 	FONT-STYLE: italic
 }
 </STYLE>

 <META content="MSHTML 6.00.2505.0" name=GENERATOR></HEAD>
 <BODY>
 <H1>How bridge/ebtables/iptables interaction works</H1>

 <P class=section>1. How frames traverse the <EM>ebtables</EM> chains:</P>
 <P>This section only considers <EM>ebtables</EM>, _not_ <EM>iptables</EM>.</P>
 <PRE>
      Route
        ^
        |
 I  +--------+ Bridge  +----------+                     +-------+      +-----------+   O
 N->|BROUTING|-------->|PREROUTING|----->[BRIDGING]---->|FORWARD| ---->|POSTROUTING|-->U
    +--------+         +----------+      [DECISION]     +-------+      +-----------+   T
                                              |                              ^
                                              v                              |
                                           +-----+                      +----------+
                                           |INPUT|                      |OUTPUT (2)|
                                           +-----+                      +----------+
                                              |                              ^
                                              |                              |
                                              |                         +----------+
                                              |                         +OUTPUT (1)+
                                              |                         +----------+
                                              |                              ^
                                              +------->Local Process---------+
 </PRE>
 <P>
 First thing to keep in mind is that we are talking about the ethernet layer here,
 so the OSI layer 2. A packet destined for the local computer according to the bridge
 (which works on the ethernet layer) isn't necessarily destined for the local computer
 according to the ip layer. That's how routing works (MAC destination is the router, ip
 destination is the actual box you want to communicate with).</P>
 <P>
 <EM>Ebtables</EM> currently has three tables: filter, nat and broute. The filter table has a
 FORWARD, INPUT and OUTPUT chain. The nat table has a PREROUTING, OUTPUT and POSTROUTING chain.
 The broute table has the BROUTING chain. In the figure the filter OUTPUT chain has (2)
 appended and the nat OUTPUT chain has (1) appended. So these two OUTPUT chains are not
 the same (and have a different intended use).</P>
 <P>
 When a nic enslaved to a bridge receives a frame, the frame will first go through the BROUTING
 chain. In this special chain one can choose whether to route or bridge frames. The default
 is bridging and we will assume the decision in this chain is 'bridge'. So, next the frame
 passes through the PREROUTING chain. This chain is intended for you to be able to alter the
 destination MAC address of
 frames (DNAT). If the frame passes this chain, the bridging code will decide where the
 frame should be sent. The bridge does this by looking at the destination MAC address, it
 doesn't care about the OSI layer 3 addresses (e.g. ip address). Note that frames coming in
 on non-forwarding ports of a bridge will not be seen by <EM>ebtables</EM>, not even by the BROUTING
 chain.</P>
 <P>
 If the bridge decides the frame is for the bridging computer, the frame will go through the
 INPUT chain. In this chain you can filter frames destined for the bridge box. After passing
 the INPUT chain, the frame will be given to the code on layer 3 (i.e. it will be passed up),
 e.g. to the ip code. So, a routed ip packet will go through the <EM>ebtables</EM> INPUT chain, not
 through the <EM>ebtables</EM> FORWARD chain. This is logical.</P>
 <P>
 Else the frame should possibly be sent onto another side of the bridge. If it should, the
 frame will go through the FORWARD chain and the POSTROUTING chain. In the FORWARD chain one
 can filter frames that will be bridged, the POSTROUTING chain is intended to be able to
 change the MAC source address (SNAT).</P>
 <P>
 Frames that originate from the bridge box itself will go, after the bridging decision, through the
 nat OUTPUT chain, through the filter OUTPUT chain and the POSTROUTING chain. The
 nat OUTPUT chain allows you to alter the destination MAC address and the filter OUTPUT chain
 allows you to filter frames originating from the bridge box. Note that the nat OUTPUT chain is
 traversed after the bridging decision, so actually too late. We should change this. The POSTROUTING
 chain is the same one as described above. Note that it is also possible for routed frames to go
 through these chains, this is when the destination device is a logical bridge device.</P>
 <P class=section>
 2. A machine used as a bridge and a router (not a brouter):</P>
 <P>
 It's possible to see a single ip packet pass the PREROUTING, INPUT, nat OUTPUT, filter OUTPUT
 and POSTROUTING <EM>ebtables</EM> chains.</P>
 <P>
 This can happen when the bridge is also used as a router. The ethernet frame(s) containing that
 ip packet will have the bridge's destination MAC address, while the destination ip address is not
 that of the bridge. Including the <EM>iptables</EM> chains, this is how the ip packet runs through the
 bridge/router (eb=ebtables , ip=iptables ):</P>
 <PRE>ebPREROUTING->ipPREROUTING->ebINPUT->ipFORWARD->ipPOSTROUTING->ebOUTPUT(1)->ebOUTPUT(2)->ebPOSTROUTING->send packet</PRE>
 <P>
 This assumes that the routing decision sends the packet to a bridge interface. If the routing
 decision sends the packet to a physical network card, this is what happens:</P>
 <PRE>ebPREROUTING->ipPREROUTING->ebINPUT->ipFORWARD->ipPOSTROUTING->send packet</PRE>
 <P>
 What is obviously "asymmetric" here is that the <EM>iptables</EM> PREROUTING chain is traversed before
 the <EM>ebtables</EM> INPUT chain, however this can not be helped. See the next section.</P>
 <P class=section>
 3. DNATing bridged packets:</P>
 <P>
 Take an ip packet received by the bridge,  it enters the bridge code. Lets assume we want to do
 some ip DNAT on it. Changing the destination address of the packet (ip address and MAC address)
 has to happen before the bridge code decides what to do with the packet. The bridge code can decide
 to bridge it (if the destination MAC address is on another side of the bridge), flood it over all
 the forwarding bridge ports (the position of the box with the destination MAC is unknown to the bridge),
 give it to the higher protocol code (here, the ip code) if the destination MAC address is that of the
 bridge, or ignore it (the destination MAC address is located on the same side of the bridge).</P>
 <P>
 So, this ip DNAT has to happen very early in the bridge code. Namely before the bridge code
 actually does anything. This is at the same place as where the <EM>ebtables</EM> PREROUTING chain will
 be traversed (for the same reason).</P>
 <P class=section>
 4. Chain traversal for bridged ip packets:</P>
 <P>
 A bridged packet never enters any network code above layer 2. So a bridged ip packet will never
 enter the ip code. Therefore all <EM>iptables</EM> chains will be traversed while the ip packet is in the
 bridge code. The chain traversal will look like this:</P>
 <PRE>
 ebPREROUTING->ipPREROUTING->ebFORWARD->ipFORWARD->ebPOSTROUTING->ipPOSTROUTING</PRE>
 <P>
 Once again note that there is a certain form of asymmetry here that cannot be helped.</P>
 <P class=section>
 5. Using a bridge port in <EM>iptables</EM> rules:</P>
 <P>
 The wish to be able to use physical devices belonging to a bridge (bridge ports) in <EM>iptables</EM> rules
 is valid. It's necessary to prevent spoofing attacks. Say br0 has ports eth0 and eth1. If <EM>iptables</EM>
 rules can only use br0 there's no way of knowing when a box on the eth0 side changes it's source ip
 address to that of a box on the eth1 side, except by looking at the MAC source address (and then
 still...). With the current bridge/iptables patch (0.0.6 or later) you can use eth0 and eth1 in your
 <EM>iptables</EM> rules and therefore catch these attempts.</P>
 <P class=case>
 1. <EM>iptables</EM> wants to use bridge ports:<P>
 <P>
 To make this possible the <EM>iptables</EM> chains have to be traversed after the bridge code decided where
 the frame needs to be sent (eth0, eth1, both or none). This has some impact on the scheme presented
 in section 2 (so, we are looking at routed traffic here). It actually looks like this:</P>
 <PRE>
 ebPREROUTING->ipPREROUTING->ebINPUT->ipFORWARD->ebOUTPUT(1)->ebOUTPUT(2)->ipPOSTROUTING->ebPOSTROUTING->send packet</PRE>
 <P>
 Note that this is the work of the br-nf patch. If one does not compile the br-nf code into the kernel,
 the chains will be traversed as shown below. However, then one can only use br0, not eth0/eth1 to
 filter.</P>
 <PRE>ebPREROUTING->ebINPUT->ipPREROUTING->ipFORWARD->ipPOSTROUTING->ebOUTPUT(1)->ebOUTPUT(2)->ebPOSTROUTING->send packet</PRE>
 <P>
 Notice that ipPREROUTING is now in the natural position in the chain list and too far to be able to change
 the bridging decision. More precise: ipPREROUTING is now traversed while the packet is in the ip code.</P>
 <P class=case>
 2. IP DNAT for locally generated packets (so in the <EM>iptables</EM> nat OUTPUT chain):</P>
 <P>
 The 'normal' way locally generated packets would go through the chains looks like this:</P>
 <PRE>
 ipOUTPUT(1)->ipOUTPUT(2)->ipPOSTROUTING->ebOUTPUT(1)->ebOUTPUT(2)->ebPOSTROUTING</PRE>
 <P>
 From the section 5.1 we know that this actually looks like this:</P>
 <PRE>
 ipOUTPUT(1)->ipOUTPUT(2)->ebOUTPUT(1)->ebOUTPUT(2)->ebPOSTROUTING->ipPOSTROUTING</PRE>
 <P>
 Here we denote by ipOUTPUT(1) (resp. ipOUTPUT(2)) the <EM>iptables</EM> nat (resp. filter) OUTPUT chain. Note that
 the ipOUTPUT(1) chain is traversed while the packet is in the ip code, while the ipOUTPUT(2) chain is traversed when
 the packet has entered the bridge code. This makes it possible to do DNAT to another device in ipOUTPUT(1) and lets
 one use the bridge ports in the ipOUTPUT(2) chain.</P>
 <P class=section>
 6. Two possible ways for frames/packets to pass through the <EM>iptables</EM> PREROUTING, FORWARD and POSTROUTING
 chains:</P>
 <P>
 With the br-nf patch there are 2 ways a frame/packet can pass through the 3 given <EM>iptables</EM>
 chains. The first way is when the frame is bridged, so the <EM>iptables</EM> chains are called by the bridge code.
 The second way is when the packet is routed. So special care has to be taken to distinguish between those
 two, especially in the <EM>iptables</EM> FORWARD chain. Here's an example of strange things to look out for:</P>
 <P>
 Consider the following situation (my personal setup)</P>
 <PRE>
          +-----------------+
          |   cable modem   |
          +-------+---------+
                  |
                  |
              eth0|IP via DHCP from ISP
          +-------+---------+
          |bridge/router/fw |
          +--+-----------+--+
         eth1| 172.16.1.1|eth2
             |   (br0)   |
             |           |
   172.16.1.4|           |172.16.1.2
  +----------+---+    +--+------------+
  |test computer/|    |    desktop    |
  |backup server |    +---------------+
  +--------------+</PRE>
 <P>
 With this setup I can test the bridge+ebtables+iptables code while having access to the internet from all
 three computers. The default gateway for 172.16.1.2 and 172.16.1.4 is 172.16.1.1. 172.16.1.1 is the bridge
 interface br0 with ports eth1 and eth2.</P>
 <P class=case>More details:</P>
 <P>
 The idea is that traffic between 172.16.1.4 and 172.16.2 is bridged, while the rest is routed, using
 masquerading. Here's the "script" I use at bootup for the bridge/router:</P>
 <PRE>
 iptables -t nat -A POSTROUTING -s 172.16.1.0/24 -d 172.16.1.0/24 -j ACCEPT
 iptables -t nat -A POSTROUTING -s 172.16.1.0/24 -j MASQUERADE
 insmod ebtables
 insmod ebtable_filter
 insmod ebtable_nat
 insmod ebt_nat
 insmod ebt_log
 insmod ebt_arp
 insmod ebt_ip
 insmod br_db
 brctl addbr br0
 brctl stp br0 off
 brctl addif br0 eth1
 brctl addif br0 eth2
 ifconfig eth1 0 0.0.0.0
 ifconfig eth2 0 0.0.0.0
 ifconfig br0 172.16.1.1 netmask 255.255.255.0 up
 echo '1' > /proc/sys/net/ipv4/ip_forward</PRE>
 <P>
 The catch is in the first line. Because the <EM>iptables</EM> code gets executed for both bridged packets and routed
 packets we need to make a distinction between the two. We don't really want the bridged packets to be
 masqueraded. If we omit the first line then everything will work too, but things will happen differently.
 Let's say 172.16.1.2 pings 172.16.1.4. The bridge receives the ping request and will transmit it through its eth1
 port after first masquerading the ip address. So the packet's source ip address will now be 172.16.1.1 and
 172.16.1.4 will respond to the bridge. Masquerading will change the ip destination of this response from
 172.16.1.1 to 172.16.1.4. Everything works fine. But it's better not to have this behaviour. Thus, we use the
 first line of the script to avoid this. Note that if I wanted to filter the connections to and from the
 internet, I would certainly need the first line so I don't filter the local connections as well.</P>
 <P class=section>
 7. ip DNAT in the <EM>iptables</EM> PREROUTING chain on frames/packets entering on a bridge port:</P>
 <P>Through some groovy play it is assured that (see /net/bridge/br_netfilter.c) DNAT'ed packets that after DNAT'ing
 have the same output device as the input device they came on (the logical bridge device which we like to call br0)
 will be bridged, not routed. So they will go through the <EM>ebtables</EM> FORWARD chain. All other DNAT'ed packets will be
 routed, so won't go through the <EM>ebtables</EM> FORWARD chain, will go through the <EM>ebtables</EM> INPUT chain and might go
 through the <EM>ebtables</EM> OUTPUT chain.</P>
 <P class=section>
 8. using the mac module extension for <EM>iptables</EM>:</P>
 <P>The side effect explained here occurs when the br-nf code is compiled in the kernel, the ip packet is routed and the out device
 for that packet is a logical bridge. The side effect is encountered when filtering on the mac source in the
 <EM>iptables</EM> FORWARD chains. As should be clear from earlier sections, the traversal of the <EM>iptables</EM> FORWARD chains
 is postponed until the packet is in the bridge code. This is done so one can filter on the bridge port out device. This has a
 side effect on the MAC source address, because the ip code will have changed the MAC source address to the MAC address of the bridge.
 It is therefore impossible, in the <EM>iptables</EM> FORWARD chains, to filter on the MAC source address of the computer sending
 the packet in question to the bridge/router. If you really need to filter on this MAC source address, you should do it in the nat
 PREROUTING chain. Agreed, very ugly, but making it possible to filter on the real MAC source address in the FORWARD chains would
 involve a very dirty hack and is probably not worth it.</P>
 <P>
 Released under the GPL.</P>
 <P>
 Bart De Schuymer.</P>
 <P>
 Last updated June 2nd, 2002.</P>
 </BODY></HTML>
	<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3c.org/TR/1999/REC-html401-19991224/loose.dtd">
	<HTML><HEAD><TITLE>How bridge/ebtables/iptables interaction works</TITLE>
	<META http-equiv=Content-Type content="text/html; charset=iso-8859-15">
	<STYLE type=text/css>H1 {
	FONT: bold 25pt Times, serif; TEXT-ALIGN: center; TEXT-DECORATION: underline
	}
	P {
	FONT: 20pt Times, serif
	}
	LI {
	MARGIN-BOTTOM: 2em; FONT: 22pt 'Times New Roman', serif
	}
	PRE {
	FONT: 18pt Courier, monospace
	}
	.statement {
	TEXT-DECORATION: underline
	}
	.section {
	FONT: bold 22pt Times
	}
	.case {
	FONT-STYLE: italic
	}
	</STYLE>

	<META content="MSHTML 6.00.2505.0" name=GENERATOR></HEAD>
	<BODY>
	<H1>How bridge/ebtables/iptables interaction works</H1>

	<P class=section>1. How frames traverse the <EM>ebtables</EM> chains:</P>
	<P>This section only considers <EM>ebtables</EM>, _not_ <EM>iptables</EM>.</P>
	<PRE>
	Route
	^
	\|
	I +--------+ Bridge +----------+ +-------+ +-----------+ O
	N->\|BROUTING\|-------->\|PREROUTING\|----->[BRIDGING]---->\|FORWARD\| ---->\|POSTROUTING\|-->U
	+--------+ +----------+ [DECISION] +-------+ +-----------+ T
	\| ^
	v \|
	+-----+ +----------+
	\|INPUT\| \|OUTPUT (2)\|
	+-----+ +----------+
	\| ^
	\| \|
	\| +----------+
	\| +OUTPUT (1)+
	\| +----------+
	\| ^
	+------->Local Process---------+
	</PRE>
	<P>
	First thing to keep in mind is that we are talking about the ethernet layer here,
	so the OSI layer 2. A packet destined for the local computer according to the bridge
	(which works on the ethernet layer) isn't necessarily destined for the local computer
	according to the ip layer. That's how routing works (MAC destination is the router, ip
	destination is the actual box you want to communicate with).</P>
	<P>
	<EM>Ebtables</EM> currently has three tables: filter, nat and broute. The filter table has a
	FORWARD, INPUT and OUTPUT chain. The nat table has a PREROUTING, OUTPUT and POSTROUTING chain.
	The broute table has the BROUTING chain. In the figure the filter OUTPUT chain has (2)
	appended and the nat OUTPUT chain has (1) appended. So these two OUTPUT chains are not
	the same (and have a different intended use).</P>
	<P>
	When a nic enslaved to a bridge receives a frame, the frame will first go through the BROUTING
	chain. In this special chain one can choose whether to route or bridge frames. The default
	is bridging and we will assume the decision in this chain is 'bridge'. So, next the frame
	passes through the PREROUTING chain. This chain is intended for you to be able to alter the
	destination MAC address of
	frames (DNAT). If the frame passes this chain, the bridging code will decide where the
	frame should be sent. The bridge does this by looking at the destination MAC address, it
	doesn't care about the OSI layer 3 addresses (e.g. ip address). Note that frames coming in
	on non-forwarding ports of a bridge will not be seen by <EM>ebtables</EM>, not even by the BROUTING
	chain.</P>
	<P>
	If the bridge decides the frame is for the bridging computer, the frame will go through the
	INPUT chain. In this chain you can filter frames destined for the bridge box. After passing
	the INPUT chain, the frame will be given to the code on layer 3 (i.e. it will be passed up),
	e.g. to the ip code. So, a routed ip packet will go through the <EM>ebtables</EM> INPUT chain, not
	through the <EM>ebtables</EM> FORWARD chain. This is logical.</P>
	<P>
	Else the frame should possibly be sent onto another side of the bridge. If it should, the
	frame will go through the FORWARD chain and the POSTROUTING chain. In the FORWARD chain one
	can filter frames that will be bridged, the POSTROUTING chain is intended to be able to
	change the MAC source address (SNAT).</P>
	<P>
	Frames that originate from the bridge box itself will go, after the bridging decision, through the
	nat OUTPUT chain, through the filter OUTPUT chain and the POSTROUTING chain. The
	nat OUTPUT chain allows you to alter the destination MAC address and the filter OUTPUT chain
	allows you to filter frames originating from the bridge box. Note that the nat OUTPUT chain is
	traversed after the bridging decision, so actually too late. We should change this. The POSTROUTING
	chain is the same one as described above. Note that it is also possible for routed frames to go
	through these chains, this is when the destination device is a logical bridge device.</P>
	<P class=section>
	2. A machine used as a bridge and a router (not a brouter):</P>
	<P>
	It's possible to see a single ip packet pass the PREROUTING, INPUT, nat OUTPUT, filter OUTPUT
	and POSTROUTING <EM>ebtables</EM> chains.</P>
	<P>
	This can happen when the bridge is also used as a router. The ethernet frame(s) containing that
	ip packet will have the bridge's destination MAC address, while the destination ip address is not
	that of the bridge. Including the <EM>iptables</EM> chains, this is how the ip packet runs through the
	bridge/router (eb=ebtables , ip=iptables ):</P>
	<PRE>ebPREROUTING->ipPREROUTING->ebINPUT->ipFORWARD->ipPOSTROUTING->ebOUTPUT(1)->ebOUTPUT(2)->ebPOSTROUTING->send packet</PRE>
	<P>
	This assumes that the routing decision sends the packet to a bridge interface. If the routing
	decision sends the packet to a physical network card, this is what happens:</P>
	<PRE>ebPREROUTING->ipPREROUTING->ebINPUT->ipFORWARD->ipPOSTROUTING->send packet</PRE>
	<P>
	What is obviously "asymmetric" here is that the <EM>iptables</EM> PREROUTING chain is traversed before
	the <EM>ebtables</EM> INPUT chain, however this can not be helped. See the next section.</P>
	<P class=section>
	3. DNATing bridged packets:</P>
	<P>
	Take an ip packet received by the bridge, it enters the bridge code. Lets assume we want to do
	some ip DNAT on it. Changing the destination address of the packet (ip address and MAC address)
	has to happen before the bridge code decides what to do with the packet. The bridge code can decide
	to bridge it (if the destination MAC address is on another side of the bridge), flood it over all
	the forwarding bridge ports (the position of the box with the destination MAC is unknown to the bridge),
	give it to the higher protocol code (here, the ip code) if the destination MAC address is that of the
	bridge, or ignore it (the destination MAC address is located on the same side of the bridge).</P>
	<P>
	So, this ip DNAT has to happen very early in the bridge code. Namely before the bridge code
	actually does anything. This is at the same place as where the <EM>ebtables</EM> PREROUTING chain will
	be traversed (for the same reason).</P>
	<P class=section>
	4. Chain traversal for bridged ip packets:</P>
	<P>
	A bridged packet never enters any network code above layer 2. So a bridged ip packet will never
	enter the ip code. Therefore all <EM>iptables</EM> chains will be traversed while the ip packet is in the
	bridge code. The chain traversal will look like this:</P>
	<PRE>
	ebPREROUTING->ipPREROUTING->ebFORWARD->ipFORWARD->ebPOSTROUTING->ipPOSTROUTING</PRE>
	<P>
	Once again note that there is a certain form of asymmetry here that cannot be helped.</P>
	<P class=section>
	5. Using a bridge port in <EM>iptables</EM> rules:</P>
	<P>
	The wish to be able to use physical devices belonging to a bridge (bridge ports) in <EM>iptables</EM> rules
	is valid. It's necessary to prevent spoofing attacks. Say br0 has ports eth0 and eth1. If <EM>iptables</EM>
	rules can only use br0 there's no way of knowing when a box on the eth0 side changes it's source ip
	address to that of a box on the eth1 side, except by looking at the MAC source address (and then
	still...). With the current bridge/iptables patch (0.0.6 or later) you can use eth0 and eth1 in your
	<EM>iptables</EM> rules and therefore catch these attempts.</P>
	<P class=case>
	1. <EM>iptables</EM> wants to use bridge ports:<P>
	<P>
	To make this possible the <EM>iptables</EM> chains have to be traversed after the bridge code decided where
	the frame needs to be sent (eth0, eth1, both or none). This has some impact on the scheme presented
	in section 2 (so, we are looking at routed traffic here). It actually looks like this:</P>
	<PRE>
	ebPREROUTING->ipPREROUTING->ebINPUT->ipFORWARD->ebOUTPUT(1)->ebOUTPUT(2)->ipPOSTROUTING->ebPOSTROUTING->send packet</PRE>
	<P>
	Note that this is the work of the br-nf patch. If one does not compile the br-nf code into the kernel,
	the chains will be traversed as shown below. However, then one can only use br0, not eth0/eth1 to
	filter.</P>
	<PRE>ebPREROUTING->ebINPUT->ipPREROUTING->ipFORWARD->ipPOSTROUTING->ebOUTPUT(1)->ebOUTPUT(2)->ebPOSTROUTING->send packet</PRE>
	<P>
	Notice that ipPREROUTING is now in the natural position in the chain list and too far to be able to change
	the bridging decision. More precise: ipPREROUTING is now traversed while the packet is in the ip code.</P>
	<P class=case>
	2. IP DNAT for locally generated packets (so in the <EM>iptables</EM> nat OUTPUT chain):</P>
	<P>
	The 'normal' way locally generated packets would go through the chains looks like this:</P>
	<PRE>
	ipOUTPUT(1)->ipOUTPUT(2)->ipPOSTROUTING->ebOUTPUT(1)->ebOUTPUT(2)->ebPOSTROUTING</PRE>
	<P>
	From the section 5.1 we know that this actually looks like this:</P>
	<PRE>
	ipOUTPUT(1)->ipOUTPUT(2)->ebOUTPUT(1)->ebOUTPUT(2)->ebPOSTROUTING->ipPOSTROUTING</PRE>
	<P>
	Here we denote by ipOUTPUT(1) (resp. ipOUTPUT(2)) the <EM>iptables</EM> nat (resp. filter) OUTPUT chain. Note that
	the ipOUTPUT(1) chain is traversed while the packet is in the ip code, while the ipOUTPUT(2) chain is traversed when
	the packet has entered the bridge code. This makes it possible to do DNAT to another device in ipOUTPUT(1) and lets
	one use the bridge ports in the ipOUTPUT(2) chain.</P>
	<P class=section>
	6. Two possible ways for frames/packets to pass through the <EM>iptables</EM> PREROUTING, FORWARD and POSTROUTING
	chains:</P>
	<P>
	With the br-nf patch there are 2 ways a frame/packet can pass through the 3 given <EM>iptables</EM>
	chains. The first way is when the frame is bridged, so the <EM>iptables</EM> chains are called by the bridge code.
	The second way is when the packet is routed. So special care has to be taken to distinguish between those
	two, especially in the <EM>iptables</EM> FORWARD chain. Here's an example of strange things to look out for:</P>
	<P>
	Consider the following situation (my personal setup)</P>
	<PRE>
	+-----------------+
	\| cable modem \|
	+-------+---------+
	\|
	\|
	eth0\|IP via DHCP from ISP
	+-------+---------+
	\|bridge/router/fw \|
	+--+-----------+--+
	eth1\| 172.16.1.1\|eth2
	\| (br0) \|
	\| \|
	172.16.1.4\| \|172.16.1.2
	+----------+---+ +--+------------+
	\|test computer/\| \| desktop \|
	\|backup server \| +---------------+
	+--------------+</PRE>
	<P>
	With this setup I can test the bridge+ebtables+iptables code while having access to the internet from all
	three computers. The default gateway for 172.16.1.2 and 172.16.1.4 is 172.16.1.1. 172.16.1.1 is the bridge
	interface br0 with ports eth1 and eth2.</P>
	<P class=case>More details:</P>
	<P>
	The idea is that traffic between 172.16.1.4 and 172.16.2 is bridged, while the rest is routed, using
	masquerading. Here's the "script" I use at bootup for the bridge/router:</P>
	<PRE>
	iptables -t nat -A POSTROUTING -s 172.16.1.0/24 -d 172.16.1.0/24 -j ACCEPT
	iptables -t nat -A POSTROUTING -s 172.16.1.0/24 -j MASQUERADE
	insmod ebtables
	insmod ebtable_filter
	insmod ebtable_nat
	insmod ebt_nat
	insmod ebt_log
	insmod ebt_arp
	insmod ebt_ip
	insmod br_db
	brctl addbr br0
	brctl stp br0 off
	brctl addif br0 eth1
	brctl addif br0 eth2
	ifconfig eth1 0 0.0.0.0
	ifconfig eth2 0 0.0.0.0
	ifconfig br0 172.16.1.1 netmask 255.255.255.0 up
	echo '1' > /proc/sys/net/ipv4/ip_forward</PRE>
	<P>
	The catch is in the first line. Because the <EM>iptables</EM> code gets executed for both bridged packets and routed
	packets we need to make a distinction between the two. We don't really want the bridged packets to be
	masqueraded. If we omit the first line then everything will work too, but things will happen differently.
	Let's say 172.16.1.2 pings 172.16.1.4. The bridge receives the ping request and will transmit it through its eth1
	port after first masquerading the ip address. So the packet's source ip address will now be 172.16.1.1 and
	172.16.1.4 will respond to the bridge. Masquerading will change the ip destination of this response from
	172.16.1.1 to 172.16.1.4. Everything works fine. But it's better not to have this behaviour. Thus, we use the
	first line of the script to avoid this. Note that if I wanted to filter the connections to and from the
	internet, I would certainly need the first line so I don't filter the local connections as well.</P>
	<P class=section>
	7. ip DNAT in the <EM>iptables</EM> PREROUTING chain on frames/packets entering on a bridge port:</P>
	<P>Through some groovy play it is assured that (see /net/bridge/br_netfilter.c) DNAT'ed packets that after DNAT'ing
	have the same output device as the input device they came on (the logical bridge device which we like to call br0)
	will be bridged, not routed. So they will go through the <EM>ebtables</EM> FORWARD chain. All other DNAT'ed packets will be
	routed, so won't go through the <EM>ebtables</EM> FORWARD chain, will go through the <EM>ebtables</EM> INPUT chain and might go
	through the <EM>ebtables</EM> OUTPUT chain.</P>
	<P class=section>
	8. using the mac module extension for <EM>iptables</EM>:</P>
	<P>The side effect explained here occurs when the br-nf code is compiled in the kernel, the ip packet is routed and the out device
	for that packet is a logical bridge. The side effect is encountered when filtering on the mac source in the
	<EM>iptables</EM> FORWARD chains. As should be clear from earlier sections, the traversal of the <EM>iptables</EM> FORWARD chains
	is postponed until the packet is in the bridge code. This is done so one can filter on the bridge port out device. This has a
	side effect on the MAC source address, because the ip code will have changed the MAC source address to the MAC address of the bridge.
	It is therefore impossible, in the <EM>iptables</EM> FORWARD chains, to filter on the MAC source address of the computer sending
	the packet in question to the bridge/router. If you really need to filter on this MAC source address, you should do it in the nat
	PREROUTING chain. Agreed, very ugly, but making it possible to filter on the real MAC source address in the FORWARD chains would
	involve a very dirty hack and is probably not worth it.</P>
	<P>
	Released under the GPL.</P>
	<P>
	Bart De Schuymer.</P>
	<P>
	Last updated June 2nd, 2002.</P>
	</BODY></HTML>