|
||||||||
Il 07/09/2011 22:32, Joey Morin ha scritto: > On Wed, Sep 7, 2011 at 11:53 AM, Tonix (Antonio Nati) > <tonix at interazioni dot it>wrote: > >> With this small change manageability would become fantastic for ISP >> environments. >> Rules would be much less, and general speed of monowall would be better. >> > while i agree that this kind of feature would be much easier to manage and > maintain (especially in a situation with soooo many interfaces), it's > unlikely that it would improve performance. i suspect that the > configuration feature you seek would still need to generate individual rules > for each interface, either at configuration time or dynamically at run time. > Why? Practically speaking instead of several "pass in" pass in on eth0 proto tcp from any to 100.100.100.100 pass in on eth1 proto tcp from any to 100.100.100.100 pass in on eth2 proto tcp from any to 100.100.100.100 pass in on eth3 proto tcp from any to 100.100.100.100 ............................... pass in on ethN proto tcp from any to 100.100.100.100 it would become simply pass out on eth5 proto tcp from any to 100.100.100.100 This "pass out" rules eliminatex all N rules needed for every incoming interface. So, I feel handling of a rules table 20 times smaller would help a lot rules checking performance. But that would a a side effect. Main effect is real manageability. In complex situations like mine, actual monowall behaviours are hard to manage. Basically, it is a question of prospective. As normal user or end user actual behaviour is fine. As ISP, managing dozens of vlans, actual behaviour is hard to use, hard to mantain, hard to check. Using output rules would help extremely and would semplify security schemas. Regards, Tonino > jj > -- ------------------------------------------------------------ Inter@zioni Interazioni di Antonio Nati http://www.interazioni.it tonix at interazioni dot it ------------------------------------------------------------ |