[skipping over things I have no opinion on or answer for] On 7/2/2012 8:29 AM, tibz wrote: > - Zone-based FW, to replace the current "incoming interface based" > system. Or to get the choice between both at the beginning. > This is mainly to ease the maintenance. Say I've 8 interfaces/vlans, and > 1 is a guest that should only get Internet access. Then I've to create 7 > drop rules on this interface to say "to int1_subnet" > block, "to > int2_subnet > block", etc until I can safely have a "to any" > pass > rule. I can perhaps workaround this by putting some rules in the > floating tab, but if I start using it, I must keep in mind that for any > interface, there might also be rules for it in the floating tab.
Just as with a zone switch you'd have to remember the differences there... Floating rules can let you effectively have this, when paired with aliases. Just make aliases that contain the addresses for your "zones" and apply them as you like quick in/out on any interface. Might be a bit of a performance hit but no reason that wouldn't technically work. > - Better logging: I believe it has been discussed numerous of time and I > might have not found the final answer on "why it's not possible to log > locally". If you run the nano version on a flash card, OK. But if you > run it on a traditional hard drive, I see no reason why you could not > keep more logs on the box, with rotation every day/week and to have a > search module. (I'm not talking about best practice to export logs, etc, > just technically, why couldnt we do local?) On 2.0.2 and 2.1 we don't wipe the logs on reboot anymore, and the log sizes have been bumped up a bit. Still some work to be done there, but really that is best left to a remote syslog box. I don't see us switching away from the clog format, and if you want rotation you'd need "regular" files + newsyslog or similar. No reason it couldn't technically be done, it's just a fair amount of work for little benefit. If the code were to appear, or a customer funded the feature, I'm sure it would be doable. > - Integrate packages: while the packages system is a good idea to get > extra functionnalities, i'm always hesitating whether to use it or not. > There are several reason, like the fact that many packages are marked as > ALPHA/BETA (which should means not production proof), or the fact that > they are not maintained by pfSense's people (which means they could [i'm > only guessing here] be broken during an upgrade, or commercial support > wont cover issue you get with extra packages [guessing again]). That's > why having most used (ie: Squid/Snort) integrated right into pfSense > would be more comfortable. No, that'll never happen. Bloating the system is never the correct answer. :-) The best you can hope for (and something we've tried to do) is make a distinction in the package list between packages that we support and packages that we do not. If anything we'd like to go the other way and split more things off into packages so there could be an optional stripped-down no-frills bare-bones install. The packages wouldn't magically get out of beta status just because they were integrated, but then again those labels are wildly inaccurate in the package system. Some of them are extremely stable but still listed as beta because they may be lacking features and not stability (or perhaps the maintainer just forgot to update it...). That whole area could use some cleanup. Jim _______________________________________________ List mailing list [email protected] http://lists.pfsense.org/mailman/listinfo/list
