Troubleshooting Remote Management Issues
This section covers how to troubleshoot issues related to remote management.
7.1 Things to Check When Getting SIC Failures
The most obvious things to check: Is there connectivity? From one module, can you Telnet to the other module on port 18191? If a TCP connection isn't established, is there some sort of router or firewall that might be blocking this communication? Is the firewall itself blocking the communication?
If the firewall has the default filter loaded, try the command fw unloadlocal. This unloads the security policy, so be careful! You will want to load a proper security policy as soon as possible after doing this.
SIC relies on a process called cpd, which is responsible for performing all intermodule communications. The process needs to be running on the firewall modules and listening on port 18211 (netstat can be used to verify this).
The next thing to check is whether or not the modules contain each other's IP addresses and hostnames in the local hosts file (/etc/hosts on UNIX, %SystemRoot%\System32\drivers\etc\hosts on Windows). If the remote module is subject to address translation, add the translated IP address to the hosts file.
The last thing to check is the date and time on the operating systems. Because SIC uses certificates that are time and date based, if one system is configured very differently than the other, relative to GMT, the generated certificates might not be valid. See the next FAQ.
7.2 Syncing Clocks between Firewall and Management
The error message "I am getting the error: SIC Error for getifs: validate: not yet valid" indicates that there is a clock synchronization problem between the management server and the module. The message indicates that the management server clock is ahead of the module's clock and that the module is not willing to accept the management server's certificate because it is in the future and thus not yet valid.
Synchronize the module's clock with the management server's clock and restart the cpd daemon on the module (e.g., fw kill cpd; cpd).
7.3 Establishing SIC with a Module Using Dynamic Addressing
Initially, you should configure the firewall module as if it did not have a dynamic IP address. This means that when creating the gateway object, you specify the module's current IP address. Enter the OTP as normal and initialize SIC. Get the interfaces under the Topology frame of the object. Finally, you can check the Dynamic IP box on the General frame of the gateway object.
7.4 SIC General Failure (Error No. 148)
This usually means there is a connectivity problem between the modules. After checking to see that the remote module is up, go to the module and unload the security policy by typing the command fw unloadlocal. If SIC succeeds, it is likely a problem with your security policy, or the default filter was loaded. You will want to reinstall the security policy as soon as possible after doing this.
7.5 Certificate Authority Errors in a Management HA Configuration
The error "A write operation was executed while Certificate Authority is running in read only mode. Operation failed." shows up only in a Management High Availability configuration.
If the $FWDIR/conf/mgmtha.conf file is corrupted or empty, the primary management server will not be able to extract information regarding the status of the local machine. To ensure that the ICA database does not get corrupted, it is locked into a read-only mode. To resolve this, follow these steps.
Execute cpstop on both primary and secondary management servers.
Remove $FWDIR/conf/mgmtha.conf and $FWDIR/conf/mgmtha_stack from both machines.
Execute cpstart on both primary and secondary management servers.
The preceding steps will cause the primary management server to recreate the files and allow the ICA database to load in a read-write mode.
7.6 Resetting SIC
Once a module is defined in FireWall-1 NG, you cannot change its name. The SIC certificate associated with each managed module is based on the name of the module itself. If you have to change the name of the module, you must generate a new SIC certificate. There may be other reasons when you have to regenerate certificates or reset SIC as well.
To reset SIC between a firewall and a management station, open the appropriate module object in Policy Editor/SmartDashboard, click on the Communication button, then click the Reset button in the Communication window.
To reset SIC on the management server itself, use the command fw sic_reset after you have stopped the management station with cpstop. This command deletes the Internal Certificate Authority, deletes the Management Server Certificate, deletes the Certificates Revocation List, and updates the objects database.
WARNING!
 | This command resets SIC authentication for all modules. Authentication will need to be reestablished for all modules. |
Next, you have to reinitialize the Internal Certificate Authority. This is done via the cpconfig utility in UNIX systems. On Windows, use the Check Point Configuration Tool and select the Certificate Authority tab. Once you have done that and restarted the management station with cpstart, you need to reestablish SIC with each module managed by this management module.
7.7 Forcibly Resetting SIC
There are times when FAQ 7.6 does not result in resetting SIC. The next step is to attempt to revoke your ICA certificate. Use the command cpca_client revoke_cert -n certificate-DN (your DN is listed in the general tab of your management station object under the SIC section). Once you have done this, proceed as in FAQ 7.6.
WARNING!
| Revoking your ICA certificate will disrupt SIC and IKE connectivity and is not recommended. |
A more drastic approach is the following.
Stop the management station by issuing a cpstop.
Remove the $FWDIR/conf/InternalCA.* and $FWDIR/conf/ICA.* files.
Edit $FWDIR/conf/objects_5_0.C and remove the sic_name attribute from the primary management object.
Find the internal_ca object and remove it. It might look something like the following:
: (internal_ca :ca_type (internal) :cacertificate () :cacertsignkey (690f1ea0d466f4b4c09c1ad9) :crl_cache_timeout (86400) :crl_cache_type (Timeout) :crl_http (true) :crl_ldap (false) :dn ("O=snuffleupagus..uf8rzq") :internal_CA_check_CRL (true) :permissions_strings () :permissions_type (None) :type (ca) )Use cpconfig to reinitialize SIC and follow the rest of the steps in FAQ 7.6.
7.8 If All Else Fails, Debug
To enable debugging of SIC, issue the following commands on UNIX, assuming a C-shell-based shell is being used (the default on Nokia platforms).
# cpstop # setenv OPSEC_DEBUG_LEVEL 3 # setenv TDERROR_ALL_ALL 3 # cpd ?d # cpstart
On a UNIX platform with an sh-based shell, use these commands.
# cpstop # OPSEC_DEBUG_LEVEL=3 # export OPSEC_DEBUG_LEVEL # TDERROR_ALL_ALL=3 # export TDERROR_ALL_ALL # cpd ?d # cpstart
On a Windows platform, use the following code.
C:\> cpstop C:\> set OPSEC_DEBUG_LEVEL=3 C:\> set TDERROR_ALL_ALL=3 C:\> cpd ?d C:\> cpstart
These commands tell cpd to write a debug/trace output to the $CPDIR/log/cpd.elg file. Once you've captured what the problem is, type cprestart to bounce FireWall-1 and turn off cpd debugging.
$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 to 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 helpful comments. 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 make rules look more readable.
There are two types of rules: inbound rules and outbound rules. Inbound rules refer 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; the first matching rule is used.
Rules look like this:
<apply-to> ; <peers> ; <ports> ; <services> ; <method>
<apply-to> indicates for whom the rule is relevant, similar to the Install On field in the Policy Editor. ANY means apply the rule on any installation type. Otherwise, a group can be specified. If <apply-to> does not reference the local system, the rule is ignored.
<peers> specifies how the other end of the connection is referred to, which can be listed as a SIC name, an IP address, a predefined 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 that a specific port be used.
<services> refers to the Check Point services for which this rule is relevant. Check Point services are unload, load, db_download, commit, and so on, as well as OPSEC services such as sam, lea, and cvp.
<methods> indicates the methods by which this service is permitted if the first four entries of the rule match. The methods are tried in the order listed, so the most desirable methods should be listed first.
Aliases take the following form:
<name>: <element-1>, <element-2>, ..., <element-n>
Aliases are listed before any rules in sic_policy.conf. There are many predefined aliases already listed in this file.
