SIC troubleshooting

First, some general guidelines (i.e. 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 it's 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, which 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 port 18211 to the firewall module. 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.

4. Clocks are out of sync between firewall and management module. The clocks do not have to match exactly, but they should match within a few minutes. SIC failures can occur if the clocks are not correctly synchronized. 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 it's default gateway, which may be another firewall. This is possible when all firewalls have a direct connection on the network of the management server.

To enable debugging of SIC:

cpstop
setenv OPSEC_DEBUG_LEVEL 3
setenv TDERROR_ALL_ALL 3
cpd -d

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.

$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>

<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.

courtesy of Nokia

< back