Andrew Suffield wrote: > On Tue, Nov 14, 2006 at 06:11:48PM -0800, Tom Eastep wrote:
>> I've attached an updated configuration which is similar. It requires >> that you manually configure the broadcast addresses in the interfaces >> file (I've just put "-") but it compiles on my not-so-new laptop in 10 >> seconds. > > Now here's an interesting idea. I didn't consider merging the zones > like this because the individual interfaces aren't supposed to be able > to send anything to each other (to prevent Windows worms from > spreading between them) or use the wrong IP addresses (for > accounting), but so long as routefilter is set and routeback isn't I > think this is still correct, and I can still add individual rules for > each interface by using "afl:eth2.35" or "wfl:10.1.5.0/24" in the > rules file. I'll have to play with it next time I'm at that site, and > see if this works as I expect. It should. > > Until I saw this, I hadn't realised that zones were both expensive and > unnecessary here. I guess the performance issues arise from using > large numbers of zones, because you get N*N possible chains with N > zones. Shorewall's performance is O(n * n) where n = number of networks. Each entry in /etc/shorewall/interfaces that specifies a zone in the ZONE column and each entry in /etc/shorewall/hosts is one network. The essential realisation is that zones aren't discrete regions > of the network, like a subnet, they're discrete *behaviours* within > the network - and although all the afl and wfl subnets are firewalled > off from each other, they all behave more or less the same > way. Obvious, but only with hindsight. The documentation could > probably be better at explaining this. I don't think it's really > discussed anywhere, and all the examples (especially the pictures) > suggest that zones reflect the structure of the network. You are welcome to join the Shorewall documentation team. > > It also gives me another idea... maybe I can use ipsets to trim the > number of duplicate rules, so the config isn't quite so eye-watering. Excellent idea. > >> ############################################################################### >> #ZONE HOST(S) OPTIONS >> wfl eth2.102:0.0.0.0/0 > > I'll have to change that to use ranges, but that shouldn't be a > problem. > >> ############################################################################### >> #ZONE INTERFACE BROADCAST OPTIONS >> afl eth2.3+ - dhcp >> afl eth2.4+ - dhcp > > I presume it won't matter if I have to list the interfaces in full, > instead of using wildcards. Wrong!!! See above. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ [EMAIL PROTECTED] PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
