Re: [pfSense] pfSense Setup - Slow GUI & DNS?
Just an update to the list for the archives: The Internet connection finally came in, and even with DNS reachability, the GUI was still massively slow. After lots of troubleshooting, it turned out to be exhausted MBUF's on the system. The default values were not sufficient, and that's what was causing slowness of the GUI. I increased the MBUF's significantly (46GB of RAM in these boxes), and all was right. In all fairness, I didn't go back to testing GUI response without a DNS entry or no Internet connectivity, but solving that MBUF issue was worth it. Mark. signature.asc Description: This is a digitally signed message part. ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] pfSense vs JunOS
Il 02/07/2012 15:51, Giles Coochey ha scritto: On 02/07/2012 14:37, Tonix (Antonio Nati) wrote: I would be not so sure about that. When I gave an inside look at PF, some years ago, I had the perception filters are evaluated all together in the same place, despite they are ingoing or outgoing. You can even mix incomin and outgoing interfaces in the filter flow you design. As far as I remember PF does let you specify INPUT or OUTPUT interface, but not INPUT and OUTPUT. That would be some feat indeed... the output interface isn't known until the packet has been routed.:-) It would be nice to know how pfsense acts now on that. Anyway, I don't feel DoA can be a problem, since connection could be saturated much before than CPU on the most connections. Regards, Tonino -- Regards, Giles Coochey, CCNA, CCNAS NetSecSpec Ltd +44 (0) 7983 877438 http://www.coochey.net http://www.netsecspec.co.uk gi...@coochey.net ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list -- Inter@zioniInterazioni di Antonio Nati http://www.interazioni.it to...@interazioni.it ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] pfSense vs JunOS
On 7/2/2012 11:42 AM, tibir wrote: > I was referring to adding feature. You already have a lot of packages, > or lets call them services that are "integrated" into pfSense. (so they > are part of the basic, like openvpn, dhcp server, ...)There could have > been a DHCP Server package to add, but instead you integrated it > directly. I've spoken about Squid or Snort but that doesnt means "I > would like you to integrated these packages as-is". I meant "I would > like you to intergate a HTTP Proxy and an IDS/IPS function". Then > whatever the software you plan to use or the way you > install/pre-configure it, I just need to care about what it does and > which options are offered to me through the GUI. > Hopefully you understand the shade between both approach. > I know large network tend to keep things separated (and I do agree with > that), but for SOHO or SMB, that's not always feasable. Moreover like > you said the status of packages is not really accurate and we dont > really know whether they are maintained or not. The things in the base system are there because they are a good compromise between features and stability. They don't change much, and they provide a service everyone wants. Things like snort, squid, etc are very much a moving target and would need near-constant updates that would require firmware updates if they were in the base system, or a complete redesign of the update system to handle. Plus pulling them in would vastly increase the workload on us, the build system, etc, etc. It's just not worth it on -any- level. Packages are where those things belong. > I you really dont want put more into pfSense, I believe the option to > have the "official/supported" packages list separated from the > "unofficial/unsupported" ones, right from the Packages Installer menu, > would be a good option. I'm not sure if they will get separate tabs, but there will eventually be some notation on the page to distinguish them. For the most part we try to support even more packages than we claim as maintainers, but of course we can't do them all perfectly. Sometimes we can at least test/confirm issues and act as a liaison to the actual maintainer where possible. > Btw no comment about identity-based and application awareness, shall I > understand it's on the way ? ;-) Or that it's being ignored entirely as not feasible/desirable. :-) Jim ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] pfSense vs JunOS
On 2/07/2012 15:39, Chris Bagnall wrote: On 2/7/12 2:31 pm, Jim Pingle wrote: No, that'll never happen. Bloating the system is never the correct answer. +1. I couldn't agree more. Kind regards, Chris Well I was not expecting you to take the current package directly in the installer and say it's integrated. I was referring to adding feature. You already have a lot of packages, or lets call them services that are "integrated" into pfSense. (so they are part of the basic, like openvpn, dhcp server, ...)There could have been a DHCP Server package to add, but instead you integrated it directly. I've spoken about Squid or Snort but that doesnt means "I would like you to integrated these packages as-is". I meant "I would like you to intergate a HTTP Proxy and an IDS/IPS function". Then whatever the software you plan to use or the way you install/pre-configure it, I just need to care about what it does and which options are offered to me through the GUI. Hopefully you understand the shade between both approach. I know large network tend to keep things separated (and I do agree with that), but for SOHO or SMB, that's not always feasable. Moreover like you said the status of packages is not really accurate and we dont really know whether they are maintained or not. I you really dont want put more into pfSense, I believe the option to have the "official/supported" packages list separated from the "unofficial/unsupported" ones, right from the Packages Installer menu, would be a good option. Btw no comment about identity-based and application awareness, shall I understand it's on the way ? ;-) Cheers, tibz ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] pfSense vs JunOS
On Mon, Jul 02, 2012 at 01:01:47PM +0100, Chris Bagnall wrote: > On 1/7/12 4: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? > > 'JunOS' is a fairly vague comparison point - the JunOS feature set > supported by the big Juniper routers is somewhat different from that > supported by the little SOHO firewalls. These would be ScreenOS, and aren't these EOLed? > As a routing platform - the big difference (in my experience) has been > in BGP. Whilst pfSense does have an OpenBGP package, I've not heard too > many people using it in anger with full routing tables for considerable > traffic volumes (i.e. >1Gbps). By contrast, that's fairly standard for > all but the very bottom J-series boxes (and even the very bottom J2320 > will do 400Mbps). > > Actually, BGP on pfSense is an area I'd really like to learn more about > from people using it in anger - I can think of quite a few sites with > ageing J-series and Quagga boxes that I'd love to replace with pfSense > at some point - if pfSense proves appropriate. I would be also quite interested in hearing more about such power uses of pfSense. > As a firewall I can't really comment - I've no real experience with the > smaller Juniper SOHO boxes. I've picked up a free Netscreen 5GT (which is ScreenOS) a few days ago and it's pretty rudimentary. I think the cheapest JunOS devices are SRX100 and higher. Apparently the first useful product line is SRX210. The hardware doesn't seem half bad for the base license price, though probably still doesn't have an ASIC. ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] pfSense vs JunOS
2012/7/1 Eugen Leitl > > Are there any JunOS features you consider killer that > are not in pfSense 2.1? What would be these features? > > Thanks. > ___ > List mailing list > List@lists.pfsense.org > http://lists.pfsense.org/mailman/listinfo/list > Hi Eugen, Hi @List, my ideas/wishes aren't related to JunOS. :-) No killer features found in JunOS. May be the Box itself? How heavy is that thing? if i would throw it after one or smash it against the wall? :-) = iirc we have the common deployment(XML-RPC) inklusive and exclusive for nearly any setting. Since R1.0 or so. Perfect for different Locations with same settings or just slightly different rules/settings. Now over the time i stumbled over the fact that i need sometimes all slightly different firewalls to manage at the same time. At this time i work either with different browser tabs or windows or even with different browsers. The time goes on and everything seems to get into a "grid mode" or "cloud mode". So i would find it very practical if we can get a layer on top in the WebConfigurator to say: Hey thats my master firewall and from there i like to manage all the different locations that i have put in the game. (p.e.) __ [your preferred webbrowser] __ | [link]pfsense.org[/link] | [link]gate.huston.rescueme.com[/link] | gate.idaho.rescueme.com | gate.utah.rescueme.com | |___ | | configuration page rules for gate,huston.rescueme.com | (just like the well known and proved Webconfigurator) Means i add the XML-RPC-Data to one or two boxes and add the "slave/descendent/dependent" Host to that boxes as "configurator" for the added ones. Than i can easily remember which boxes have different rules and can manage them from the same boxes from that i spread the common stuff. Also a very nice feature if you use the pfSense with Carp as redundant Firewalls. Both Master and Slave on one pane/in one frame. no idea if this is a great idea, just i know it would help me, cannot speak in common sense here. :-) = Can we combine UDP-speaking and TCP-speaking Apps in the Aliases as Ports? Means alias: common-web: 21(tcp),22(tcp),(25)tcp)(53(udp),110(tcp),500(udp) so we will end up in one single alias + rule for this? i have to admit its a bit time gone as i would use such a combination. it ended up in 1:n aliases and 1:n corresponding rules. 1:n -> TCP (1), UDP (n=1;n+1), AH(n=2;n+1); ESP(n=3;n+1) -> in this expample at least 4 aliases and 4 rules = On the end of the package extensions i would warmly welcome a package that delivers features like dropbox. User management should already be functional - afaik. ( not sure if it would already exist such a package, i have not seen it or it is still unknown to me) even if i say, such a "shit" ( imho in context of firewall and security; dropbox itself: great) has nothing to search on a firewall, customers cy for it for easy exchange of data. = some thoughts: All that are just ideas. i love pfSense and i can just get together with others and say: pfSense is (one of) the greatest/best firewalls that you can get for free witjh a full commercial support. So what you need more? i do not see any point, different to performance, why customers or imself should spend just one cent to commercial firewalls like nokia, junos or how they all are called. Spent the money to pfsense. They will make it better if they have the same scope of action. -- if one has no idea about TCP/IP, Firewalling, Protocols, DMZ and so on... he should learn it or (learn to) keep the fingers off the knobs. I wouldn't made a surgery at my neighboors hand even if i own a sterile Scalpell. :-) Also in regard to the shell access (ICAS). if one isn't able to secure up the shell access of any system he shouldn't manage a firewall. :-) If one loves roasted chickens: much fun by KFC. Just my Opinion. if the admin is experienced and knows his shit, he can do what he likes with it or he surely knows how to do that with this or that he has to get something else to get made what he wants to be done. So we speak at that point about personal prefers or about time consuming things. if two firewalls are at the same speed and have nearly the same features so the personal taste will made the choice. -- pfSense a very good choice. ;-) greetings michael -- = = = http://michael-schuh.net/ = = = Projektmanagement - IT-Consulting - Professional Services IT Michael Schuh Postfach 10 21 52 66021 Saarbrücken phone: 0681/8319664 mobil: 0175/5616453 @: m i c h a e l . s c h u h @ g m a i l . c o m = = = Ust-ID: DE251072318 = = = ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] pfSense vs JunOS
On 02/07/2012 14:37, Tonix (Antonio Nati) wrote: I would be not so sure about that. When I gave an inside look at PF, some years ago, I had the perception filters are evaluated all together in the same place, despite they are ingoing or outgoing. You can even mix incomin and outgoing interfaces in the filter flow you design. As far as I remember PF does let you specify INPUT or OUTPUT interface, but not INPUT and OUTPUT. That would be some feat indeed... the output interface isn't known until the packet has been routed.:-) -- Regards, Giles Coochey, CCNA, CCNAS NetSecSpec Ltd +44 (0) 7983 877438 http://www.coochey.net http://www.netsecspec.co.uk gi...@coochey.net smime.p7s Description: S/MIME Cryptographic Signature ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] pfSense vs JunOS
On 7/2/2012 9:38 AM, Tonix (Antonio Nati) wrote: > Too much confusion in keeping filters tables, Switching how the entire firewall operates is also very confusing and not likely to do what people expect -- floating rules would be much easier to understand than you expect (if the list were cleaned up a bit) > and no possibility to let a user to manage his/her interface. That's not even possible now, and would be just as difficult/easy to implement on the floating tab as any other. (If a user can only see interface X, only show the rules for interface X, done.) Jim ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] pfSense vs JunOS
On 2/7/12 2:31 pm, Jim Pingle wrote: No, that'll never happen. Bloating the system is never the correct answer. +1. I couldn't agree more. Kind regards, Chris -- This email is made from 100% recycled electrons ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] pfSense vs JunOS
Il 02/07/2012 15:32, Jim Pingle ha scritto: On 7/2/2012 8:41 AM, Tonix (Antonio Nati) wrote: I've suggested (both for pfSense and Monowall) to give the possibility to invert the filtering directions. Which you can do on floating rules. You can make floating rules in the 'out' direction. No need to alter the rest of the interface or make any sweeping changes, just put your rules on the floating tab. Too much confusion in keeping filters tables, and no possibility to let a user to manage his/her interface. Tonino Jim ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list -- Inter@zioniInterazioni di Antonio Nati http://www.interazioni.it to...@interazioni.it ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] pfSense vs JunOS
Il 02/07/2012 15:00, Giles Coochey ha scritto: On 02/07/2012 13:41, Tonix (Antonio Nati) wrote: 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. In some environments this might cause a performance issue and perhaps easier to DoS In an outbound filtering scenario: If you think about it, the firewall looks at the packet, processes it (NATs & routes it appropriately etc...) then when it goes to transmit the packet only then does it check the outbound ruleset and makes the decision to drop the packet - but it already wasted quite a few CPU loops before deciding to drop the packet. In an inbound filtering scenario the packet is dropped or accepted prior to any of routing, NAT etc... and a lot fewer CPU instructions are wasted. Just a thought? I would be not so sure about that. When I gave an inside look at PF, some years ago, I had the perception filters are evaluated all together in the same place, despite they are ingoing or outgoing. You can even mix incomin and outgoing interfaces in the filter flow you design. As far as I remember PF does let you specify INPUT or OUTPUT interface, but not INPUT and OUTPUT. Tonino ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list -- Inter@zioniInterazioni di Antonio Nati http://www.interazioni.it to...@interazioni.it ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] pfSense vs JunOS
OpenBGP works. Its configuration is somewhat easier than the equivalent IOS or JunOS config, IMHO. Takes a while to get used to it. There are several people on this list running multiple full takes with it. I've only used it with ~300k routes. -Adam Chris Bagnall wrote: >On 1/7/12 4: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? > >'JunOS' is a fairly vague comparison point - the JunOS feature set >supported by the big Juniper routers is somewhat different from that >supported by the little SOHO firewalls. > >As a routing platform - the big difference (in my experience) has been >in BGP. Whilst pfSense does have an OpenBGP package, I've not heard too >many people using it in anger with full routing tables for considerable >traffic volumes (i.e. >1Gbps). By contrast, that's fairly standard for >all but the very bottom J-series boxes (and even the very bottom J2320 >will do 400Mbps). > >Actually, BGP on pfSense is an area I'd really like to learn more about >from people using it in anger - I can think of quite a few sites with >ageing J-series and Quagga boxes that I'd love to replace with pfSense >at some point - if pfSense proves appropriate. > >As a firewall I can't really comment - I've no real experience with the >smaller Juniper SOHO boxes. > >Kind regards, > >Chris >-- >This email is made from 100% recycled electrons > >___ >List mailing list >List@lists.pfsense.org >http://lists.pfsense.org/mailman/listinfo/list > ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] pfSense vs JunOS
On 7/2/2012 8:41 AM, Tonix (Antonio Nati) wrote: > I've suggested (both for pfSense and Monowall) to give the possibility > to invert the filtering directions. Which you can do on floating rules. You can make floating rules in the 'out' direction. No need to alter the rest of the interface or make any sweeping changes, just put your rules on the floating tab. Jim ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] pfSense vs JunOS
[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 List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] pfSense vs JunOS
On 02/07/2012 13:41, Tonix (Antonio Nati) wrote: 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. In some environments this might cause a performance issue and perhaps easier to DoS In an outbound filtering scenario: If you think about it, the firewall looks at the packet, processes it (NATs & routes it appropriately etc...) then when it goes to transmit the packet only then does it check the outbound ruleset and makes the decision to drop the packet - but it already wasted quite a few CPU loops before deciding to drop the packet. In an inbound filtering scenario the packet is dropped or accepted prior to any of routing, NAT etc... and a lot fewer CPU instructions are wasted. Just a thought? -- Regards, Giles Coochey, CCNA, CCNAS NetSecSpec Ltd +44 (0) 7983 877438 http://www.coochey.net http://www.netsecspec.co.uk gi...@coochey.net smime.p7s Description: S/MIME Cryptographic Signature ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] pfSense vs JunOS
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@zioniInterazioni di Antonio Nati http://www.interazioni.it to...@interazioni.it ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] pfSense vs JunOS
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. - 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
Re: [pfSense] pfSense vs JunOS
On 1/7/12 4: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? 'JunOS' is a fairly vague comparison point - the JunOS feature set supported by the big Juniper routers is somewhat different from that supported by the little SOHO firewalls. As a routing platform - the big difference (in my experience) has been in BGP. Whilst pfSense does have an OpenBGP package, I've not heard too many people using it in anger with full routing tables for considerable traffic volumes (i.e. >1Gbps). By contrast, that's fairly standard for all but the very bottom J-series boxes (and even the very bottom J2320 will do 400Mbps). Actually, BGP on pfSense is an area I'd really like to learn more about from people using it in anger - I can think of quite a few sites with ageing J-series and Quagga boxes that I'd love to replace with pfSense at some point - if pfSense proves appropriate. As a firewall I can't really comment - I've no real experience with the smaller Juniper SOHO boxes. Kind regards, Chris -- This email is made from 100% recycled electrons ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] pfSense vs JunOS
On Sun, Jul 01, 2012 at 01:14:12PM +0200, Adam Thompson wrote: > > Are there any JunOS features you consider killer that are not in > > pfSense 2.1? What would be these features? > > Hardware offload: you can scale vertically with JunOS platforms with the > simple addition of more money, whereas an x86-style software-only system > like pfSense will always hit bottlenecks much earlier on, no matter how > much money you throw at it. IRQ Polling helps a bit, but not enough to > scale into the 10GB range IMHO. I was thinking about packet engine offloading when I wrote that. However, JunOS is also olive, and hence one could imagine using an ASIC or FPGA board to offload packet manipulation in pfSense. Presumably, such capabilities are yet rudimentary in FreeBSD, if available at all? > Also, "commit confirmed" is a REALLY, REALLY nice feature. A similar > concept could theoretically be implemented in pfSense, but that would > probably be 3.0-timeframe at best based on my knowledge of how the > webconfigurator works. (Many firewalls have similar stage/commit/rollback > functions, there are multiple ways to gain equivalent functionality.) Right, that's a very valuable feature. > Other than that... I can't think of any 'killer' features that pfSense > lacks. Depending on your environment, certification (e.g. ICSA) and tech > support may be very important. You can get tech support for pfSense, but > not with the resources of a JTAC behind it. Good luck certifying it - > it's uncertifiable by design because of the shell access and the ability > to add arbitrary packages. Certification is probably a major issue for enterprise netwonks. I've never used support for proprietary firewalls, so I don't know how pfSense's support contracts compare. I personally found them very adequate. ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
