Home Page | Skip to Navigation | Skip to Content | Skip to Search | Skip to Footer
 Support Center > Search Results > SecureKnowledge Details
Support Center
 Print    Email
How to debug SIC problems

Solution ID: sk41513
Product: Security Gateway
Version: NG AI R56
Date Created: 19-Apr-2009
Last Modified: 26-Aug-2013
Rate this document
[1=Worst,5=Best]
Solution

SIC (Secure Internal Communication) has taken the place of fw putkey in the NG release of FireWall-1. SIC can sometimes go out of sync or be "broken" for one reason or another. The following article explains how to debug problems with SIC.

Some general guidelines (things to check before enabling debugging).

1. SIC relies on a one-time password (OTP) for initial authentication before certificates are pulled. The management console define its individual firewall modules in the Policy Editor application. At that time, they establish an OTP. On the firewall module itself, the OTP is specified via cpconfig. These OTPs need to match.

2. SIC relies on a process called cpd that is responsible for performing all inter-module communications. The process needs to be running on the firewall modules and listening on port 18211 (netstat can be used to verify this).

3. The "Default filter" that gets generated on the firewall module when it is first installed should permit access via TCP port 18211 to the firewall module. Also TCP port 18209 should be permitted from the firewall module to the management station. However, a later policy might block access to SIC, specifically if you disable the "Accept FireWall-1 Control Connections" property. In this case, make sure your policy permits access from your management module to your firewall module via port 18211 and from your firewall module to management station on TCP port 18209.

4. SIC failures can occur if the
firewall and management module clocks are not correctly synchronized. The clocks do not have to match exactly, but they should match within a few minutes. Both your management module and firewall module should synchronize to an external time source via NTP.

5. If using multiple firewalls running VRRP, try to make sure that the management server routes all interface addresses of any firewall directly to the machine itself, instead of routing it to its default gateway, which may be another firewall. This is possible when all firewalls have a direct connection on the network of the management server.

Troubleshooting SIC

Once you have verified these things, you can use the following commands to troubleshoot:

nokia[admin]# cpstop

nokia[admin]# setenv OPSEC_DEBUG_LEVEL 3

nokia[admin]# setenv TDERROR_ALL_ALL 3

nokia[admin]# cpd -d

From a different shell, run:

nokia[admin]# cpstart


This tells cpd to write a debug/trace output to the $CPDIR/log/cpd.elg file. Once you've captured what the problem is, use ctrl-c to terminate cpd. Then type 'cpstart' to restart cpd.

To debug this on a Windows management station,

C:\>cpstop

C:\> set OPSEC_DEBUG_LEVEL=3

C:\> set TDERROR_ALL_ALL=3

C:\> cpd.exe -d

C:\> cpstart


The debug file will be stored in C:\Program Files\CheckPoint\cpshared\5.0\log\cpd.elg

The cpd_admin utility can be used to debug cpd as well.

To turn on the cpd debug:

nokia[admin]# cpd_admin debug on TDERROR_ALL_ALL=5

nokia[admin]# cpd_admin debug on OPSEC_DEBUG_LEVEL=3

 

The debug output is written to $CPDIR/log/cpd.elg.


To stop cpd debug:


nokia[admin]# cpd_admin debug off TDERROR_ALL_ALL=0

nokia[admin]# cpd_admin debug off OPSEC_DEBUG_LEVEL=0

How to know if SIC works?


Follow these steps:  

  • Open the object in the GUI, and enter the "Communication" dialog. Check that the status is "Initialized and Communicating".
  • On the module: check that you have the file .../cpshared/conf/sic_cert.p12
  • On the module: check in the Registry that in HKEY_LOCAL_MACHINE\SOFTWARE\CheckPoint\SIC you have the entry "HasCertificate" with the value: 1.

If all the answers above are positive, it means that system thinks the SIC is ready. This doesn't mean other problems won't happen. For example, clock gaps can fail the SIC certificate validation. Therefore it is important to collect as much info as possible, not only from the GUI console, but also from the debugging error messages of the process. For example, try to install a policy on a remote module using fw load -d  or even run fw stat -d module_name and see what happens.

sic_policy.conf


$CPDIR/conf/sic_policy.conf is akin to $FWDIR/lib/control.map in FireWall-1 4.1 and earlier. It defines the policy that the module follows for communication via SIC (i.e. who can authenticate with what and how do I authenticate when connecting). From the cpd debug above, you might uncover a mismatch in authentication. Editing this file might allow you to resolve that issue.


The sic_policy.conf file contains lots of comments that are helpful. However, there are two basic types of entries you will see: rules and aliases.

  • Rules determine who can do what.
  • Aliases give you a nice way to group multiple items together (think "groups" in the Policy Editor) and are used to make rules look more readable.

There are two types of rules: Inbound rules, and Outbound rules. Inbound rules refers to connections coming from external hosts (i.e. I am the server and a client is connecting to me). Outbound rules refer to connections being established to external hosts (i.e. I am the client connecting to a server). Rules are listed and enforced in order and the first matching rule is used.

Rules look like the following:

<apply-to> ; <peers> ; <ports> ; <services> ; <method>


These elements are described as follows:

  • <apply-to> refers to "whom the rule is relevant for," similar to the "install-on" field in the Policy Editor. "ANY" means apply on any installation type. Otherwise, a group can be specified. If the apply-to does not reference the local system, then the rule is ignored.
  • <peers> refers to "what the other end of the connection is referred to as," which can be listed as a SIC name, IP address, a pre-defined alias, a group defined in the objects database, or a user-defined alias.
  • <ports> refers to the port on which the server listens. This is usually left as ANY because security requirements usually do not dictate a specific port be used.
  • <services> refers to the Check Point services this rule is relevant for. Check Point services are unload, load, db_download, commit, etc, as well as OPSEC services such as sam, lea, cvp, etc
  • <methods> If the first four entries of the rule match, then these are the methods by which this service is permitted. The methods are tried in the order they are listed, so the most desirable methods should be listed first.

Aliases are of the form:

<name>: <element-1>, <element-2>, ..., <element-n>


Aliases will be listed before any rules in sic_policy.conf. There are many pre-defined aliases already listed.


Related Solution(s): sk30579.


Imported from Nokia support database
This solution is about products that are no longer supported and it will not be updated
Give us Feedback
Rate this document
[1=Worst,5=Best]
Additional comments...(Max 2000 characters allowed)
Characters left: 2000