./upgrade_import Error: This SmartCenter Server is not Primary.

[comnisad]

Hello Everyone,

I am trying to restore a config from ./upgrade_export and when I run the ./upgrade_import util I get this "Error: This SmartCenter Server is not Primary."

I am running this command from the same server the export came from.

Can anyone help with this matter?

Thanks in advance,
Adam

[northlandboy]

Are you trying to do a restore on an already configured system? Try doing a clean install of Check Point, make sure you say it's a primary mgmt server, and then do a restore.

[comnisad]

Yes I'm trying to restore a config I made before making a policy change. Is there a way to get the ./upgrade_import working without taking the machine down?

[Acidio]

This is a rather brute force method of roll back. When making changes to the policy, why not just save a new version of the database and policy. Much easier and doesn't require a full CP restore.

[comnisad]

This is how we were going about making backups and I was unaware of any other way of doing this. As of now the interface between my management server and the firewall is down. I cannot update the policies from the management server and was thinking of using the upgrade_import since I had done the export in the same fashion.
How can I go about restoring?

[Acidio]

Are you able to log into your management server? If so, are you having problems pushing the policy to the gateway?

If you're having problems pushing the policy, it may be the SIC is broken. In which case you'll need to reset it. Unfortunately doing so interrupts communication out of the gateway. You can test the sic by editing your gateway object, click the communication button, then test sic status. (this is assuming you can get into smart dashboard. Do this test before resetting it - as it may not be the problem.

Another option (again assuming you can log into smart dashboard), try unloading the policy from the gateway and then test the sic- if the sic tests ok, push the policy. This may work - try this before doing the SIC reset also.

Hope this helps. Good luck.

[comnisad]

I can log into the management server.

I cannot push policies to the firewall. I get this error.
"Reason: TCP connectivity failure ( port = 18191 )( IP = 63.243.143.194 )[ error no. 10 ]. "

When testing the SIC connection I get the following error.
Could not establish connectivity... check if CDP ... error

I figured that everything was working because I could still see the logging from the firewall but in the meantime our VPN access had gone down.

I NATted a device behind the external interface of the firewall to get a VPN working and that's when all of this started.

The ip address assigned to the firewall in the nodes is the external address. Should I try and change the IP of the firewall and push the policy to another interface?

[Acidio]

Ok, what I would do (if it's not going to cause you too many issues - ie stopping traffic) is unload the policy from the gateway, retest the SIC - it should work, then push the policy. The error you are getting is related to SIC communication between the mgmt server and the gateway. If you unload the policy, there won't be any policy to prevent the mgmt server from communicating to it.

To unload the policy, log on to the gateway and type "fw unloadlocal" I suggest you find out what the current policy name is so you can do a manual load if you can't push the policy successfully.

[comnisad]

Thanks that seems like it will work.
How do I get the current policy name and load it manually from the gateway?

[Acidio]

Oops, got that manual load suggestion a little wrong. You'll need to do that from the management server, so if management won't talk to the gateway via smart dashboard, you won't be able to a manual load either.

A reboot if the box will reload the policy, however you'll need to be sure that doing this fits within a time window suitable to your business.

Getting back to the restore issue.....

When you make changes to a policy you can save as a different name and install the new policy. Then you'll have the old policy to roll back to. Also, you can create copies of the database. This is useful if you are modifying, adding, deleting objects etc. Check out the CP docs or help for further detail.

Doing this won't stop the situation you currently have though. If you lose connectivity to the gateway, it doesn't matter how many old policies or databases you have to roll back to. Also, an upgrade_import to the mgmt server won't do any good either. You need to focus on the gateway to re-enable comms from the mgmt server.

As mentioned previously, usually unloading the policy from the gateway will re-enable comms from the mgmt server. However if that doesn't work, you may still have to reset the SIC - or in the worst case, rebuild the gateway.

[comnisad]

The fw unloadlocal worked perfectly.

I ran the command on the firewall and the connectivity between the management server immediately started working again. I simply pushed the fixed policy back to the firewall and everything came back up.

Thank you so much for you help, it was greatly appreciated! Think I owe you a beer for this one! Thanks.

[Acidio]

Excellent news.

Beer is always accepted.