I have a couple of firewalls that are rather complicated - one has 21 interfaces, and the other has about 50 (there''s some heavy use of 802.1q, they only have half a dozen network cards). They work okay, but - compiling the rules takes a long time even on the faster servers, and restarting shorewall-lite takes between 5 and 10 minutes (during which time, only the routestopped stuff will work). It would be nice if the compiler was faster (although the lesson here might be "don''t write complicated software in sh"), but it''s the network outage that''s the really awkward part. As far as I can tell, the main thing that slows it down there is the time taken to spawn iptables about 9000 times (estimate based on the final state, assuming one call per chain and one per rule; actual figure is probably higher). I haven''t analysed it carefully to see whether it''s the shell, the dynamic linker, or the kernel that takes most of the time, but my bet would be on the linker. 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). The other way is to modify shorewall to use a different approach to installing rules. It seems to me that iptables-restore could be (ab)used to perform batch installations of many rules at once. I think that''s either a really good idea or a really bad one, but I''m not sure which. (The config files have been minimally pruned for customer privacy reasons - mostly comments, and a few extra ACCEPT rules, nothing significant. All the files not included are the defaults.) ------------------------------------------------------------------------- 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
Andrew Suffield wrote:>I have a couple of firewalls that are rather complicated - one has 21 >interfaces, and the other has about 50 (there''s some heavy use of >802.1q, they only have half a dozen network cards). They work okay, >but - compiling the rules takes a long time even on the faster >servers, and restarting shorewall-lite takes between 5 and 10 minutes >(during which time, only the routestopped stuff will work).And I thought my 1 1/2 minutes to restart my setup with accounting rules for in and out on 254 addresses was bad ! Would it be ''less bad'' to setup routestopped to allow everything ? I know it gives people a small window to do stuff they shouldn''t - but is that better or worse than losing connectivity for 5 minutes ? ------------------------------------------------------------------------- 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
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.> The other way is to modify shorewall to use a different approach to > installing rules. It seems to me that iptables-restore could be > (ab)used to perform batch installations of many rules at once. I think > that''s either a really good idea or a really bad one, but I''m not sure > which.That change is almost as big as the change from 3.0 -> 3.2. I''ve looked at it but I''m out of energy for this type of massive change at the moment. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- 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
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.Here''s an updated rules file -- I didn''t notice the error in the prior one. This configuration compiles in 18 seconds on the same old laptop. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- 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
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/0I''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+ - dhcpI 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
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 \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- 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
On Tue, Nov 14, 2006 at 08:25:24PM -0800, Tom Eastep wrote:> > 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.> > I presume it won''t matter if I have to list the interfaces in full, > > instead of using wildcards. > > Wrong!!! See above.Ah, now that piece of information definitely should be documented somewhere, it''s not at all obvious. I''ll have to keep this in mind when designing the networks in future... but I think what I''ll want to do on the more complicated firewalls is use an ipset instead, that should solve the problem neatly.> You are welcome to join the Shorewall documentation team.I didn''t know that there was such a thing. I''m not really inclined to spend much time on documentation, but I might send a patch to fix the things I''ve spotted here... ------------------------------------------------------------------------- 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
Andrew Suffield wrote:> On Tue, Nov 14, 2006 at 08:25:24PM -0800, Tom Eastep wrote:> >> You are welcome to join the Shorewall documentation team. > > I didn''t know that there was such a thing. I''m not really inclined to > spend much time on documentation, but I might send a patch to fix the > things I''ve spotted here...You can always send patches to the Webmaster. If you are interested in getting write access to the SVN repository, also contact the webmaster. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- 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
On Wed, Nov 15, 2006 at 04:17:24AM +0000, Andrew Suffield wrote:> 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. > > I''ll have to play with it next time I''m at that site, and > see if this works as I expect.It appears to work - but takes a little over 3 minutes to compile on the server I normally use for this (1 minute user, 2 minutes system). Admittedly that server''s only got a C3 processor (poor cooling in that cupboard), but that''s still a long way from 10 seconds. I could use a faster server instead, but I have to wonder if I''m missing something. Still, it got the network downtime to a little under 1 minute (all the firewalls are C3s too), which is at least tolerable - people don''t call me and complain when I do it any more.> 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.This was a promising idea but ran into a couple of problems. My first effort got me this: Validating hosts file... ERROR: BRIDGING=Yes is needed for this zone definition: bario eth0.102:+barionets I''m not really sure why that happened, but I guess shorewall thinks this is a bridge port rather than an ipset? I backed off from using a zone, and did all the work in the rules file, which avoided the problem. However, I then discovered this: asuffield@rukia:~/shorewall/sado$ grep home firewall progress_message2 "Processing /home/asuffield/shorewall/sado/stop ..." progress_message2 "Processing /home/asuffield/shorewall/sado/stopped ..." progress_message2 "Processing /home/asuffield/shorewall/sado/params ..." progress_message2 "Processing /home/asuffield/shorewall/sado/init ..." ipset -R < /home/asuffield/shorewall/sado/ipsets progress_message2 "Processing /home/asuffield/shorewall/sado/continue ..." progress_message2 "Processing /home/asuffield/shorewall/sado/initdone ..." progress_message2 "Processing /home/asuffield/shorewall/sado/start ..." progress_message2 "Processing /home/asuffield/shorewall/sado/started ..." That would work fine if I was using shorewall directly, but I don''t think it''ll work very well with shorewall-lite. Presumably the contents of the ipsets file should be copied into the firewall script instead. ------------------------------------------------------------------------- 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
Andrew Suffield wrote:> > This was a promising idea but ran into a couple of problems. My first > effort got me this: > > Validating hosts file... > ERROR: BRIDGING=Yes is needed for this zone definition: bario eth0.102:+barionets > > I''m not really sure why that happened, but I guess shorewall thinks > this is a bridge port rather than an ipset?It''s a bug. The attached patch to /usr/share/shorewall/functions corrects the problem.> > I backed off from using a zone, and did all the work in the rules > file, which avoided the problem. However, I then discovered this: > > asuffield@rukia:~/shorewall/sado$ grep home firewall > progress_message2 "Processing /home/asuffield/shorewall/sado/stop ..." > progress_message2 "Processing /home/asuffield/shorewall/sado/stopped ..." > progress_message2 "Processing /home/asuffield/shorewall/sado/params ..." > progress_message2 "Processing /home/asuffield/shorewall/sado/init ..." > ipset -R < /home/asuffield/shorewall/sado/ipsets > progress_message2 "Processing /home/asuffield/shorewall/sado/continue ..." > progress_message2 "Processing /home/asuffield/shorewall/sado/initdone ..." > progress_message2 "Processing /home/asuffield/shorewall/sado/start ..." > progress_message2 "Processing /home/asuffield/shorewall/sado/started ..." > > That would work fine if I was using shorewall directly, but I don''t > think it''ll work very well with shorewall-lite. Presumably the > contents of the ipsets file should be copied into the firewall script > instead.If you want that behavior, then you will have to copy the contents of the ipsets file into your init script as in: ipset -R << _EOF_ <contents of ipsets> _EOF_ -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- 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
Andrew Suffield wrote:> > It appears to work - but takes a little over 3 minutes to compile on > the server I normally use for this (1 minute user, 2 minutes > system). Admittedly that server''s only got a C3 processor (poor > cooling in that cupboard), but that''s still a long way from 10 > seconds. I could use a faster server instead, but I have to wonder if > I''m missing something.I assume that you are using a light-weight shell? -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- 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
On Sat, Nov 18, 2006 at 08:39:31AM -0800, Tom Eastep wrote:> If you want that behavior, then you will have to copy the contents of the ipsets > file into your init script as in: > > ipset -R << _EOF_ > <contents of ipsets> > _EOF_Ah, I''ll do that. Still, shorewall should probably throw an error rather than generate a firewall script that can''t possibly work. ------------------------------------------------------------------------- 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
On Sat, Nov 18, 2006 at 09:44:41AM -0800, Tom Eastep wrote:> Andrew Suffield wrote: > > > > > It appears to work - but takes a little over 3 minutes to compile on > > the server I normally use for this (1 minute user, 2 minutes > > system). Admittedly that server''s only got a C3 processor (poor > > cooling in that cupboard), but that''s still a long way from 10 > > seconds. I could use a faster server instead, but I have to wonder if > > I''m missing something. > > I assume that you are using a light-weight shell?Using dash instead of bash shaves maybe 10 seconds off it - not really sure why the difference is so small, as I''d have expected more like 30 or 40 seconds, but it won''t do anything about the 2 minutes spent inside the kernel (probably fork/exec, although I haven''t measured it). ------------------------------------------------------------------------- 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
Andrew Suffield wrote:> On Sat, Nov 18, 2006 at 09:44:41AM -0800, Tom Eastep wrote: >> Andrew Suffield wrote: >> >>> It appears to work - but takes a little over 3 minutes to compile on >>> the server I normally use for this (1 minute user, 2 minutes >>> system). Admittedly that server''s only got a C3 processor (poor >>> cooling in that cupboard), but that''s still a long way from 10 >>> seconds. I could use a faster server instead, but I have to wonder if >>> I''m missing something. >> I assume that you are using a light-weight shell? > > Using dash instead of bash shaves maybe 10 seconds off it - not really > sure why the difference is so small, as I''d have expected more like 30 > or 40 seconds, but it won''t do anything about the 2 minutes spent > inside the kernel (probably fork/exec, although I haven''t measured > it).It helps must during compilation. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- 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
Andrew Suffield wrote:> On Sat, Nov 18, 2006 at 08:39:31AM -0800, Tom Eastep wrote: >> If you want that behavior, then you will have to copy the contents of the ipsets >> file into your init script as in: >> >> ipset -R << _EOF_ >> <contents of ipsets> >> _EOF_ > > Ah, I''ll do that. Still, shorewall should probably throw an error > rather than generate a firewall script that can''t possibly work.Please try the attached patch -- it moved processing of ipsets to the firewall system. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- 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
On Sat, Nov 18, 2006 at 12:23:28PM -0800, Tom Eastep wrote:> Andrew Suffield wrote: > > On Sat, Nov 18, 2006 at 08:39:31AM -0800, Tom Eastep wrote: > >> If you want that behavior, then you will have to copy the contents of the ipsets > >> file into your init script as in: > >> > >> ipset -R << _EOF_ > >> <contents of ipsets> > >> _EOF_ > > > > Ah, I''ll do that. Still, shorewall should probably throw an error > > rather than generate a firewall script that can''t possibly work. > > Please try the attached patch -- it moved processing of ipsets to the > firewall system.Oh, cool. I''ll try it next time I get a chance (probably some day this week - I''m not at that site every day, and don''t like to meddle with the firewalls over the internet). If I understand it correctly, I have to put the ipsets file into /var/lib/shorewall-lite on the target system by hand? ------------------------------------------------------------------------- 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
Andrew Suffield wrote:> On Sat, Nov 18, 2006 at 12:23:28PM -0800, Tom Eastep wrote: >> Andrew Suffield wrote: >>> On Sat, Nov 18, 2006 at 08:39:31AM -0800, Tom Eastep wrote: >>>> If you want that behavior, then you will have to copy the contents of the ipsets >>>> file into your init script as in: >>>> >>>> ipset -R << _EOF_ >>>> <contents of ipsets> >>>> _EOF_ >>> Ah, I''ll do that. Still, shorewall should probably throw an error >>> rather than generate a firewall script that can''t possibly work. >> Please try the attached patch -- it moved processing of ipsets to the >> firewall system. > > Oh, cool. I''ll try it next time I get a chance (probably some day this > week - I''m not at that site every day, and don''t like to meddle with > the firewalls over the internet). > > If I understand it correctly, I have to put the ipsets file into > /var/lib/shorewall-lite on the target system by hand?Put it in /etc/shorewall-lite/ -- you can do that on the firewall system using ipset -S > /etc/shorewall-lite/ipsets -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- 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
Andrew Suffield wrote:> On Sat, Nov 18, 2006 at 12:23:28PM -0800, Tom Eastep wrote: >> Andrew Suffield wrote: >>> On Sat, Nov 18, 2006 at 08:39:31AM -0800, Tom Eastep wrote: >>>> If you want that behavior, then you will have to copy the contents of the ipsets >>>> file into your init script as in: >>>> >>>> ipset -R << _EOF_ >>>> <contents of ipsets> >>>> _EOF_ >>> Ah, I''ll do that. Still, shorewall should probably throw an error >>> rather than generate a firewall script that can''t possibly work. >> Please try the attached patch -- it moved processing of ipsets to the >> firewall system. > > Oh, cool. I''ll try it next time I get a chance (probably some day this > week - I''m not at that site every day, and don''t like to meddle with > the firewalls over the internet). >Here is a corrected version of the patch. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- 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
On Sat, Nov 18, 2006 at 07:18:51PM +0000, Andrew Suffield wrote:> On Sat, Nov 18, 2006 at 09:44:41AM -0800, Tom Eastep wrote: > > Andrew Suffield wrote: > > > > > > > > It appears to work - but takes a little over 3 minutes to compile on > > > the server I normally use for this (1 minute user, 2 minutes > > > system). Admittedly that server''s only got a C3 processor (poor > > > cooling in that cupboard), but that''s still a long way from 10 > > > seconds. I could use a faster server instead, but I have to wonder if > > > I''m missing something. > > > > I assume that you are using a light-weight shell? > > Using dash instead of bash shaves maybe 10 seconds off it - not really > sure why the difference is so small, as I''d have expected more like 30 > or 40 seconds, but it won''t do anything about the 2 minutes spent > inside the kernel (probably fork/exec, although I haven''t measured > it).Or I''m just being an idiot. When -e <directory-name> is included, only the SHOREWALL_SHELL and VERBOSITY settings from /etc/shorewall/shorewall.conf are used and these apply only to the compiler itself. The settings used by the compiled firewall script are determined by the contents of <directory name>/shorewall.conf. Would be the appropriate realisation. I successfully managed to run /sbin/shorewall and the generated firewall script under dash, but not /usr/share/shorewall/compiler. It would probably be wise for that distinction to be noted in the template shorewall.conf, so that other absent-minded people get reminded. New time after changing that one too: real 0m45.249s user 0m11.645s sys 0m32.814s Still five times slower than your laptop... but perhaps it''s not as old as you think, and these processors really are not fast. It''s roughly equivalent to a 450MHz P3 (except with modern storage and network performance, appalling floating point performance, but vastly lower heat output - no fans on these things). Faster would be nice, but I can live with this. Time to restart shorewall-lite is still about a minute, and that''s all spent running iptables - no surprise there, and short of doing something evil with iptables-restore, I don''t expect it to change. For me at least, it''s not currently worth the effort. Might be something to think about next time the beast gets rewritten. ------------------------------------------------------------------------- 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
On Sat, Nov 18, 2006 at 02:50:15PM -0800, Tom Eastep wrote:> >> Please try the attached patch -- it moved processing of ipsets to the > >> firewall system. > > > > Oh, cool. I''ll try it next time I get a chance (probably some day this > > week - I''m not at that site every day, and don''t like to meddle with > > the firewalls over the internet). > > > > If I understand it correctly, I have to put the ipsets file into > > /var/lib/shorewall-lite on the target system by hand? > > Put it in /etc/shorewall-lite/ -- you can do that on the firewall system > using ipset -S > /etc/shorewall-lite/ipsetsFinally got around to trying it - that works much more sensibly, thanks. ------------------------------------------------------------------------- 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
Andrew Suffield wrote:> On Sat, Nov 18, 2006 at 02:50:15PM -0800, Tom Eastep wrote:>> Put it in /etc/shorewall-lite/ -- you can do that on the firewall system >> using ipset -S > /etc/shorewall-lite/ipsets > > Finally got around to trying it - that works much more sensibly, > thanks.You''re welcome. Thank you for testing. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- 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