So yes, I changed jobs which is why this blog has been a little quiet.
At my new employer we are about to replace Checkpoint with a UTM solution.
While I understand that most people that read this blog work with Fortinet I'm also looking to solicit some real world feedback from anyone out there who has used both Fortinet and Palo Alto Network boxes.
I'm not looking for "Fortinet is better because PA blows", rather I'm looking for technical differences and usability nuances that would help us make an informed decision.
If you have information to help out do please post a comment.
Thanks everyone for reading!
Hi Sebastian
ReplyDeleteHappy to talk about it over email, have baked off an made both vendors and made them bleed with Breakingpoint in a past life.
Greg
I think that, although Fortinet would prefer not to make a distinction, there is truly a difference between UTM and a NGFW.
ReplyDeleteA Fortinet box runs a bunch of technologies... Sure it does firewall, IPS, and URL filtering, but it can also act as a wireless controller, web app firewall, and even a WAN optimization solution. But there's really no correlation, rhyme or reason to how all these technologies work together. They just happen to all services running on the same piece of hardware.
PAN doesn't just throw stuff on their box for the hell of it. Everything is tightly integrated and each function is correlated with the other functions...
Run an incident analysis on a PAN, then try to do it on a Fortinet. You will see the difference. It's apples to oranges.
Fortinet is a UTM, Firewall-IPS-WebFiltering-antiSpam, Antivirus-Wireless Lan controller-LoadBalancer-tokenAuth, every application is verified (ICSA-FIPs-EAL,etc), works fine, very fine. But every application works in proxy mode(flow mode also), thats means packet have to travel every app for complete content inspection (thats mean losing speed throughput when enable all the apps). But Fortinet have throughput excess, i tested Fortigate less 1K$ working as Firewall NextGen $10K.
ReplyDeleteI love fortinet we have appliances working from 5 to 5000 users very well, integrated with AD, LDAP, Radius.
PaloAlto is a NGFW, parallel procesing packet, thats mean one or two processing packet steps.
If you review Network World test, the NGFW had the same issue that UTM, when enable UTM, IPS, Web content, SSL decrypt, the throughtput goes from 99% to 1%.
I believe that UTM is the right Way, NGFW is highest price and near functionality.
This comment has been removed by the author.
ReplyDeletePlaces where Palo Alto Networks runs circles around Fortinet: GUI, on/off-box reporting/monitoring/logging, application detection, speed/performance, setup time, ease of manually editing the config file, IPS usage/detection, virtual systems, transparent mode is not all-or-nothing, and phone support is a little better.
ReplyDeletePlaces where Fortinet beats Palo Alto: the small boxes are much more affordable and ssl-vpn (even though it sucks to set up, it is more powerful).
Just my opinion, I've used both, I'm biased toward PAN. Some of the issues I've had with my Fortinet boxes have been ridiculous (losing config between an upgrade), it's left a bad taste in my mouth.
I work with both fortinet and palo alto.
ReplyDeleteFor me, the advantage of palo is visibility, reporting and user authentication. Fortinet is easier and faster to configure.
A commit on a paloalto is very long when we are used to have a direct modification of fortinet.
Virtual wire on paloalto is much more easier than transparent mode of fortinet, it's really usefull to prepare an integration or a demo in real situation and the tap mode is cool for that too.
What an useful thread. I work in a Fortinet shop, but I have looked very closely at PAN for the last few years. The app detection on the Fortinet is OK but not great.
ReplyDeletePrice has scared us away from the PAN.
I thought you would be interested in this ongoing blog post by a Fortinet and PAN vendor:
http://www.anitian.com/blog/?p=31
VERY interesting to read all comments; well, the educated, intelligent ones, at least.
ReplyDeleteI'm obviously a fan of the FGTs - I'm aware of the solutions to the "problems" many newcomers experience. I'm comfortable.
But maybe too comfortable. Though I've just introduced my new employer to Fortinet, you must always be objective in your search for proper hardware. Do your homework, cross the T's and dot your I's.
Even when not considering anything other than a FGT, I still consider other vendors - that doubt, nagging or gnawing at the back of my brain. And even when I force myself to be unbiased, the FGT line always wins. I WANT to move on; it's time - I've been with Fortinet for 8 years now. But they somehow keep winning my loyalty. And it's not with unending bugs. The Hardware is legit; it's tight. It's fast. It's pretty - LOOK! They come in WHITE now! How Apple. The point is, FGTs are just doing it and doing it and doing it well. I continue to get creative with design and implementation, and they continue to flex and perform. Unique configurations not possible with other Vendors I've worked with. They have their shortcomings in areas; ALL vendors have their shortcomings - aware or not. But which shortcomings mean nothing to you?
Stuff to watch out for (or at least keep in mind):
ReplyDelete* SSL-decryption (whitelistning).
PA uses a whitelist for certain CN so its SSL decryption wont block stuff that cannot be decrypted anyway (for example windowsupdate, which if being SSL-terminated wont function).
Current list is available at https://live.paloaltonetworks.com/docs/DOC-1423
* SSL-decryption (performance).
Previously due to the design of the PA-2000 boxes the SSL termination feature could overload the mgmtplane making bad things happen (for example wrong user being logged). This has been fixed (and is only mentioned as a historic reference).
* Commit times
Recently there are reports of commits taking as long as 20 minutes or more to complete for PA-2000 boxes. Discussions in the support forums believes this can have to do with to little RAM in the mgmtplane which makes the PA-2000 device to swap and therefor take ages to complete. As a sidenote a PA-5000 box takes roughly 5-10 seconds to commit the same ruleset (with AV, IPS etc enabled).
This is supposed to be addressed in upcoming PAN-OS 5.0 but rumours says that there will be a new device out shortly who will replace the PA-2000 series.
* Antivirus
This can be both good and bad but the AV feature in PA is streambased. Which means that there is virtually no upper size for how large the files who get scanned can be (compared to Fortigate) but at the same time not all file formats can be scanned streambased.
* Application identification
NEVER EVER use "service:any" (service is the PA name for port). Use "service:application-default" unless you can manually specify UDP/TCP and port/range your flow will use (however service:any can of course be used when you want to block traffic because you want often a block to be as wide as possible while an allow should be as narrow as possible).
continued...
ReplyDelete* Application dependencies
Some applications, for example "Facebook", have dependencies towards other applications which must also be enabled for a particular rule to function. This gives that occassionally one are forced to open a bit too much (based on content of the flow/session).
This is said to be addressed in PAN-OS 5.0 who will better merge dependencies so you from 5.0 wont need to allow "web-browsing" just because you wish to allow "Facebook". The difference will be that the upcoming "Facebook" will allow as much "web-browsing" as needed for identification - if not identified after a few packet the "web-browsing" will no longer be accepted for the particular flow/session.
There are however workarounds for this today - you can combine the AppID being used with an url-filter and/or a url-category.
* User identification
The regular method of using dedicated userid/pan-agent servers will most likely not scale that well for enterprise use. You might consider install the userid/pan-agent service on each DC and lock it to only follow the security log from localhost.
That is because the userid/ip mapping is done by tailing/following the security log (events 672, 673 and 674 for Win2003 DCs and events 4768, 4769 and 4770 for Win2008 DCs) and when a user logins to the domain only the DC who authed the user will log its presence (the security log is not replicated within the domain for some odd reason).
With a network of just 2 DCs this is not a problem (even if you have 10.000 concurrent users). But if you have lets say have 50 DCs (with 10.000 concurrent users) the math will be something like (with 2 PA devices):
- Dedicated userid/pan-agent servers (tailing security log of each DC over the network):
50 * 5Mbit/s * 2 + 2 * 0-100kbit/s ~= 500Mbit/s network load (5Mbit/s is estimated network load to follow a single DC in an environment with approx 10.000 concurrent users).
vs.
- Userid/pan-agent installed on each DC (and configured to only read the local security log):
50 * 0-100kbit/s * 2 ~= 0-10Mbit/s network load (that is each PA device (2 of them in this example) will connect directly to each DC (who runs the userid/pan-agent service)).
continued...
ReplyDelete* DEFCON19
Juniper seems to be upset at Palo Alto Networks:
www.youtube.com/watch?v=s2cz--bzZRE
DEFCON 19: Network Application Firewalls: Exploits and Defense
http://www.youtube.com/watch?v=G8U-1J4SI4o
DEFCON 19: Network Application Firewalls: Exploits and Defense ( w speaker)
I have got a response from a Sales Engineer at PaloAlto for the above statements which Juniper made but I dont know if I can publish those in public (I will notify this SE about this post so he can post on his own).
* Unhappy user at Cisco forum
An unhappy user who was disappointed at PA published his/her thoughts on Cisco Forum:
https://supportforums.cisco.com/thread/2011246
Response from PA regarding mentioned cases is:
"
I think that this particular customer has had many interactions with our support and has unfortunately found some bugs that required changes that were too large to put in a maintenence release. This was the root cause of the long closure times.
15350 - solved within 60min
21993 - solved within 60min
30788 - Worked with the customer, did debugging sessions with engineers on their system and made a fix that could not be back ported and required an upgrade so it took a while to close the case.
22967 - solved within 90min
23047 - This case required engineering to debug on their device as well and led to a fix that could not be back ported, and therefore the customer had to upgrade for the fix.
32874 - This was a complicated case that had over 100 comments (between support and the customer) on the case over a period of months with much engineering interaction an eventual bug fix that again was too large to put in a maintence release
"
continued...
ReplyDelete* Performance worries
Found at the PA forums:
"
Perfomance on PA 4060 - Huge Disappointment:
We are having a poc at an ISP with a 4060 . It is a huge disppointment performance wise . We are seeing very high dataplane utilization on very small sessions. 50% on 220,000 sessions. 38% on 149,000 sessions. This is a box that is supposedly can handle 2M sessions.
Palo Alto is claiming there is nothing wrong with the unit as it is performing as expected based on the traffic . I thought PAN isn't a UTM . It is looking more like one to me.
"
reply to the above (from another customer):
"
The utilization on its own is pretty much couldnt care less since you will have the virtually the same latency with one packet vs 100.000 packets (until it hits the roof).
As you can see with your figures using 149k sessions yielded 38% utilization on the fpga's bringing you a ratio of 3921 sessions per percent.
With 220k sessions you had 50% which brings you a ratio of 4400 sessions per percent.
According to some tests performed by NSS Labs in autumn 2010 and spring 2011 the tested PA unit (4020) yielded higher true throughput than stated in the datasheets:
http://www.paloaltonetworks.com/literature/research/NSS-Labs-Report.pdf
http://www.paloaltonetworks.com/literature/research/NSS-Labs-Report-2011.pdf
So the question here is how you have setup the test-network along with which settings you use in your PA unit?
Are you for example having extensive use of NAT's and PBF's and stuff like that?
"
ended with (reply from thread starter):
"
Sorry been busy . Well the box is holding . We are now averaging 600000 sessions and dataplane utilization is averaging 78% . We had another issue with very high utilization on the management cpu . It turns out we were logging 7000 records per second . Which was taxing the management cpu to the max . We had to play around with what we were logging and it has come down . The good thing is the box held with the 300% increase in traffic . That was our greatest fear and the POC is looking good.
Thanks
"
and:
"
Upgraded to 4.1.2 and did a load balancing with two PA 4060s and it has helped with the performance issue.
"
Ok enough of spamming but thats the comments I have about PA - not really negative but still things you should keep in mind.
ReplyDeleteBy the way one of my posts seems to be automagically deleted for some unknown reason (regarding testcase and previous vuln)?
Followup on the Defcon19...
ReplyDeleteClaim: Application firewalling does not replace the need for IPS.
Absolutely true. There is no question that IPS technology is a requirement. App-ID is not intended to replace IPS or even reduce the need for it. This is the reason we have invested in building a best-in-class IPS functionality into the device. This is also why IPS is a critical piece of the next-gen firewall requirements.
Claim: Application cache causes traffic to be misidentified.
Not true. App-ID cache delivers performance gains without sacrificing accuracy. Application and protocol decoders validate the traffic on sessions identified using the cache, and if the validation checks fail, the cache entry is removed. The session is then switched out of the decoder and identified as unknown. Also, at short periodic intervals, new sessions are inspected by the App-ID engine regardless of the cache hit. This handles cases where the destination/port may have been reused for a different application server. We repeated the test described in their claim by populating the App-ID cache with an entry for web-browsing by sending multiple HTTP sessions on the same destination/port. The SMTP traffic in a following session on the same destination/port causes a cache hit, is inspected by the HTTP decoder, fails validation checks, is switched out of the decoder, and reported as unknown. The cache entry is invalidated as part of this and the next SMTP session will be identified as SMTP.
Followup on the Defcon19...
ReplyDeleteClaim: Does not inspect both Client-to-server and Server-to-client directions of traffic.
Not true. Traffic is inspected in both directions. We repeated the test described in their claim, sending an HTTP GET request followed by a FTP server response on the same session. The session is initially identified as web-browsing but switches to unknown-tcp when inspecting the FTP server response, since the traffic is neither HTTP nor FTP.
Claim: Can evade Application firewall using client-server collusion by starting the connection as a permitted application and switching to another.
Not a genuine or valid test. The scheme devised in the test assumes both the client and server are already under the control of the attacker. We don¹t know of any real-world clients or servers that can talk HTTP initially and then switch to SMTP. In any case, App-ID has coverage for many evasive real-world tunneling applications and we continue to add coverage for more as we discover them.
Followup on the Defcon19...
ReplyDeleteClaim: Some applications can only be identified on specific ports.
Partially true. The application example given was DNS. The identification scheme for DNS includes a check for port 53 since we don¹t expect any real world DNS service to be running on any other port and since DNS traffic is often very short and difficult to reliably identify by signature alone. Non-DNS traffic sent to port 53, will be validated in the DNS decoder to ensure it is really DNS. If the validation checks fail, the session is switched out of the DNS decoder and identified as unknown.
Claim: Does not inspect traffic at Layer 7 when the Application can¹t be identified.
Partially true. Traffic that does not match any of the applications that we have coverage for will be reported as unknown and eventually stop being scanned for threats. The best practice for dealing with unknown traffic is to deny it in security policy. Customers using an application that we don¹t currently have coverage for, can submit a request for adding coverage for it in one of our weekly content updates, or create a custom App-ID on their own. Allowing unknown applications is a risk that other firewalls or IPS products cannot prevent.
We are MSSP both serving customer using PA and Fortinet. Both have there pro and cons
ReplyDeleteCongratulations with your new job.
ReplyDeleteI truly hope you will decide to choose Fortinet as UTM solution so this blog will extend and extend.
It has been and is a great resource for troubleshooting Fortigates, thank you for that!
Thanks Michel,
ReplyDeleteof course if it was entirely up to me you know what platform we would choose ;)
Indeed, many thanks, Sebastian. Best of luck. Will be reading.
ReplyDeleteHello Mate,
ReplyDeleteI am new to networking and hoping you will do me a favor. I have a quick question about fortigate. I have one of these units and no console cable. So using the RJ45 cable to internal port and accessed the web console. My ignorance, I went to System->interfaces and clicked on bring down interface. Now I can't access this box. What are my options now? Your help is greatly appreciated.
Correction to my previous request. Its the internal interface that I brought down.
ReplyDeleteSince I brought down internal interface, I can't access this box. What are my options now? Your help is greatly appreciated.
A very interesting read. Some of the comments about Fortinet are misleading, wrong or perhaps based on old information.
ReplyDeleteYou can do 99% of things in the Fortinet GUI. There are a tiny number of things such as PPTP setup that need the CLI.
Reporting and monitoring is good with the FortiAnalyser but does require an investment in time to setup.
Troubleshooting with the built in packet sniffer and flow monitor is easy.
The speed and performance is easily comparable with PA.
The config files can be modified in Notepad++ or similar. I regularly chop and change them about even porting them between different FG hardware.
Even the low end FGs support multiple virtual firewalls.
The FortiGate GUI and CLI is consistent across the range from low end boxes to carrier class.
After reading the NGFW vs UTM posts,
ReplyDeleteI am starting to think the passion of the PAN folks is motivated by their desire to keep their job in a tight economy after having spent well more than double what they needed to meet requirements.
The "Easy button" is overrated. Just my $.02
--
Great blog... My question is why does PA keep dominating the Gartner quadrant for NGFW?
ReplyDeleteI've made 100% of IT infrastructure decisions (AV, content filtering, e-mail spam filtering, firewall, routing, switching, VPN and virtualization to name a few) over multiple decades based on my own findings; paying zero attention to Gartner Group "research" (and others like them).
ReplyDeleteBeen around the block with firewalls: Axxent, Cisco, Chuck Point, NS/Juniper, ... and IDS/IPS: NFR, Symantec, NS/Juniper, McAffee, SourceFire, TippingPoint, ...
The NGFW/UTM market finally shows signs of maturing to the point where I am close to making a purchase. The main challenge is that I already have other appliances and devices in place for AV, content filtering, HID among other things so there is a lot of overlap.
For my purposes, Palo Alto Networks looks to be the right combination to fit my needs. It appears to have plenty of performance in the box for processing traffic, lots of customization capabilities for unique situations and a reasonably coherent and intuitive interface with a decent CLI too.
My only grumblings from evaluating a last generation box are: GUI is less than snappy and committing changes takes too darn long. Supposedly these will be part of what is coming in the 3000 series...
We are small MSSP and we had huge issues with random 100% data plane issues with our Palo units. There datasheets aren't even close when used in the real world. In fact if you look at the current round of datasheets they have a note that says "in ideal conditions". I don't know many firewalls sitting on the Internet living in ideal conditions these days. We moved to Fortinet and have been very happy with the price to performance metrics.
ReplyDeleteAt the end of the day the Palo behaved like a under powered UTM.
I work as network administrator and use both Palo alto and Fortigate firewalls. I am working with Fortigate firewal and other devices ~4 years. I am new to Palo alto and Panorama, we bougth them just this year.
ReplyDeleteFortigate
Good:
*Easy to configure common things.
*VPN configuration is in one place, not hard to configure.
*SSL-VPN offers good options (portal or client)
*Real time configuration (no need to commit)
Bad:
*Uncommon configuration options are hidden in CLI, it is not possible to configure them through GUI
*loging and reports are not fully customizible (even including Fortinalyzer functionality)
*If you try to turn on all UTM options (Antivirus, IPS, applications, URL filtering) performance drops considerably.
Palo alto
Good:
*All configuration options is available through GUI, only debuging in CLI
*Good loging and application analysis tools
*Easy to create new policies add address group or address, because everythink is in one place
Bad:
*There is lot of limitations (we found those when migrating from old Alcatel Lucent firewall), for example:
-No more than 500 addresses in address group
-Dynamic NAT limit 400
-Static NAT limit 1000
*Annoing VPN configuration, you need to configure almos in 5 places (zone, interface, 1st pahase, 2nd phase, IPsec Crypto, IKE Crypto)
*NAT rules is separated from Security rules, hard to track associations
*IT is not possible to find out where some specific address or address group is used (only by trying to delete)
So, we have a bunch of Fortigate 310/200/400 firewalls/manager/analyzer. Well we are still at FOS 4 MR2. I know that´s not supported anymore since months/years. But after running an upgrade on one of the small ones I lost not the whole configuration but only the admin password was reset to default. And I´m really afraid of deleting the whole or part of the configuration with a firmware upgrade on my major fortigate clusters. Lossless firmware upgrade without service interruption seems not to be possible? Also I have to upgrade each cluster member myself. But damn I have to do those upgrades.
ReplyDeleteBtw on my fortinets I also have to create new address groups if one is full. This is way below your limit of 500 addresses.
Performancewise we have an active active cluster where only few UTM is activated. Sadly logging says that performance limits has been reached almost every day for some weeks for 3000 seconds. Damn I need a way to reduce the UTM protection...
http://technologyshifts.blogspot.com/
ReplyDeleteI just made new post on my recent POCs for Fortinet and Palo Alto. Here is the link if someone interested. http://technologyshifts.blogspot.com/
ReplyDeleteSurprised no one suggested Dell SonicWALL .. When you're going to spend money on a multiyear solution, you owe it to yourself to keep your options open.
ReplyDeleteSonicwall? Really? They are not even in the same realm as Palo Alto or Fortinet. Sonicwall is more for Small/Mid size companies. Also, Juniper has gone down the drain with their escape from Netscreen to the SRX series.
ReplyDelete