Announcing 5.4: New rule engine, Check Point 61000/41000 support
Welcome 5.4!
In this release we’ve included phase one of our infrastructure operations platform, added new content and as well as Check Point 41k/61k support. In addition, specific feature requests and bugfixes were included. Please reach out to our support team to get the updated release.
IMPORTANT NOTE TO ALL USERS: Starting with 5.4, the licensing mechanism is attached to the indeni instance’s unique identifier (uid) and not the IP address. This allows customers to not only change the IP of their indeni instance, but also set up cold active/standby high-availability in case the primary indeni instance is down or is cut off from the network. To set up cold active/standby, please reach out to our support team.
New content:
- New Rule Engine: With this release, a new rule engine has been incorporated into the product. In the future it will allow partners, consultants and customers to write their own checks on top of indeni’s infrastructure operations platform. This is an early version of the engine. If you are interested in learning more, please email [email protected].
- IK-2449: Support Check Point 61k/41k – initial support (Check Point firewalls). This includes:
- CPU, memory, swap and disk utilization
- Tracking of number of connections and alerting when a drastic drop in connections occurs
- Blade status tracking (up, down, flapping)
- License tracking
- Network port utilization, drops, errors
- Ability to alert when specific logs are found matching regular expression patterns. Sample patterns included with this release:
- outed.*quitting because too many sockets open
- routed.*Exit routed
- fwha_.*
- cul_load_.*
- Port .*?: Down
- PPPoE session failed to connect
- NAT Hide failure.*
- Invalid username/password
- Failed to check .*? content upgrade info due to generic communication error
- Failed password for.*
- Drive error detected
- Chassis Master Alarm:
- Auto update agent failed to download new content
- .*internal error – invalid port.*
- .*[Ll]ogin denied.*
- .*? job failed for user Auto update agent
NOTE: The support for Check Point 61k/41k was built entirely on the new rule engine included in this release.
Key takeawaysThis key takeaway was generated through LLMs crawling the page and coming up with an overview of the content.Release 5.4 introduces phase one of an infrastructure operations platform, a new extensible rule engine, Check Point 61k/41k support, targeted content additions, and multiple bugfixes and improvements. The update changes licensing to bind to the indeni instance unique identifier (uid) instead of IP address, enabling IP changes and cold active/standby high-availability setups, and expands monitoring coverage (CPU, memory, connections, blades, licenses, ports, and log-pattern alerts) for Check Point firewalls. Operational impact includes reduced false positives, improved bandwidth usage and discovery, HTTPS proxy support, and many device-specific fixes to improve reliability and alerting accuracy across supported devices.
What is the important licensing change in indeni 5.4 and how does it affect high-availability setups?
Starting with 5.4, the licensing mechanism is tied to the indeni instance’s unique identifier (uid) rather than the device IP address. This change allows customers to change the IP address of an indeni instance without invalidating the license and enables cold active/standby high-availability configurations where a standby instance can take over if the primary is down or network-isolated. To implement cold active/standby or get assistance with the new licensing behavior, customers are instructed to contact the indeni support team for guidance and setup.
What monitoring and alerting capabilities were added for Check Point 61k/41k devices in this release?
Initial support for Check Point 61k/41k was added using the new rule engine and includes monitoring of CPU, memory, swap and disk utilization; tracking connection counts with alerts for drastic drops; blade status detection (up, down, flapping); license tracking; and network port utilization, drops, and errors. The release also enables alerting on specific log messages that match provided regular expression patterns (a set of sample patterns shipped with the release). Note that this Check Point support was implemented entirely using the new rule engine introduced in 5.4.
What are the notable bugfixes and minor improvements included in 5.4 that impact alerting and resource usage?
Release 5.4 includes several fixes to improve alert accuracy and reduce resource use: HTTPS proxy support for indeni insight (IS-1862); using the indeni instance ID for licensing to allow IP changes (IS-1437); changes to SNMP trap flow to send indeniNewAlertTrap whenever an alert becomes active (IS-920); caching HKLM_registry output to reduce bandwidth (IK-2448); improved lsof usage to lower data usage (IK-2447); and ensuring swap usage always alerts at a 1% threshold (IK-2339). Additional fixes address false positives (sync loss events), device discovery failures, backup behavior after device removal, parsing inaccuracies, and several Check Point-specific alerting and display issues.
Select new signatures:
- IS-1864: Alert when SSL decryption doesn’t work due to unsupported cipher suites (Palo Alto Networks firewalls, see https://live.paloaltonetworks.com/t5/Management-Articles/SSL-Decryption-Not-Working-due-to-Unsupported-Cipher-Suites/ta-p/55543)
- IK-2142: Track buffer utilization via ‘debug dataplane pool statistics’ command (Palo Alto Networks firewalls)
Select bugfixes and minor improvements:
- IS-1862: Support HTTPS proxy for indeni insight
- IS-1844: Treat chassis devices (61k, 41k, Crossbeam, 7080, etc.) separately for licensing purposes
- IS-1437: Use indeni instance ID for licensing instead of IP address (allow IP address changes for indeni devices)
- IS-920: SNMP traps: change flow to use indeniNewAlertTrap every time that an alert becomes active instead of only sending indeniAlertStatusUpdateTrap
- IK-2510: Bugfix: indeni continues to backup a device after it’s removed from the backup schedule
- IK-2495: SecureXL templates are partially disabled’ does not alert for VSs (Check Point firewalls)
- IK-2494: Inaccurate parsing of firewall kernel memory in ‘fw ctl pstat’ (Check Point firewalls)
- IK-2493: Monitoring Suspended due to unexpected mpstat output
- IK-2479: Failing to discover MDM using RADIUS-based login (Check Point firewalls)
- IK-2448: Cache HKLM_registry output to reduce bandwidth usage (Check Point firewalls)
- IK-2447: Improve ‘lsof’ command usage to reduce data usage
- IK-2442: Failed to Communicate alerts: send via email when these occur
- IK-2408: Contract expired/about to expire’ alerts should only display the contract and add reference to SmartUpdate (Check Point firewalls)
- IK-2405: “Use of NTP servers configured but not operational” add details even when all NTP servers are not synced (All devices)
- IK-2339: Swap memory usage should always alert if swap is used (reduce alerting threshold to 1%) (All devices)
- IK-1979: Sync loss events have occurred – possible sync network issue (SA#35136)’ false positive in case of policy installation, set a threshold for alerting to 5 sync loss events (Check Point firewalls)
- IK-2497: Errors appear in the indeni web console due to devices being deleted
Related content
BlueCat moves agentic AI from insight to action with new AI integrations
Extends its Intelligent NetOps platform to help organizations unlock measurable AI value through a unified data foundation
BlueCat appoints Jeff McCullough as Vice President, Worldwide Channel and Alliance
Experienced channel leader will drive partner-led growth and support partners in generating revenue and value within BlueCat’s global ecosystem
BlueCat introduces BlueCat Horizon, a SaaS-first Intelligent NetOps platform for cross-domain network operations
The platform delivers a unified control plane for DNS, DHCP, IPAM, security, and observability, empowering rapid, automated action across networks
Fewer than half of enterprises are fully successful with network observability tools
Fragmented tools and cloud blind spots are straining NetOps, but a new five-stage maturity model charts the path to excellence.