[leaf-devel] Bridging and Shorewall

[S M. <sm...@vs...>]

I'm opening a new thread as the subject n earlier mails are misleading and
so would the threading.

Tom and other members:

I'm in a preliminary stage of research. The following scenarios are
emerging.

1. ebtables syntax looks mighty similar to iptables. Plain substitution may
be possible. Need to verify that functionality is identical even though
syntax may be.
2. ebtables has a facility to pass on all IP packets to layer 3 for IP
routing and bridge all other protocols.

I guess in the second scenario, shorewall can be used. I also understand
kernel 2.5 has a match called physdev which could match based on physical
interface even though packet comes from a logical interface like br0.

<snip>
http://users.pandora.be/bart.de.schuymer/ebtables/examples.html extract:

Making a brouter:

Here is an example setup for a brouter with following situation: br0 with
ports eth0 and eth1

ifconfig br0 0.0.0.0
ifconfig eth0 172.16.1.1 netmask 255.255.255.0
ifconfig eth1 172.16.2.1 netmask 255.255.255.0
ebtables -t broute -A BROUTING -p ipv4 -i eth0 --ip-dst 172.16.1.1 -j DROP
ebtables -t broute -A BROUTING -p ipv4 -i eth1 --ip-dst 172.16.2.1 -j DROP
ebtables -t broute -A BROUTING -p arp -i eth0 -d $MAC_OF_ETH0 -j DROP
ebtables -t broute -A BROUTING -p arp -i eth1 -d $MAC_OF_ETH1 -j DROP


As mentioned in the man pages, the DROP target in the BROUTING chain
actually tells the network code to route the frame instead of bridging it.

The first two ebtables commands are easy to explain: they make sure the IP
packets that must be routed enter the IP routing code through the eth0
(resp. eth1) device, not throught the br0 device.
The last two commands are needed for a subtle reason. When the brouter sends
an ARP request for, let's say 172.16.1.5, this request is sent through the
eth0 device. Without the third ebtables rule, the ARP reply would arrive on
the br0 device instead of the eth0 device, as far as the ARP code can tell.
This reply is discarded. Using the third rule, the reply arrives on the eth0
device and the ARP code is happy. So the last 2 rules are needed to make the
ARP code use the ARP replies. Without the third rule, the brouter will not
send IP packets to 172.16.1.5 (unless it already knew the MAC address of
172.16.1.5 and therefore didn't send an ARP request in the first place).

Using the redirect target:

Here is a simple example that will make all IP traffic entering a
(forwarding) bridge port be routed instead of bridged (suppose eth0 is a
port of the bridge br0):

ebtables -t broute -A BROUTING -i eth0 -p ipv4 -j redirect --redirect-target
DROP

As mentioned in the man pages, the DROP target in the BROUTING chain
actually tells the network code to route the frame. The redirect target will
trick the routing code to think the packet was originally destined for the
box.

Using the following rule has a similar effect:

ebtables -t nat -A PREROUTING --logical-in br0 -p ipv4 -j
redirect --redirect-target ACCEPT

The difference is that in the second case the IP code and routing code will
think the IP packet entered through the br0 device. In the first case the IP
code and routing code will think the IP packet entered through the eth0
device. It depends on the situation in which chain to use the redirect
target.

</snip>

--On Thursday, February 27, 2003 08:08:36 PM +0530 S Mohan
<sm...@vs...> wrote:

> Yes I did try directions also. No luck. Jaime (LinCE) also seems to have
> checked this out and had the same result.
>

So in other words, iptables support for a bridge is pretty weak, even with
the relevant patches applied... Filtering can be by source and destination
IP address and by protocol/port. And only for traffic THROUGH the bridge.

Doesn't seem like Shorewall is a very good fit...

-Tom

Bye
Mohan