Doubt about SIC between SMS and SG

[fjulianom]

Hi experts,

I have a doubt about SIC between my SMS and SG. I have a cluster of two SGs, currently with interfaces:

eth1: 192.168.1.0/24

eth2:192.168.2.0/24

eth3:192.168.3.0/24

The SMS is in other segment, say 10.10.10.0/24, and has SIC established with SG segment 192.168.3.0/24. Now I am going to migrate the SMS to segment 192.168.2.0/24. I know the SIC should be restarted, but can the SMS start establishing SIC with the SG IPs in segment 192.168.3.0/24 as before, or now the SMS must establish SIC with SG IPs in segment 192.168.2.0/24?

Regards,

Julián

[the_rock]

Think about it this way...any time there is a new network segment, regardless if its for fw or mgmt, both entities need to know how to get there, so routing has to be correct. Therefore, SIC will most likely need to be re-established for this to work.

Now, you can actually reset SIC without having to restart all the services with below:

https://korkutozcan.com/how-to-reset-sic-without-restarting-check-point-gw/

Hope that helps.

Andy

[fjulianom]

Hi Andy,

OK, let's say that the new SMS IP in segment 10.10.10.0/24 can reach the SG IPs in segment 192.168.3.0/24, then the SIC can be established between these IPs?

By the way, about resetting SIC without having to restart all the services, does this mean at the moment of resetting SIC there will be no service interruption for the traffic crossing the SG?

Regards,

Julián

[Chris_Atkinson]

Please refer sk86521

[the_rock · Accepted solution]

Correct Julian. Also, keep in mind below ports need to be opened (which Im sure they are)

https://community.checkpoint.com/t5/Management/A-question-on-SIC/td-p/72356

But, to fully answer your questions, as long as routing is there and both entities (gw + mgmt server) can "talk" properly to each other, SIC has to work. Now, for your other question, correct, it will NOT stop the traffic.

Andy

[fjulianom]

OK, I think there will be no problem. The new SMS gateway will be the SG VIP interface, say 192.168.2.100, so for the SMS to reach the SG IPs in segment 192.168.3.0/24 I only need to configure rules between these two segments and open those ports, and after that migrate the SMS, and then restart SIC.

A collegue told me SIC must be established between the SMS and SG "nearest" interfaces, which mean here the SIC "should be" established between the SMS (IP in segment 192.168.2.0/24), and SG IPs in segment 192.168.2.0/24. But considering all we talked about, SIC can be established between the SMS (IP in segment 192.168.2.0/24), and SG IPs in segment 192.168.3.0/24.

Regards,

Julián

[the_rock]

I will tell you quickly a story. Ages ago, I had a client call me after being so frustrated why SIC was failing every time he would push the policy and literally, after 2 mins of helping him, we realized his route was wrong. I always tell people, no matter what vendor or fw is in question...all you have to wonder is HOW one device will reach the other device. Think arp, think routing, nat...those are 3 things that ALWAYS come to my mind first when troubleshooting anything.

[PhoneBoy · Accepted solution]

When we talk about resetting SIC, usually, it involves revoking existing, valid certificates.
If you’re merely changing IP addresses, this shouldn’t be necessary.

However, what you will have to do when changing IP addresses is re-establish the connections authenticated by SIC.
This is done by changing the relevant objects in SmartConsole and pushing policy to the relevant gateways.
Obviously, this won’t work with your existing access policy since this communication is handled through Implied Rules that won’t be updated until…you push policy.
Which leaves you with two options:

• Add relevant manual rules to the relevant access policies involving the NEW ip addresses before making the changes to the objects.
• Do a quick ‘fw unloadlocal’ to allow the management to push policy from the new IP addresses (will cause an outage).

[fjulianom]

Thanks @PhoneBoy, your answers are always appreciated by a beginner of Check Point like me 🙂

Regards,

Julian

[emmap]

Please refer to sk40993. There's no need to reset SIC when changing IPs, SIC certificates are based on names.

[fjulianom]

Hi guys,

Thanks to everyone for your answers. Now I am confused. You say there is no need to reset SIC when changing IP addresses because SIC are based on certificates, and it makes sense. But sk40993 leads to sk103356 which says the following:

IP Address of the Internal Certificate Authority (ICA) of Security Management Server / Domain Management Server is automatically added to Check Point Registry file ($CPDIR/registry/HKLM_registry.data) on Security Gateway when SIC is first established (between Security Gateway and Management Server).

If the IP Address of Security Management Server / Domain Management Server is changed, and SIC is never manually reset (between Security Gateway and Management Server), then the AutoRenewal of the Certificate will fail.

And this is Check Point official documentation...

Regards,

Julián

[the_rock]

Whil I agree with @emmap , I can tell you I seen people do this before and SIC had to be reset every single time. 

[fjulianom]

Hi,

So this is a dilemma, while some people says it isn't needed to reset SIC, Check Point official documentation says it is... Has this happened to you sometime?

Regards,

Julián

[the_rock]

Yes, thats what I mentioned in my previous response, seem it happen few times before. Think if it this way...when network segment changes, ok, its true SIC is based on names, but if the fw cant talk to new mgmt network subnet, how will SIC work properly? Lets use such a basic example...say both your fw and mgmt are on 10.10.10.0/24 subnet, of course all will work, as ARP will be recognized as there is no need for routing. But then, say mgmt subnet changes to 192.168.10.0/24, how will fw communicate to mgmt? It needs to know how to get there...

Sorry for spelling mistakes, hate typing long responses on my iphone lol

[fjulianom]

Sure, I know routing must be correct if they are in different segments. But it seems SIC is only based on certificates (considering routing and ports are correct, and SMS and SG can talk properly each other). Maybe is what @PhoneBoy says.

So do you mean it happens to you few times and you needed to reset SIC?

Regards,

Julián 

[the_rock]

Correct. But again, thats whole point of what I was saying...IF routing and ports are indeed right, then you would be fine. 

[the_rock]

K, so what I did for you is this...I moved my mgmt server to different network segment and made sure route was there and gateway could reach back and forth and when I tested SIC, it was fine and I was able to push the policy fine.

So, the conclusion is this...AS LONG AS you have correct routes and both entities can communicate, there would be NO need to do SIC reset. 

Even though this was all done in the lab, Im positive same behavior applies to any environment. So, I am sure the cases I mentioned to you before where people had this problem was due to them not actually making correct access/routing changes needed.

[fjulianom]

OK, I will see with my own eyes when I migrate the SMS. Thank you very much 🙂

Regards,

Julian

[fjulianom]

Hi,

Just to let you know I migrated the SMS and I didn't need to reset SIC, everything was fine 🙂

Regards,

Julián