Re: [pfSense] pfSense vs JunOS
Il 04/07/2012 15:41, Giles Coochey ha scritto: On 04/07/2012 11:06, Tonix (Antonio Nati) wrote: Il 04/07/2012 11:44, Ermal Luçi ha scritto: On Wed, Jul 4, 2012 at 10:44 AM, Tonix (Antonio Nati) wrote: Il 02/07/2012 15:51, Jim Pingle ha scritto: 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.) Would it be possible to have a technical answer about using OUTPUT interfaces rules instead of INPUT interfaces rules? What should change dramatically inside pfsense, and there is any real security reason for not doing that? As far as I can see PF filtering, both INPUT and OUTPUT interfaces rules would be evaluated in same place. Definition of same place is not correct here. While its true that all rules are in the same place(data structure), on stateful firewalls they get evaluated only once that is why it is not considered to split them out. Also there are optimizations that make this not a factor at all in evaluation of ruleset. Certainly it is recommended to kill mosquitoes before they come to you :) Though its mostly performance reasons because the packets than will consume to much CPU and open possibility of DoS. Although there is the other reason of buffer overflows and exploits. Wrongly crafted packets might crash your host or even make it vulnerable to exploits while with filtering on inbound you reduce this risk by at least making sure the sanity of network metadata(packet headers, ips, etc). Sorry, but you did not answer my question. Your comments are general security comments but do not answer to the central question. Once you have an incoming connection (first time) to, let's say from INT X to INT Y, dest IP Z, dest port P, will these alternative rules be evaluated in same moment or not? - Evaluate INPUT on INT X, dest IP Z, dest port P - Evaluate OUTPUT on INT Y, dest IP Z, dest port P If the answer is YES, there is no added security risk on preferring filering rules on OUTPUT interface. Both INPUT and OUTPUT have same risks. If the answer is NOT, please explain where and why INPUT and OUPUT are evaluated in different phases. Regards, Tonino My firewall has four interfaces. A packet arrives on one interface At this stage it is impossible for the firewall to apply a rule based on the outbound interface because which interface that is has not been evaluated yet. It is not until the packet is processed that the outbound interface is determined. It is however, able to make a decision on rules applied on the INBOUND interface, because that is a known fact. Simples. As a general rule, best practices state, that if you are going to drop / filter packets on your network, do so as close to the source as possible. This applies within systems as well as on the wire. I'd say NOT - INPUT is evaluated upon Input, OUTPUT is evaluated upon Output - my guess as the reason they decided to call them INPUT and OUTPUT. Your theory is perfect, and I agree totally with you. But reading PF manuals gave me a different vision of how PF acts. Are you sure PF acts exactly like you are explaining? Regards, 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
Il 04/07/2012 16:21, Sean Cavanaugh ha scritto: Once you have an incoming connection (first time) to, let's say from INT X to INT Y, dest IP Z, dest port P, will these alternative >rules be evaluated in same moment or not? - Evaluate INPUT on INT X, dest IP Z, dest port P - Evaluate OUTPUT on INT Y, dest IP Z, dest port P If the answer is YES, there is no added security risk on preferring filering rules on OUTPUT interface. Both INPUT and OUTPUT >have same risks. If the answer is NOT, please explain where and why INPUT and OUPUT are evaluated in different phases. Regards, Tonino For full explanation you have to understand how the filtering process occurs in entirety SOURCE---INPUT Interface -INPUT rule set -CPU based routing rule set -OUTPUT rule set OUTPUT Interface -DESTINATION The CPU based routing rule set is the area where the firewall is determining what interface to send the data out of. Even if you only have a 2 interface firewall, it will still have to evaluate where it has to go because it technically can go out either interface. People do use NAT reflection to send data from inside their networks to the firewall and bounce it back inside. Because of this they take a bit of processing power to calculate as they have to be reviewed by pretty much every rule on the box per state The interface rule sets are the most simple rules. Either traffic is allowed or not. They take very little processing power to accomplish. They act as a simple bouncer at a night club. It is because of this imbalance that it is preferred to do filtering as low as possible. For a very simplistic example, lets go for extremely inflated numbers. Let's say it takes 1% of the CPU to handle interface rules and takes 5% of the CPU for routing rules. If we went for pure routing based rules, we could only run 20 states before we are at 100% utilization and start running into contention, whereas if we went for interface rules, we could run 100 states before we hit 100%. The problem with running rule sets on the OUTPUT interface is that you MUST then use up the routing rule set resources, meaning you would run into the same 20 state limit, even for streams that would hit the OUTPUT interface and be blocked. You would then literally be wasting resources to do nothing. This is why it is preferred to make rules based on INPUT as they will use as little resources of the firewall as possible. There are times when people have no choice but to put rules on the OUTPUT interface but that should be an absolute last resort as it will cost resources. Would you rather but a soda for a dollar or run it thru exchange rates and end up paying 5 dollars for a soda? It's your call. Sometimes you're THAT thirsty. Thanks for the detailed explanation, but... There is something I don't understand. Your considerations are based on having three different steps: INPUT, routing, OUTPUT. This is possible only if you can execute PF on INPUT interfaces, then execute routing code, then execute again PF for OUTPUT interfaces. Looking at PF (Packet filter) manuals, I do not see any kind of call/ioctl like "examine only INPUT INTERFACE" or any possibility to execute PF code on only a part of filters rules. PF manual says PF evaluates every rule found in "pf.conf", and does not mention any possibility to execute only a part of rules. So, it looks like INPUT and|or OUTPUT interfaces are evaluated at same stage, probably after routing (which is not part of PF). Please let me understand better. Regards, Tonino -Sean ___ 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
> >Once you have an incoming connection (first time) to, let's say from INT X to INT Y, dest IP Z, dest port P, will these alternative >rules be evaluated in same moment or not? > >- Evaluate INPUT on INT X, dest IP Z, dest port P >- Evaluate OUTPUT on INT Y, dest IP Z, dest port P >If the answer is YES, there is no added security risk on preferring filering rules on OUTPUT interface. Both INPUT and OUTPUT >have same risks. > >If the answer is NOT, please explain where and why INPUT and OUPUT are evaluated in different phases. > >Regards, > >Tonino For full explanation you have to understand how the filtering process occurs in entirety SOURCE---INPUT Interface -INPUT rule set -CPU based routing rule set -OUTPUT rule set OUTPUT Interface -DESTINATION The CPU based routing rule set is the area where the firewall is determining what interface to send the data out of. Even if you only have a 2 interface firewall, it will still have to evaluate where it has to go because it technically can go out either interface. People do use NAT reflection to send data from inside their networks to the firewall and bounce it back inside. Because of this they take a bit of processing power to calculate as they have to be reviewed by pretty much every rule on the box per state The interface rule sets are the most simple rules. Either traffic is allowed or not. They take very little processing power to accomplish. They act as a simple bouncer at a night club. It is because of this imbalance that it is preferred to do filtering as low as possible. For a very simplistic example, lets go for extremely inflated numbers. Let's say it takes 1% of the CPU to handle interface rules and takes 5% of the CPU for routing rules. If we went for pure routing based rules, we could only run 20 states before we are at 100% utilization and start running into contention, whereas if we went for interface rules, we could run 100 states before we hit 100%. The problem with running rule sets on the OUTPUT interface is that you MUST then use up the routing rule set resources, meaning you would run into the same 20 state limit, even for streams that would hit the OUTPUT interface and be blocked. You would then literally be wasting resources to do nothing. This is why it is preferred to make rules based on INPUT as they will use as little resources of the firewall as possible. There are times when people have no choice but to put rules on the OUTPUT interface but that should be an absolute last resort as it will cost resources. Would you rather but a soda for a dollar or run it thru exchange rates and end up paying 5 dollars for a soda? It's your call. Sometimes you're THAT thirsty. -Sean ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] pfSense vs JunOS
On 04/07/2012 11:06, Tonix (Antonio Nati) wrote: Il 04/07/2012 11:44, Ermal Luçi ha scritto: On Wed, Jul 4, 2012 at 10:44 AM, Tonix (Antonio Nati) wrote: Il 02/07/2012 15:51, Jim Pingle ha scritto: 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.) Would it be possible to have a technical answer about using OUTPUT interfaces rules instead of INPUT interfaces rules? What should change dramatically inside pfsense, and there is any real security reason for not doing that? As far as I can see PF filtering, both INPUT and OUTPUT interfaces rules would be evaluated in same place. Definition of same place is not correct here. While its true that all rules are in the same place(data structure), on stateful firewalls they get evaluated only once that is why it is not considered to split them out. Also there are optimizations that make this not a factor at all in evaluation of ruleset. Certainly it is recommended to kill mosquitoes before they come to you :) Though its mostly performance reasons because the packets than will consume to much CPU and open possibility of DoS. Although there is the other reason of buffer overflows and exploits. Wrongly crafted packets might crash your host or even make it vulnerable to exploits while with filtering on inbound you reduce this risk by at least making sure the sanity of network metadata(packet headers, ips, etc). Sorry, but you did not answer my question. Your comments are general security comments but do not answer to the central question. Once you have an incoming connection (first time) to, let's say from INT X to INT Y, dest IP Z, dest port P, will these alternative rules be evaluated in same moment or not? - Evaluate INPUT on INT X, dest IP Z, dest port P - Evaluate OUTPUT on INT Y, dest IP Z, dest port P If the answer is YES, there is no added security risk on preferring filering rules on OUTPUT interface. Both INPUT and OUTPUT have same risks. If the answer is NOT, please explain where and why INPUT and OUPUT are evaluated in different phases. Regards, Tonino My firewall has four interfaces. A packet arrives on one interface At this stage it is impossible for the firewall to apply a rule based on the outbound interface because which interface that is has not been evaluated yet. It is not until the packet is processed that the outbound interface is determined. It is however, able to make a decision on rules applied on the INBOUND interface, because that is a known fact. Simples. As a general rule, best practices state, that if you are going to drop / filter packets on your network, do so as close to the source as possible. This applies within systems as well as on the wire. I'd say NOT - INPUT is evaluated upon Input, OUTPUT is evaluated upon Output - my guess as the reason they decided to call them INPUT and OUTPUT. 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
I confirm too: excellent support! Odette -- Odette Nsaka Il giorno mar, 03/07/2012 alle 15.26 -0600, James Caldwell ha scritto: > Absolutely, some of the best support I've had for a software solution to date. > > James ... ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] pfSense vs JunOS
Il 04/07/2012 11:44, Ermal Luçi ha scritto: On Wed, Jul 4, 2012 at 10:44 AM, Tonix (Antonio Nati) wrote: Il 02/07/2012 15:51, Jim Pingle ha scritto: 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.) Would it be possible to have a technical answer about using OUTPUT interfaces rules instead of INPUT interfaces rules? What should change dramatically inside pfsense, and there is any real security reason for not doing that? As far as I can see PF filtering, both INPUT and OUTPUT interfaces rules would be evaluated in same place. Definition of same place is not correct here. While its true that all rules are in the same place(data structure), on stateful firewalls they get evaluated only once that is why it is not considered to split them out. Also there are optimizations that make this not a factor at all in evaluation of ruleset. Certainly it is recommended to kill mosquitoes before they come to you :) Though its mostly performance reasons because the packets than will consume to much CPU and open possibility of DoS. Although there is the other reason of buffer overflows and exploits. Wrongly crafted packets might crash your host or even make it vulnerable to exploits while with filtering on inbound you reduce this risk by at least making sure the sanity of network metadata(packet headers, ips, etc). Sorry, but you did not answer my question. Your comments are general security comments but do not answer to the central question. Once you have an incoming connection (first time) to, let's say from INT X to INT Y, dest IP Z, dest port P, will these alternative rules be evaluated in same moment or not? - Evaluate INPUT on INT X, dest IP Z, dest port P - Evaluate OUTPUT on INT Y, dest IP Z, dest port P If the answer is YES, there is no added security risk on preferring filering rules on OUTPUT interface. Both INPUT and OUTPUT have same risks. If the answer is NOT, please explain where and why INPUT and OUPUT are evaluated in different phases. Regards, Tonino Regards, 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 ___ 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 Wed, Jul 4, 2012 at 10:44 AM, Tonix (Antonio Nati) wrote: > Il 02/07/2012 15:51, Jim Pingle ha scritto: > >> 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.) > > > Would it be possible to have a technical answer about using OUTPUT > interfaces rules instead of INPUT interfaces rules? > What should change dramatically inside pfsense, and there is any real > security reason for not doing that? > > As far as I can see PF filtering, both INPUT and OUTPUT interfaces rules > would be evaluated in same place. > Definition of same place is not correct here. While its true that all rules are in the same place(data structure), on stateful firewalls they get evaluated only once that is why it is not considered to split them out. Also there are optimizations that make this not a factor at all in evaluation of ruleset. Certainly it is recommended to kill mosquitoes before they come to you :) Though its mostly performance reasons because the packets than will consume to much CPU and open possibility of DoS. Although there is the other reason of buffer overflows and exploits. Wrongly crafted packets might crash your host or even make it vulnerable to exploits while with filtering on inbound you reduce this risk by at least making sure the sanity of network metadata(packet headers, ips, etc). > Regards, > > Tonino > > > >> Jim >> >> >> >> >> ___ >> 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 ___ 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, Jim Pingle ha scritto: 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.) Would it be possible to have a technical answer about using OUTPUT interfaces rules instead of INPUT interfaces rules? What should change dramatically inside pfsense, and there is any real security reason for not doing that? As far as I can see PF filtering, both INPUT and OUTPUT interfaces rules would be evaluated in same place. Regards, 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
Absolutely, some of the best support I've had for a software solution to date. James -Original Message- From: list-boun...@lists.pfsense.org [mailto:list-boun...@lists.pfsense.org] On Behalf Of bsd Sent: July-03-12 3:24 PM To: pfSense support and discussion Subject: Re: [pfSense] pfSense vs JunOS Le 3 juil. 2012 à 21:59, Vick Khera a écrit : > On Sun, Jul 1, 2012 at 3:33 PM, Chris Buechler wrote: > The level of service we provide is on par or better than commercial > vendors. For most of our customers, much better, because commercial > vendors will rule out the firewall and tell you to have a nice day > > I'll confirm that their support is excellent, and they stick with you until > you have a solution or figure out that there is no solution *at all*. > > I'd recommend buying it even if you don't plan to use it as a way to support > the project. I confirm this : support is awesome ! Live support is fast and efficient, supporting dev project is fun and useful for the community, It is great and I wish pfSense team all the best ! -- -> Grégory Bernard Director <- ---> www.osnet.eu <--- --> Your provider of OpenSource appliances <-- -- OSnetOSnetOSnetOSnetOSnetOSnetOSnetOSnetOSnetO ___ 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
Le 3 juil. 2012 à 21:59, Vick Khera a écrit : > On Sun, Jul 1, 2012 at 3:33 PM, Chris Buechler wrote: > The level of service we provide is on par or better than commercial > vendors. For most of our customers, much better, because commercial > vendors will rule out the firewall and tell you to have a nice day > > I'll confirm that their support is excellent, and they stick with you until > you have a solution or figure out that there is no solution *at all*. > > I'd recommend buying it even if you don't plan to use it as a way to support > the project. I confirm this : support is awesome ! Live support is fast and efficient, supporting dev project is fun and useful for the community, It is great and I wish pfSense team all the best ! –– -> Grégory Bernard Director <- ---> www.osnet.eu <--- --> Your provider of OpenSource appliances <-- –– OSnetOSnetOSnetOSnetOSnetOSnetOSnetOSnetOSnetO ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] pfSense vs JunOS
On Sun, Jul 1, 2012 at 3:33 PM, Chris Buechler wrote: > The level of service we provide is on par or better than commercial > vendors. For most of our customers, much better, because commercial > vendors will rule out the firewall and tell you to have a nice day > I'll confirm that their support is excellent, and they stick with you until you have a solution or figure out that there is no solution *at all*. I'd recommend buying it even if you don't plan to use it as a way to support the project. ___ 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
Re: [pfSense] pfSense vs JunOS
On Sun, Jul 1, 2012 at 11:47 AM, Eugen Leitl wrote: > > Are there any JunOS features you consider killer that > are not in pfSense 2.1? What would be these features? > I'll add a few things to Adam's list. The biggest in my opinion is a solid cli. The webUI is not bad in pfSense but a solid command line interface is central to so many of the really nice things about Junos. And JunOS's cli and approach to configuration in general is pretty slick. A better separation of running configuration vs current edits. In pfSense there's often times that you have to apply one set of changes before moving to another part of the interface to make additional changes to your configuration. It would be nice to be able to make any changes you need and then be able to commit check and then commit confirm them. At work we use the "show | compare" to spit out a diff between the current edits and the running configuration in order to get other people on the team a chance to comment on any changes that you're about to make. pfSense does have this feature but I'll mention it anyhow b/c we use it all the time at work and to have it integrated into a CLI is key. The rollback feature which lets you load previous configurations into the current edit config at which point you can do "show | compare" and make additional changes before running commit. We us this to turn down a BGP session with a peer who has some maintenance window. It's nice to just be able to rollback to the previous configuration very easy at the end of the maintenance window. -- David ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] pfSense vs JunOS
On Sun, Jul 1, 2012 at 7:14 AM, 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. > At the $150K+ USD firewall level, nothing can compare with commercial solutions at this time. Though finding any commercial firewall that does > 10 Gb is hard, the few that can don't go much beyond that. Generally at those traffic loads you're looking at a big router or L3 switch, which is an entirely different ball game. > 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. The level of service we provide is on par or better than commercial vendors. For most of our customers, much better, because commercial vendors will rule out the firewall and tell you to have a nice day figuring out the problem yourself. Since we strictly do hourly support, we can gladly help determine the actual source of the issue, and do what we can to help resolve it. Whether that's talking to ISPs, private WAN circuit providers, other firewall vendors at times, and a wide range of other scenarios. > Good luck certifying it - > it's uncertifiable by design because of the shell access and the ability > to add arbitrary packages. > Last I looked at the ICSA specs, the ability to modify the system would have been irrelevant. Those certifications are testing for things like "Has X functionality, and it works" on a wide range of checklist items. Nowhere do they specify that the system is impossible to modify. Granted it's easy by design, but many certified commercial firewalls aren't all that hard to get into and modify for someone with the right skills, the many based on Linux or BSD at least. The few that aren't are generally modifiable as well, just not nearly as easily. The impediment to certification is cost, it's a lot of money for something that's basically useless. ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] pfSense vs JunOS
> 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. 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.) 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. -Adam Thompson athom...@athompso.net ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
[pfSense] pfSense vs JunOS
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
