Troubleshooting Checkpoint Reporting Devices

I`ve configured Checkpoint with MARS lots of times and never encountered a problem.

But on an install a few weeks ago, it just wouldn`t play ball.

I`m not going to go into detail on how to configure Checkpoint with MARS, as thats all in the documentation. In this article i`m going to give you a few hints and tips on what to look for if things dont go to plan!

Check Point components uses Secure Internal Communications (SIC) to securely communicate with each other and with third-party OPSEC applications. SIC is the process by which MARS Appliance authenticates to the SmartCenter Server and other Check Point components.

SIC uses a shared secret as the seed for negotiating session keys. This shared secret is referred to as an activation key. The authentication and communication setup works as follows:

1. Using a username and password pair, MARS authenticates to the SmartCenter Server and other Check Point components, such as remote log servers. (TCP port 18210 is used for pulling certificate from the Certificate Authority for OPSEC Secured communication)

2. If authenticated, the peers swap the activation key and each other’s SIC (TCP port 18190 /OPSEC-CPMI is used for discovery)

3. If each peer validates the authenticity of the other, the Check Point component establishes an encrypted session over TCP port 18184 with the MARS Appliance. It is over this channel that the Check Point components to sends encrypted log data to MARS. (TCP port 18184 / OPSEC-LEA is used for pulling logs)

Unless these are altered MARS requires access to these ports to the appropriate network device.

Errors associated with initially pulling the Certificate.......

If we enter a Wrong Activation Key, this will produce the following error...

If the Client SIC Name is typed incorrectly (or wrong IP address), will result in the following error....


Errors associated with Discovery.............


Incorrect Access Credentials, or incorrect Client or Server SIC will result in...

Things to Check....

Never try to type in the Client and Server SIC name to the MARS UI. Its very error prone. Use copy/paste from the CheckPoint Management UI if possible.

Always use the CS-MARS CLI’s telnet command to test the connectivity between the CS-MARS and CheckPoint Management/Log Server for all three ports.


Discovery using CPMI
telnet management_server_ip 18190

Pulling the Certificate
telnet management_server_ip 18210

If the management server is also the log server
telnet management_server_ip 18184

To pull logs via LEA
telnet logserver_ip 18184


Use PNLOG
To set the logging level or to view log information at the console, use the pnlog command. This command specifies the logging level of the MARS services, as well as the CheckPoint CPMI and LEA logs received by the MARS Appliance.

The pnlog setlevel cpdebug command sets the output level of the CheckPoint discovery process. You must specify one of three levels: 0, 3, or 9, where 0 disables Check Point debug logging, 3 enables all OPSEC debug logs, and 9 enables all CPMI debug logs.

This command is used together with pnlog show cpdebug command to study the raw output of CheckPoint Discovery (CPMI) and CheckPoint Log (LEA) sessions. Cisco recommends the use of 9 for debugging and 0 when not actively debugging.

ie, To debug OPSEC and pulling the certificate use

[pnadmin]$ pnlog setlevel cpdebug 3

[pnadmin]$ pnlog show cpdebug
[ 14839]@pnmars ckpSSL_InputPending 1 pending bytes
[ 14839]@pnmars ckpSSL_do_read: read 12 bytes

ie, To debug CPMI Checkpoint Discovery use

[pnadmin]$ pnlog setlevel cpdebug 9
[ 15590]@pnmars openssl_lock:ssl_ctx :3076:ssl_sess.c:636

ie, To switch off cpdebug logging

[pnadmin]$ pnlog setlevel cpdebug 0

Other CLI Tools to check for incoming traffic - NETSTAT

The netstat command should display two connections per log server.


[pnadmin]$ netstat -an
tcp 0 0 192.168.8.2:33312 192.168.8.110:18184 ESTABLISHED
tcp 0 0 192.168.8.2:33315 192.168.8.110:18184 ESTABLISHED

Other CLI Tools to check for incoming traffic - TCPDUMP

For Discovery troubleshooting.... (success shown)

[pnadmin]$ tcpdump port 18190
tcpdump: listening on eth0

16:09:03.125529 pnmars.33358 > 192.168.8.110.18190: S 2762771428:2762771428(0) win 5840 (DF)
16:09:03.126988 192.168.8.110.18190 > pnmars.33358: S 679413508:679413508(0) ack 2762771429 win 16384

For troubleshooting Logs being received.... (success shown)

[pnadmin]$ tcpdump port 18184
tcpdump: listening on eth0

16:05:50.650056 192.168.8.110.18184 > pnmars.33312: P 2051260988:2051261993(1005) ack 2397731114 win 16384
16:05:50.650197 pnmars.33312 > 192.168.8.110.18184: . ack 1005 win 32520 (DF)

If all else fails!, make a call with Cisco TAC. :-)