Dear Tom: I have assigned an IP to the bridge so that I can ssh into the box for configuring the box. I tested which tables/chains get activated by giving a simple rule to block port 21 on the INPUT chain of the internal LAN interface. The iptable rule set showed the rule but it had no effect. I moved it to the output and still the same effect. I moved it to the forward table and it worked.
It is based on this experimentation that I've said that it works only on the forward chain. The bridging folks are writing (have written) a utility called ebtables which has the king of filtering that iptables provides but on the bridge interface instead of the standard eth'n' interface. Let me confess, I'm know very little as compared to most on this development list on this subject from an internals/kernel/userland point of view. I'm talking from an implementation viewpoint. I'd like comments/ feedback on whether what I've tried is Ok or do I need to try something else. Mohan -----Original Message----- From: Tom Eastep [mailto:[EMAIL PROTECTED] Sent: 27 February 2003 10:26 To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [leaf-devel] FW: TC control & bandwith management using LEAF --On Thursday, February 27, 2003 08:12:45 AM +0530 S Mohan <[EMAIL PROTECTED]> wrote: > Can I have comments on this doc please? I could have written qos-htb but > would have duplicated Juan Prieto's effort. Ideally this should be > followed by the qos-htb doc. Excuse blunders if any. Would be happy to > learn where I've gone wrong or made mistakes. > > Would like Tom or Jacques to comment on how Shorewall can be used here > only on the FORWARD table? Would also like some one to ratify cable > connections - crossed and straight for combination of devices. > Provided that you assign an IP address to the bridge device, you can still have traffic to/from the $FW zone (I'm assuming that traffic would be through the br0 device - I haven't personally experimented with the bridge code). I would think that such traffic would still use the INPUT and OUTPUT chains. You should be able to do pretty much anything else supported by Shorewall except for using those features that require the interface involved to have an IP address. With the exception of obvious things like masquerading, those features are usually denoted in the documentation by the requirement that the interface must be up before Shorewall starts. Shorewall will generate rules for the INPUT and OUTPUT chains through the bridged ethernet devices but I wouldn't think that such rules would hurt anything; they just would never be exercised. If it turns out that there are problems with those rules, we can create a 'bridged' interface option that suppresses them. I'll be happy to work with someone who is experimenting with bridging and Shorewall. It's something I've wanted to do myself but simply haven't found the time. -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://www.shorewall.net Washington USA \ [EMAIL PROTECTED] ------------------------------------------------------- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp _______________________________________________ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
