Palo vs Checkpoint

Tldr: I need advice on Palo compared to Checkpoint

My company has 2 IT components. One is, well, IT while the other is OT. OT environment (my side) uses Palo only whereas the IT side only uses Checkpoint.

We are working to refresh our hardware on the OT side and getting pushback now that we need to use Checkpoints instead and convert.

I have been tasked by management with proving our Palo is ‘better’ than the CP. The only thing I have to tangibly compare is whitepapers from each where, of course, they both look like the best firewalls ever. They are both top right quadrant for Gartner and very high in Forrester so nothing major there to use.

Does anyone have experience with both that can clue me in on weaknesses to look at, large improvements one has over the other, etc? Appreciate it in advance.

I’ve used several different versions of Check Point throughout my career, starting back on Check Point for Windows Server in the mid 1990s, proceeding on to Check Point on Nokia IPSO appliances, and then finally on to Check Point R65, R77, R80, and R81 on GAIA appliances. Having been re-introduced to R89+ in the last couple of years after a long absence, here are my thoughts on their current product offering:

CP Advantages
-----------------------

  1. Centralized management concept.
  2. Centralized logging concept.
  3. Revision management.
  4. Easy rulebase duplication.
  5. Shared firewall objects between rulebases.
  6. Shared or separate rulebases between firewalls.
  7. Reporting works as expected.
  8. Firewall rule auditing works well.
  9. Policy verification can help prevent overlapping rules.
    CP Disadvantages
    --------------------------
  10. The GAIA web interface only works with IE out of the box until it is patched.
  11. If you use an ad blocker in your web browser, GAIA web interface cannot be managed.
  12. GAIA OS supports /31 addressing, Check Point firewall software does not.
  13. GAIA OS supports multiple subnets on a single physical interface, Check Point firewall software does not.
  14. GAIA OS OSPF routing only supports the broadcast interface type.
  15. No BFD support in the current version.
  16. Installing rule changes takes 7-10 minutes per push. Installing multiple rule changes wastes much time and makes troubleshooting slow.
  17. The SmartConsole Windows fat client is slow to use in an RDP session. It is even slower to use over the WAN.
  18. There are no less that 4 distinctly different interfaces to manage this product: GAIA CLI, GAIA web interface, SmartConsole, GUIDBEdit, and SmartUpdate. Each interface does a specific thing; some specific to the interface, some shared with other interfaces.
  19. There is very little communication between GAIA OS and the Check Point firewall software, sometimes causing conflicts.
  20. The Check Point firewall software by default blocks all dynamic routing protocols. If there is a rulebase issue, then there is a dynamic routing protocol issue.
  21. Setting a static NAT in the firewall GUI does not automatically set a proxy ARP address in GAIA OS. After using the SmartConsole firewall fat client to create a static NAT, you then must go into the GAIA web interface and manually set a static proxy ARP address for the recently created static NAT.
  22. License installation is confusing and not at all intuitive when a large amount of licenses exist in the license management GUI.
  23. SmartCenter clustering is Active/Passive and requires manual intervention in a failover event.
  24. Gaia appliance clustering is Active/Passive with 2 hosts max in a cluster.
  25. Identity Agent does not work.
  26. Identity Collector is easy to break by uploading a certificate to an appliance with the same name as the one used on other appliances but that has different content. This will break the trust relationship of all devices that share that certificate within Identity Collector.
  27. Access to Check Point licensing servers is blocked by default by firewall policy and is easy to block accidentally.
  28. The amount of legacy code/options in the firewall product is excessive.
  29. OSPF operation in a cluster environment is a bit wonky, with the primary cluster member having full OSPF functionality and the secondary cluster member having zero OSPF functionality.
  30. Packet are dropped if a VRRP master for an interface is not the cluster master.
  31. Clustering is not OS clustering, it is application clustering. This causes conflict between the OS and the application sometimes. See VRRP and OSPF issues above.
  32. Client VPN management requires both the fat client and the GAIA CLI to fully manage the solution.
  33. There is no virtual partitioning of the appliances/firewall software. No VSYS as on PA or no VDOM as in FGT.
  34. The configuration is stored in binary format, making simple text-based configuration manipulation impossible.
  35. Patches come in a format similar to Windows Updates. This can be problematic. A single binary image update is much preferred on a networking device.
  36. No way to modify the security policy locally in the event of an “island” scenario.
  37. While it is nice to not have to specify source and destination interfaces in the firewall rulebase, there is no option to do so even if we needed to specify interfaces for traffic flow purposes. The option to at least be able to specify inbound and outbound interface traffic flow is a requirement, even if we don’t always use it.
  38. Many MacOS users have complained that the VPN client is difficult to use.
  39. CLI authentication using kinit on headless linux does not always work as expected. It can be challenging to get authenticated using kinit on the CLI.
  40. No dynamic routing to advertise the Client VPN subnet. A redistributed static route must be used as a workaround to advertise the client VPN subnet to the rest of the network.
  41. VRRP packets are dropped by the out-of-the-box firewall policy, so it is not possible to cluster appliances together without first modifying the firewall policy to allow VRRP packets between appliances.
  42. Identity Collector appears to be strictly time based, and will cut off an identity based session when the timer expires without first checking to see if both the user and host are still online. This leads to broken connectivity throughout the day.
  43. Asymmetric routing is not supported.
  44. A “Login failed…” error message will be displayed in the authentication portal with an active ad blocker. Disable the ad blocker and refresh the page to maybe be allowed to authenticate through the portal.
  45. If two of the same routes exist from two different methods (static or dynamic), GAIA prefers dynamically learned routes over static routes <!>. CP provides Protocol Rank, similar to Cisco Administrative Distance, to promote static routes over OSPF routes, but the default is to prefer dynamic over static. This is the exact opposite of the industry norm that prefers static over dynamic.
  46. GAIA authentication and SmartCenter authentication are two completely different systems. You may be able to get into one but not the other, leading to not being able to fully manage the firewalls.
  47. No VRF support. When using a dedicated management network with the appliance mgmt interface, both data and management traffic are routed in the same route table leading to asymmetric routing into the management network.
  48. Policy verification will not let you create overlapping rules, even if it fits a specific situation.
  49. SmartConsole crashes quite a bit.

I converted our Checkpoint installation to Palo Alto (with Panorama) years ago, manually. Object by object, rule by rule. It was well worth it.

I had to manually edit so many files in Gaia (Linux) to fix problems or gain functionality that was needed. It was a nightmare. If you need VPN or routing protocols with Checkpoint, good luck. They do things their own way.

I would never use Checkpoint again, and stay away from any job that had it, unless it was to replace it. I think if you perused these forums, you’ll find several people who have moved from Checkpoint to Palo Alto. I’m not sure you’ll find the reverse.

Pre-Palo I was a Checkpoint customer/partner at several points & certified. I got burnt about 2008 where had some crazy licensing error that killed all our sites at once, and our management server was in a colo we couldn’t reach due to the Checkpoint being down. Had to drive a couple of hours to it (concurrent with support ticket being escalated) and physically connect with support on the phone to resolve. Vowed never to have anything again that could fail just due to a licensing issue. At least with Palo if the license expires, just the subs stop but it keeps passing traffic.

I have worked with 5 brands of firewalls cisco, fortigate, palo alto, checkpoint and juniper.
Number one is Palo Alto, forget everthing else. You will love this firewall.
Checkpoint is enterprise fw but too complicated.
Management of Palo Alto is 10 times better.
If buget is a problem rather buy fortigate.

You should read about Nir Zuk, the founder and CTO of Palo Alto Networks.

He was a principal engineer at Check Point in the past.

He essentially knew there was a better way…

Much of original statefull inspection in firewalls was developed by him.

I’ve used both Palo and Checkpoint. I feel like with Palo you’ll have to deal with management server / logging issues that drive you crazy.

Now, Checkpoint on the other hand, you’ll have to deal with management server / logging issues that drive you crazy.

I think its pretty clear who the winner is here.

I’m a CCSM Elite engineer working with mostly Check Point. But I have great relations with the Palo team within my company. And I do run Palo Alto at home/LAB as I love to have experience outside my own “bubble”.

Check Point has this split personality. On one end I find it superior to Palo Alto from a management and logging side of things. I prefer Smart Console over Panorama when it comes to reading through logs, handling objects, getting a overview and understanding of a firewall policy etc. The only downside is how the software is Windows-only, and it requires you to install the software. Panorama being WebUI makes it more flexible and easier to access, but actually using it and working within it I find Smart Console superior in most ways.

The problem with Check Point stems for the fact that you often have to move outside Smart Console. When configuring gateways you will need to head over to “Gaia Portal”, aka WebUI of said gateway, or my preferred way, use SSH/CLI. And the SSH/CLI experience of Check Point is way more comprehensive compared to Palo Alto. This creates a sealing of difficulty that scales way beyond what most firewall admins are, and should be comfortable with. I end up editing various .conf files, reading various .elg files, running kernel commands and whatnot. It’s borderline insane. This comes with pros and cons, this enables CCSM Elite engineers like myself to do a lot without ever needing to involve TAC. It also makes the solution extremely flexible as I can manipulate it in so many ways. But for most users this becomes a nightmare as the useability and userfriendlyness is abysmal.

Another downside of Check Point is how every supported version tends to get affected with the same bugs. I’m not that experience with Palo Alto software to say anything definitive, but from what I understand you can stick with older, still supported versions of PanOS and avoid most bugs. So unless you need to be on the cutting edge due to hardware or some specific feature requirement, you can stay conservative and avoid most complications. This isn’t possible with Check Point in the same way as the code is mostly the same across major versions of the most part, unless there is a big leap between versions. The current supported versions are R80.40, R81, R81.10 and R81.20. The all share the same 3.10 linux kernel, and besides specific new features introduced with each new version, most of the code is the same. If you read the JHF release notes, you’ll notice they are 99% identical across all versions. The same changes and fixes are being applied to all versions, which often result in the same kind of bugs being introduced to all versions as well. This removes the capability of being conservative and staying with older versions for stability as you are always recommended to patch to the latest recommended JHF regardless of version, and it will often introduce the same bugs across all supported versions of Check Point Gaia. Unless your specific bug is tied to a specific feature introduced in a new version of course.

Overall I’d say Palo Alto and Check Point are both great and really capable. But the level of expertise and skill required to manage and optimse a Check Point solution scales way higher when compared to Palo Alto. For better or worse.

I’ve been working with Check Point products since the late 90s and they had their struggles but they are hands down the best product but very expensive.

Check Point is due to release their new version R82 version very soon which has several interesting new features such as Infinity AI Co-Pilot, Dynamic Access Layer, ElasticXL, VSnext, Backup/Restore Improvements, Upgrade Paths/Improvements, Quick Start for New Hardware, Non-Disruptive TLS Inspection, and much more.

Here’s a document comparing Check Point with Palo
https://www.checkpoint.com/comparison/check-point-vs-pan/

Very comparable. I think Checkpoint has better central policy management from a visual perspective compared to Palo. While Palo firewalls are straightforward to upgrade and manage compared to the Checkpoint variations possible. My suggestion is they are the same for the traditional capabilities they can do and it is a matter of personal preference and cost comparison for which is “best”.

I’m not a big fan of Checkpoint, but when it comes to OT, my impression is that they are ahead of PAN. They have functionality for not only controlling which OT application you can permit/block, but they can also control which parameters certain OT applications can use. This means that with for example Modbus you can specify the application, but also specify which Unit ID, Address (or address range) and value (or value range). This gives you an extreme granularity in your firewall policies. As far as I know, Checkpoint and Fortinet are the only NGFW vendors that gives you this amount of granular control over OT protocols.

Edit: Someone claims PAN has had this functionality for ages. I haven’t seen any documentation for it thought.

Used to be Checkpoint certified and did a ton of it…but about 3-4 years ago they just became irrelevant as Palo zoomed passed with development of their next gen features.

The only CP work I have done in the last 3 years is migrating clients to Palo (and yeah I probably migrate more Cisco to Palo than anything but I still see the occasional CP migration)

Now…to the IoT side- Palo is doing this now but it’s still pretty new. Its a subscription for Pan-OS but you manage it both in the gui and from the app hub. So it’s not a single interface that some people would like to see…but its waaaaaaayyyy easier than ForeScout’s solution

I am a professional services consultant for a reseller, I have worked with both extensively.

what I don’t like about Checkpoint is that the Gaia operating system, IP addressing, routing etc. is seperate to the Smart Cosole managment. It makes upgrades and new installs difficult and messy. Palo has a flat file XML configuration. It has a similar CLI to juniper, which is awesome.

But Checkpoint has the updatable objects, makes wokring with O365 and public cloud objects so much easier.
Many of my customers ask me to use different NAT pools and to bypass TLS inspection for Office 365, which is really easy on Checkpoint
Palo has ‘Hosted Dynamic Lists’ which has O365 objects but its always seems outdated, users complain and the rules often don’t match.

My other issue with Palo is that security is weak. wildfire only blocks files that have been uploaded and previousely found to be malicious. Where Checkpoint sandbox can hold files until a verdict is reached.
I find it difficult to explain to customers that Palo will let unknown files through if they havent been sent to wildfire before. and they call me out saying its no better than AV signatures, which I guess is true.

The Checkpoint reporting and managment in general is also much better, I can customise reports and it looks great. the Palo ACC thing is nice but its basic and takes forever to load, can’t really customise it and is mostly fucused on application usage rather than security.
I feel safer using Checkpoint when secuirty is the reason Im there, which it often is

Funny to see people arguing based on experiences from years ago. Both are premium firewalls, and they’re constantly watching each other to see where they can improve.

It’s like me telling you I sold my Audi in 2012 because it couldn’t play DAB+ radio, while my Mercedes could. Guess what? Both cars have been playing DAB+ flawlessly for years now. :wink:

If you care about security then I would go with Check Point. Take a look at Miercom 2023 and 2024 NGFW threat prevention tests.

There are certain things that Palo does better than Check Point does. Like application control and URL Filtering, Palo has cornered the market in terms of Metadata based Application Control and URL Filtering. However from an overall firewall perspective, Check Point is significantly better.

Check Points Cloud Adoption and Interoperability is significantly better than anything Palo has put on the market.

I also run both and would still choose Check Point over Palo every day of the week.

Check Points pricing also blows Palo out of the water. Palo wants entirely too much money for things that Check Point provides in a single license.

For Example, Palo wants a stupid amount of money for their IoT Security License where Check Point offers that all in a single license.

I’d also venture to say that Check Points Endpoint Protection Suite with Desktop Policies is way better than anything Palo has provided.

Overall there are use cases where you may need both in an environment.

WatchGuard is also cheap and best

  1. There is no per-IP traffic shaping.

  2. Logging can be configured to log to a SmartLog server and/or to a SmartConsole server with no differentiation in SmartConsole as to which data source is being accessed. This can cause logging data to fill up either server unintentionally, consequently preventing access to all log data until the logs are flushed and space is cleared.

  3. Organizations such as Gartner say that Check Point is “leading the pack” and have “completeness of vision” for NGFW services and that their IPS/DLP/etc services are top ranked. This was one of the reasons Check Point was chosen. In reality we have had just as many security related incidents with CP as we have had with other vendors in areas such as DMZ system compromises and testing lab cryptoware attacks. This is because the security related incursions are generally not related to firewall protection, but to lack of security best practice guidelines being followed by local systems administrators. Without enforcement of proper security practices through all levels of the connectivity stack, in the types of incursion scenarios experienced in the the past due to these issues, it would seem that no firewall from any vendor would help in this regard.

  4. The “expert” password in GAIA can be easily changed without being in expert mode or knowing the previous expert password. Expert mode delineates normal OS functionality from elevated privilege OS functionality, similar to “sudo” or “enable” on other OSes.

  5. Using NAT on multiple external interfaces with multiple ISPs can cause incorrect NAT addressing for ISP1 to be applied to ISP2 and vice-versa, causing dropped traffic. This has been partially fixed in the latest patches, but specific instances still exist.

  6. No partial name searches when searching for a firewall object in SmartConsole… Super annoying when trying to find like named objects.

  7. Client VPN server process is single threaded. The more people that use the service, the poorer the performance is - sk16585348.

  8. At first it appears that Check Point is one of the few vendors that allows for wildcard domain entries in firewall rules, and this seems great as it is exactly what we need to be able to dynamically build firewall rules based on wildcard domain destinations. Once you use it and find that most of your wildcard entries do not match anything you come to realize their implementation of using reverse DNS lookups to verify wildcard domain resources is flawed because many public resources do not properly populate reverse DNS entries for hosts located in CDNs or public cloud providers. The feature is more useless than helpful and causes confusion and long troubleshooting sessions trying to figure out why a wildcard DNS entry is not matching anything.

  9. The Check Point client VPN encryption domain is a single entity tied to a specific management domain. This means that all gateways hosting client VPN services in a single management domain are either all split tunnel or all full tunnel. It is not possible to configure some gateways to offer split tunneling and others to offer full tunneling within the same management domain. In order to accomplish this seemingly simple task, an additional management server must be used for specific gateways that offer a different encryption domain than the primary management server, leading to multiple management servers and domains each with different settings, policies, objects, rules, definitions, etc. All this is required to provide different encryption domains for differing employee population requirements that rely on client VPN services.

  10. Policy installation can sometimes take up to 10 minutes per push, limiting troubleshooting procedures.

  11. Two different admins cannot push two different policies to two different gateways at the same time. This slows down management tasks.

61, Separated NAT and firewall policy rules are not a good design. NAT translation should be built directly into the firewall rule policy.

  1. The bigger appliances have a LOM interface for Lights Out Management - but after using it you quickly realize it actually means Lots Of Mistakes. It requires an old Java version to use it, the remote console crashes quite a bit, there are RADIUS and LDAP configuration screens but neither work for authentication, changed settings in the GUI are not always saved, and the list goes on.

  2. Still cannot traceroute through your Check Point firewall even though you have enabled it in the firewall ruleset? You must also enable it in Gaia via the “fw ctl set int fw_allow_simultaneous_ping 1” command. Why?

Since switched to Palo. Much happier.

  1. Not true, at least not for R80+. Currently the supported versions are R80.40, R81, R81.10 and R81.20. You won’t be facing this issue when running any supported versions. R80.40 becomes end-of-support next month, while R82 should release by the end of the year.

  2. Really depends on your ad-blocker. You should always hvitelist WebUI’s regardless. This goes for Palo Alto as well. No point in having a active ad-blocker running on WebUI’s as they can end up breaking things.

  3. I’m very confused on this. Why do you keep separating between Gaia OS and Check Point firewall? Gaia OS is the operating system that runs on all Check Point firewall installations?

  4. Again I’m very confused by you acting like Gaia OS and Check Point firewall are two separate things? Gaia OS supports sub-interfaces (VLAN), it also supports adding additional IP addresses per interface, but this is something I never see in production environments. One thing it does not support is to have physical (VLAN0) and sub-interfaces (VLANs) on the same interface.If you for instance add VLAN10, VLAN11 and VLAN12 on eth1, you can’t run VLAN0 on eth1 at the same time.

  5. Pushing policy depends greatly on the management server and write speed of the hard drive on the security gateway. With accelerated policy push on the later versions, policy push will normally complete within 1-2 min.

  6. Smart Update is legacy and something you’d normally not use anymore. After initial configuration you will spend most of your time in Smart Console. But all debugging has to be done using SSH/CLI. You will rarely use the Gaia Portal / WebUI after initial configuration, unless you prefer to use it over SSH/CLI.

  7. This goes for most things. Check Point is “Security first” for better or worse. Besides some basic Check Point traffic being automatically allowed via “Implied rules” unless disabled, you will have to manually configure rules for about anything as Check Point will drop it all unless there are explicit rules allowing for the traffic.

  8. This all depends on whether you are following Check Points “best practices” and configurat NAT directly on network and host objects. This will do automatic proxy ARP. The only scenario where you end up with no automatic proxy ARP is when do you manual NAT rules, which, according to Check Point, is not the recommended way of doing things. I myself prefer manual rules to have more control, but it’s good to know that when doing it the way Check Point has meant for you to do it, this is not an issue.

  9. Check Point licensing is a complete mess. Everything form understanding the licensing itself, to applying licenses etc. Is horrendous. And when running virtual or open server gateways, all traffic will stop if there is no valid license applied. Not even the basic firewall blade will run once the license has expired, which is terrible. With appliances the firewall blade will always run, but Threat Prevention and IPsec VPN till stop functioning without a valid license.

  10. What do you mean by manual intervention? ClusterXL HA is seamless with full synchronisation of the connection table. With R82 things improve further by providing ElasticXL allowing for full Active-Active clustering with up to three gateways. One downside of ClusterXL is the use if “VIP” IP addresses, meaning you will need to have three IP addresses per subnet. One per gateway, and one virtual as VIP. This might be an issue for WAN where IP addresses might be limited.

  11. ClusterXL supports three members, you can run Active/Standby/Backup. But normally, in such scenarios Check Point will recommend you to deploy Check Point VSX, so you can run VSX VSLS to better utilise all three gateways for load sharing. All of this changes with R82 and the new ElasticXL clustering, where you can have up to three members running either Active/Standby/Standby or Active/Active/Active.

  12. What do you mean by this?

You can configure virtual fw on checkpoint phisical fw