Checkpoint SmartCentre SIC


I have migrated from a Windows SCS to SPlat (Different IP) keeping the hostname the same to ensure sic will remain intact

 Re-license via CP-Usercentre as i am using a central license to match the IP of the Smart Centre Server on Splat

If i login via SD should I be able to verify SIC communication to the gateway ? or will have to push the policy to the firewall

Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.


By keeping the name the same, you are ensuring that the ICA certificates remain valid so SIC communication should carry on working fine. You need to make sure that you change both the CheckPoint Object and also that the IP on the underlying OS is correct; please see the CP article below.


# Perform a complete backup of the system.

# As a secondary backup use the upgrade_export utility to perform an export of the SMARTCenter Server. This utility is located in $FWDIR/bin/upgrade_tools/ directory on the SMARTCenter Server. To run this utility simply issue the following command

$FWDIR/bin/upgrade_tools/upgrade_export [filename]

#   Ensure that the system backup as well as the exported configurations are moved to a secure location and MD5 values are verified.
# Log into the SMARTCenter Server using the SMARTDashboard.

# Edit the SMARTCenter Server Object and change the ip address to the new ip address.

# Save and close out of the SMARTDashboard.

# Stop the Checkpoint services by running cpstop.

# Change the ip address on the system's operating system.

# Re-start the Checkpoint services by running cpstart.

# Connect to the SMARTCenter Server using the SMARTDashboard.
Interesting question and not done this for some time.

In essence the SIC comms uses the certs, so IP is not an issue from a purely SIC perspective, however, the implied mgmt rules may have locked down the SIC comms to known mgmt IPs, which on the firewall (before you push a policy) will still be the original SCS.

So to answer your question, I would try to test SIC to see iftis allowed.

If its not allowed, or SIC appears to fail, push the policy then retest.

Note when you migrate the SCS, there are docs and guides for you to follow to change the logs and masters settings etc, to ensure that the firewalls will still take policies and send logs to the new SCS
skywalker101Author Commented:
I have tested SIC Comms with the output below, if I push the policy will it not fail if it's unable to connect on 18191

SIC Status for FWMODULE: Unknown

Could not establish TCP connection with ip address

** Check that CPD is running on Firewall and that TCP connectivity is allowed from SmartCenter server to IP address, Port 18191 **
C++ 11 Fundamentals

This course will introduce you to C++ 11 and teach you about syntax fundamentals.

As above, SIC is based on certs so are IP independent here, but the implied rules on the firewall only allow valid mgmt traffic in from known and valid hosts.

As we have changed the SCS IP address the firewall only knows of the original SCS.  This may cause the firewall to drop the packets due to implied rules.

To double check a couple of things though, SSH onto the firewall and see if port 19191 is open and if CP is running

netstat -na | grep 18191

Should be seen as "LISTENING"

Also confirm that CP is running with
fw stat

Output should show the current firewall policy, interfaces its applied to and the last time the policy was pushed

If both are fine, then push the policy

If it fails, then unload the lcoal policy on the firewall

fw unloadlocal

NOTE, this WILL stop forwarding ALL traffic but i will allow mgmt services to connect

Try to re push the policy

If this still fails, then reset sic at both ends and re push

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
skywalker101Author Commented:
All below is fine from the current mgt1 as the last policy push be from this server to Firewall.

If I do an fw unloadlocal is there quick way of getting the orginal policy back onto the firewall, just as a safety net in case the push to the fw does not work as expected or if i run into licnesing issues etc...  As this is a production network I need to get things working pretty quickly

netstat -na | grep 18191

Should be seen as "LISTENING"

Also confirm that CP is running with
fw stat

Output should show the current firewall policy, interfaces its applied to and the last time the policy was pushed

If both are fine, then push the policy

If it fails, then unload the lcoal policy on the firewall

fw unloadlocal
fw fetch localhost

this will reinstall the last locally stored policy
Check the $FWDIR/conf/masters on the gateway. Make sure it has the new SmartCenters IP address rather than the old.
skywalker101Author Commented:

It will have the old as this will the last policy installed, how do i go about changing it  ?
just use the vi text editor. You can make a backup before if you like or change it back if it doesn't help.

You know you can also lab the environment on on your laptop using vmware and the same Check Point licenses so you can test out the solution before doing it in a production environment.
skywalker101Author Commented:

Will be perform the unload local via ssh and still connectivity to the firewall or will I need access via serial ?
If you do fw unloadlocal then you will invoke the default policy. So yes you could loose connectivity remotely.

This is very unsecure but if you have to do it then:

Remove the default security policy.
#control_bootsec -r

The Enforcement Module is vulnerable to attack, until the Policy is installed. The Enforcement Module would have invoke a default Policy if you had not run "control_bootsec -r". The default policy would have block all traffic from passing through the gateway. It's necessary to remove the default policy if you are administering the server remotely or you would loose the ability to install a new policy. If you have local console access you can leave the default policy intact and then you must run "fw unloadlocal" on the Enforcement Module from the command line before Policy installation.

Open the GUI Client.

Install the Security Policy.

Replace the default security policy.
#control_bootsec -g
skywalker101Author Commented:
fw unloadlocal did the trick, I was then able to push the policy from the new scs
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Software Firewalls

From novice to tech pro — start learning today.