Hi,

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.

HTH


# 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

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

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.

Dooglave,

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.

deimark,

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

Caution:
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

fw unloadlocal did the trick, I was then able to push the policy from the new scs