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 takeawaysThis key takeaway was generated through LLMs crawling the page and coming up with an overview of the content.

The article describes recurring operational issues observed after RMA replacement of Check Point firewalls, where a cluster member disappears and a differently identified replacement joins with configuration mismatches. It highlights real-world problems such as missing or incorrect licenses, device-level configuration differences, and mismatching firewall policies that can lead to service disruption once trial licenses expire or configurations diverge. The article recommends a detailed checklist of license verification and configuration comparisons, and suggests using indeni for automated detection to prevent outages and speed post-RMA recovery.

What license checks should I perform after installing a replacement Check Point firewall?

After installing a replacement device, verify that the replacement has the correct licenses attached because licenses from the old device may not apply. Run cplic print -x and confirm the expected licenses are present; trial licenses will appear as blank output from cplic. Remember out-of-the-box replacements are typically provisioned with a 15-day trial that enables services temporarily, and once that expires the device will stop providing service, so validate permanent licensing promptly.

Which device-level configurations are most important to compare between cluster members post-RMA?

Compare routing tables (netstat -rn, show route), CoreXL and SecureXL settings (fw ctl multik stat, fw ctl affinity, fwaccel stat), any manually edited .def and .conf files such as fwkern.conf and ipassignment.conf, and OS-level files like /etc/hosts, NTP, and DNS. Also verify interfaces (IP addresses and subnets) match the intended configuration. Ensuring these items are identical or appropriately similar to the other cluster member reduces configuration drift that can cause operational issues after a replacement.

How can I detect mismatching firewall policy or other issues after adding a replacement device to a cluster?

Mismatching firewall policy can occur when a new device joins a cluster running a different policy than the active member; policy includes the rule base plus IPS signatures and VPN settings. Backups alone are insufficient for full automated recovery, so use a detection tool to identify discrepancies across policy, signatures, and system settings. The article recommends using indeni to automatically surface these and hundreds of other potential issues so you can pinpoint problems before they become critical and avoid outages after RMA procedures.

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

Close-up of interlocked metal chain links symbolizing connected network objects and relationships in IPAM

How to map your network with user-defined links in Integrity X

Map your network with user-defined links in Integrity X to define and manage custom relationships, such as dual-stack and NAT environments.

Read more
Flock of geese flying in formation across a blue sky, framed by a pink graphic border, symbolizing coordinated network migrat

Automate your DDI modernization path by migrating with Micetro

Automate cross-platform DNS and DHCP migration with Micetro to reduce risk, eliminate manual effort, and modernize infrastructure faster.

Read more
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