Possible memory leak identified in confd: Check Point Configuration Alert Guide

This is a real life sample alert from the indeni alert guide to Check Point Firewalls

Description:

The memory used by confd is increasing at a high rate without stopping. This device is running Check Point R75, which has a known memory leak in confd. It is possible the device is experiencing the issue described in SK91081.

indeni will re-check this alert every 1 minute. If indeni determines the issue has been resolved, it will automatically be flagged as such.

Manual Remediation Steps:

Follow SK91081.

How does this alert work?

indeni monitors the health of all processes in the operating system. As memory usage grows in a process, indeni attempts to determine if there is a memory leak. If there is, indeni will attempt to determine the cause (usually, comparing to known issues).

NTP Servers Configured but not Operational: Check Point Configuration Alert Guide

This is a real life sample alert from the leader in Proactive Network Management: indeni

Description:

While NTP is configured on this device it does not seem to be operating correctly for all of the configured servers.

indeni will re-check this alert every 1 minute. If indeni determines the issue has been resolved, it will automatically be flagged as such.

Problematic NTP Servers:

1.1.1.1:
Executed command “ntpdate 1.1.1.1” with the response:
27 Aug 12:36:30 ntpdate[29924]: no server suitable for synchronization found

Manual Remediation Steps:

Review the NTP configuration, firewall rules, routing tables and other elements of the network to determine the cause.

How does this alert work?

indeni uses different commands for different devices to determine if NTP is working. Examples:

  • On many Linux-based OS’s, indeni will use ntpdate for each configured NTP server (essentially forcing an NTP update and reviewing the results).
  • On Cisco devices and Juniper JunOS devices, “show ntp associations”.
  • On Check Point IPSO devices and Juniper ScreenOS devices, ntpq or ntpdate depending on version.
  • On Fortinet Fortigates, “diag sys ntp status”.

A NIC failed recently or port down

This is a real life sample alert from indeni

Description:

Some network interfaces or ports have gone from “working” to “not working”, some network traffic may be lost.

indeni will re-check this alert every 1 minute. If indeni determines the issue has been resolved, it will automatically be flagged as such.

Affected Network Interfaces or Ports:

GigabitEthernet0/2 (MAC Address: 00:0f:34:fe:00:1a, IP Address: 10.0.10.245/30, Description: Our Connection to ACME)

Manual Remediation Steps:

For GigabitEthernet0/2(Our Connection to ACME): The following log lines may assist with troubleshooting this issue:

  • Nov 12 18:30:24.704 GMT: %TRACKING-5-STATE: 2 interface Gi0/2 line-protocol Up->Down
  • Nov 12 18:30:26.588 GMT: %LINK-3-UPDOWN: Interface GigabitEthernet0/2, changed state to down
  • Nov 12 18:30:26.588 GMT: %ENTITY_ALARM-6-INFO: ASSERT CRITICAL Gi0/2 Physical Port Link Down
  • Nov 12 18:30:27.588 GMT: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/2, changed state to down

How does this alert work?

indeni uses different commands for different devices to determine if the NICs are working correctly and the ports are up. Examples:

  • On many Linux-based OS’s, indeni will use ifconfig.
  • On Cisco devices indeni will use “show interface” and related commands.

In the specific case of switches, indeni will attempt to determine if it is monitoring an access switch and will avoid alerting about ports that tend to go up and down a lot. Trunk ports, for example, will still be monitored.

 

ClusterXL Magic MAC Conflict Identified – CPFW Configuration Guide to Alerts

indeni, cisco

This is a real life sample alert from the indeni Check Point Firewalls Configuration Guide to Alerts

Description:

ClusterXL’s protocol (CCP) uses pre-set MAC addresses that by default are the same across all clusters. If you connect two different clusters to the same network segment, their traffic may conflict. This can result in odd behavior on both the cluster members and the switching equipment. This device is connected to core-switch-1 (10.12.101.1) and is using the same magic MAC address as flnj-fw1 (10.10.11.1). Note that indeni monitors the data on the switch to issue this alert as the conflict is not visible from the firewalls themselves.

indeni will re-check this alert every 1 minute. If indeni determines the issue has been resolved, it will automatically be flagged as such.

Manual Remediation Steps:

Follow SK25977.

How does this alert work?

indeni monitors the switches’ stats to identify when the magic MAC appears to be “hopping” or “flapping” between two physical ports. Once this is identified, indeni pulls the physical MAC addresses listed on those ports and crosses them with the Check Point firewalls currently monitored.

 

Check Point Firewalls
indeni is like insurance for your Check Point FIrewalls

 

Interested in learning more? Download for free the official indeni guide to Preemptive Maintenance of Check Point Firewalls. Just fill out the form below:

[ninja_form id=5]

 

Check Point Alert of the Week: Firewall log file increase rate critical – possible connectivity loss to log server

indeni, cisco

This is a real life sample alert from indeni

Description:

Over the period of the last 300 seconds there has been an increase of 1 MB in the size of the log file ($FWDIR/log/fw.log). This is a fairly high number, indicating that it is possible that the firewall cannot reach its log servers or has a slow connection to them.

indeni will re-check this alert every 1 minute. If indeni determines the issue has been resolved, it will automatically be flagged as such.

Manual Remediation Steps:

Check all hardware connections as well as any equipment (such as switches and hubs). If the log traffic is sent over VPN, check the VPN tunnels as well. SK40090 may provide further guidance on this.

How does this alert work?

indeni monitors the size of the fw.log file and alerts if it’s rate of growth is more than 1MB per 5 minutes (these thresholds can be changed).

Interested in learning more? Download for free the official indeni guide to Preemptive Maintenance of Check Point Firewalls. Just fill out the form below:

[ninja_form id=5]

Other Check Point alerts:

Check Point Firewall Experts Wanted

Every now and then it’s time to say thank you to the people who help us regularly. We’d like to organize the Check Point user community to identify who are the top contributors – those who know their stuff, can recall the days when FW1 was on a floppy disk and can configure CoreXL in their sleep.

Know anyone? Please fill out the form below to nominate your Check Point expert. You can fill it out multiple times, just be sure to use the same email under “My email” so it doesn’t fail our bot testing.

Nominations are accepted until Aug 31st, 2014.

My name:
My name:
Get technical:

CPUG.org: The risks of centralized open-source

The recent events with CPUG.org (Barry shutting down the site) have led to many conversations between Check Point users around the globe. Who owns the knowledge accumulated on CPUG.org? Are the users of CPUG.org for sale? If the site never comes back up, what happens to all the content contributed by thousands of users around the world?

It causes you to think – when a community picks a site and decides to contribute content to it, is the community aware that it doesn’t own the content? What happens if YouTube were to shut down? It’s very different to open-source development, where each contributor essentially has a copy of all the code. Here, no single contributor has a copy of any of the content that CPUG.org contained. It’s all lost now.

The only upside of this turn of events is that something important has been emphasized yet again – knowledge is critical. In order to do their jobs, Check Point administrators around the globe have relied on CPUG.org for the knowledge it contained. Their job is now negatively impacted by the lack of CPUG.org’s availability. Knowledge is something that needs to be collected and protected.

At indeni, that is what we do. We collect knowledge, we deliver it and we ensure it won’t disappear one day. We’re sad to see what’s going on at CPUG.org but would like to take the opportunity to say: your knowledge is safe with us. We welcome any contribution of knowledge and will make it available to all of our users immediately. Therefore, your effort turns into direct assistance to others around the world, almost instantly. That’s powerful.

For examples of the knowledge indeni has in the Check Point world, click here.

Gateway Cannot Access Certificate Authority: Check Point Alert Guide

This is a real life sample alert from the indeni alert guide for Check Point Firewalls for Proactive Network Management

Description:

Some of the certificate authority servers which this device considers to be those to be used during authentication (for example – for VPN) are not accessible. The CA servers for which an issue has been found are listed below. This may result in VPN tunnel failure (according to SK100731).

Unreachable Certificate Authorities

internal_ca (10.1.7.112)

Manual Remediation Steps:

Identify why the device cannot initiate a connection with the listed certificate authorities and correct as soon as possible.

How does this alert work?

indeni connects to all gateways and management servers and determines which gateways are configured to connect to which certificate authorities. In most cases, these are the internal certificate authorities (ICA) running on the SmartCenter/Provider-1/Multi-Domain-Manager. Then, for each gateway, indeni will test connectivity from the gateway itself to certain ports (such as 18264) on the certificate authority server. If the test fails, an alert is issued.

 

capture