Il 02/07/2012 14:29, tibz ha scritto:
On 1/7/2012 5:47 PM, Eugen Leitl wrote:
Are there any JunOS features you consider killer that
are not in pfSense 2.1? What would be these features?
Thanks.
A couple of features that pfSense is lacking according to me (not only
compared to SRX/JunOS though):
- 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.
I've suggested (both for pfSense and Monowall) to give the possibility
to invert the filtering directions.
In complex environment, it would be a lot more useful to apply filters
to outgoing interfaces (instead of incoming interfaces).
In this way you write only one statement and only for the interface
which is managing the output zone.
If this basic system setting (apply filters to incoming or outgoing
interfaces) could be modified, I'm sure all ISP will apply filters to
outgoing interfaces.
With output filters, interface management could also be allowed per
user, as it would not interphere with other interfaces.
Tonino
- 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?)
- 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.
- Identity-based FW, to have in addition to the source IP, the source
User/Group. There are several ways to implement this, agent-based or
agentless, transparent or explicit. The final objective is of course
to get it working in a Windows Active Directory domain.
- Real application awareness. I know there are some L7 capabilities
under Traffic Shapper (btw I wonder why it's located there), but as
far as i've seen, it's quite limited and it allow only to block (when
it works) and not to allow.
>> These 2 are big "must have" in today's firewalling (it's not my
personnal opinion, it's just a fact) so I believe pfSense must
definitely get into it.
And what has been said (CLI, commit, ...) in the other answers as well.
Appart from that, pfSense is a great piece of software which a rich
set of features and is clearly the best free/open-source FW appliance
i've used/tested by now.
Keep up good work.
_______________________________________________
List mailing list
List@lists.pfsense.org
http://lists.pfsense.org/mailman/listinfo/list
--
------------------------------------------------------------
Inter@zioni Interazioni di Antonio Nati
http://www.interazioni.it to...@interazioni.it
------------------------------------------------------------
_______________________________________________
List mailing list
List@lists.pfsense.org
http://lists.pfsense.org/mailman/listinfo/list
