RMA Do’s and Don’ts for Check Point Firewalls

Notice: This blog post was originally published on Indeni before its acquisition by BlueCat.

The content reflects the expertise and perspectives of the Indeni team at the time of writing. While some references may be outdated, the insights remain valuable. For the latest updates and solutions, explore the rest of our blog

Key Takeaways
  • Post-RMA Check Point firewall replacements frequently join clusters with configuration inconsistencies that cause operational issues.
  • Replacement devices may be running only a 15-day trial license, so license status must be verified with cplic print -x to prevent unexpected service interruptions.
  • Device-level settings such as routing tables, CoreXL/SecureXL configuration, custom .def/.conf files, and OS parameters (e.g., /etc/hosts, NTP, DNS, interfaces) must be aligned with the existing cluster member.
  • New cluster members are sometimes deployed with a mismatched firewall policy, including rule base, IPS signatures, and VPN configuration, leading to inconsistent security behavior.
  • Backups enable access to configuration data but do not provide full one-click recovery, so manual validation and alignment of the replacement firewall are still required.
  • Continuous monitoring tools are valuable for detecting configuration drift and RMA-related misconfigurations before they result in outages.

While reviewing our customers Check Point firewalls I’ve identified a pattern that keeps repeating itself: many issues tend to happen post an RMA.

The pattern that we observe is the following:

1. Two members of a firewall cluster are monitored successfully, alerts being issued, etc.
2. At some point, one member disappears (which indeni issues an alert for, of course).
3. Later, a new machine suddenly appears and is clearly not the old one (different SSH host key, serial number, etc.).
4. This new machine joins the cluster but there is a whole set of configuration issues.

Since this keeps happening again and again, I would like to point out some common mistakes that are made when RMAing a Check Point firewall and installing the replacement device into production .

  • Lack-of or wrong licenses – it depends on what licenses you use, but it’s possible that the licenses you had attached to the old device won’t be applicable to the new device. Keep in mind that the out-of-the-box replacement is usually provisioned with a 15-day trial license that will allow all services during that period. Once the trial period passes the device will stop to provide service.  Make sure to run cplic print -x and validate that the licenses are what you expect them to be. Trial licenses will appear as blank output from cplic.
  • Device-level configurations missing/mismatching – I highly recommend that you go over each of the following and make sure they are either identical to the other cluster  member or similar (where appropriate):
    • Routing tables (netstat -rn, show route)
    • CoreXL and SecureXL (fw ctl multik stat, fw ctl affinity, fwaccel stat)
    • Any .def and .conf files you may have manually edited, such fwkern.conf, ipassignment.conf, etc.
    • OS-level files, such as /etc/hosts, NTP, DNS, etc.
    • Interfaces (IP addresses, subnet in use, etc.)
  • Mismatching Firewall Policy – sounds crazy, but we run into this more than we’d expect. Somehow new devices are added to a cluster while running a different policy to the currently active member. Remember that policy isn’t just the rule base, it’s also the IPS signatures, VPN settings, etc.

While there are many backup solutions out there, including our own, backing up isn’t the entire solution. It is just the first step. A good backup makes sure you have the content you need in order to rebuild the box. However, no backup solution provides you with complete 1-click recovery. So please make sure to go over the above checklist.

Using indeni to identify the above,  as well as hundreds of more possible issues, will  ensure that your next RMA procedure goes flawlessly. For us, it’s all about avoiding outages by pin-pointing issues before they turn critical. It takes less than an hour to install indeni and we’ll be happy to help you do it (contact our support).


Published in:

Related content

Three armored figures walking toward a futuristic Las Vegas skyline with pyramids, glowing orb, and "Welcome to Fabulous Las

Your journey to intelligent NetOps begins at Cisco Live

Visit BlueCat’s booth or book a meeting now to learn more about how our solutions can help you build a network that supports constant change.

Read more
Stacked colorful wooden directional arrows on a post by a calm seaside with distant hills and blue sky

Replace BIND and ISC with Micetro DNS/DHCP Server (MDDS)

Tired of patching and manually configuring BIND DNS and ISC DHCP? Discover how Micetro MDDS appliances can replace them for modern DDI.

Read more
Row of orange industrial robotic arms positioned along an automated conveyor belt in a factory setting

Automate it all in Integrity with REST v2 API-first DDI management

Discover API-first DDI with Integrity X by using REST v2 to automate DNS, DHCP, and IPAM for scalable, secure network operations.

Read more
Three colleagues at monitors collaborating, overlaid with network, analytics, cloud, and gear icons.

Agentic AI adoption in network observability propels NetOps teams

Network observability is crucial for today’s networks and even more capable with agentic AI, according to new Omdia and BlueCat research.

Read more

⏳ Cisco Live is almost here. Put BlueCat on your agenda for smarter, more secure networks.