On Tue, Nov 14, 2006 at 06:11:48PM -0800, Tom Eastep wrote: > Andrew Suffield wrote: > > > > > So it seems like there's two ways to tackle this problem. The first is > > to dramatically reduce the number of iptables rules used by the > > firewall by restructuring it differently - I'm not sure if this is > > possible, so I'm attaching the relevant parts of one of them in case > > anybody has any ideas (the other is much the same, only bigger) > > 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. 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. 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. 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. > ############################################################################### > #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. Next year I'm going to have to build one of these things with about 150 interfaces so it'll probably get rather cluttered. In case anybody was wondering *why* I have so many interfaces on a firewall, it's sheltered housing - one interface goes into each flat or office, and some service management stuff runs over it as well as internet access for the residents, so no flat can be allowed to interfere with the operation of another. We don't need to worry about malicious behaviour from the residents, but we have to assume unsecured wireless access points could be connected anywhere, and they should only be able to break their own flat. The actual bandwidth load is too light to justify the expense of a switch that's smart enough to do all this filtering itself. A less-smart switch that can do 802.1q but no routing or filtering, combined with a small server running shorewall, gets the job done at a fraction of the cost. ------------------------------------------------------------------------- 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
