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 <[EMAIL PROTECTED]> 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 ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
