topic Re: A question on SIC in Firewall & Security Management

A question on SIC

Nick_Doropoulos — Wed, 15 Jan 2020 17:10:31 GMT

Considering that SIC uses certificates can I confirm that there is no keep-alive mechanism involved in the protocol at all (in the sense of the manager sending any keep-alive packets to the gateway at a certain frequency)?

Please note that this question is purely educational and that there is no issue that needs to be resolved.

Thanks in advance.

Re: A question on SIC

Martin_Valenta — Wed, 15 Jan 2020 20:39:11 GMT

Over SIC it's simply management talking to gateways and pulling/pushing data.

Re: A question on SIC

FraP — Wed, 15 Jan 2020 21:00:08 GMT

keepalive for what?
this can help you if i get your question fine...

https://sc1.checkpoint.com/documents/R80.20_GA/WebAdminGuides/EN/CP_R80.20_LoggingAndMonitoring_AdminGuide/html_frameset.htm?topic=documents/R80.20_GA/WebAdminGuides/EN/CP_R80.20_LoggingAndMonitoring_AdminGuide/204500&anchor=o160533

Re: A question on SIC

HeikoAnkenbrand — Wed, 15 Jan 2020 22:44:54 GMT

Here a small picture for "Secure Internal Communication" between Security Management Server and Security Gateway.

SIC is used for the following policy install, get topology,...

More read here: R80.x - Ports Used for Communication by Various Check Point Modules

Check Point components communicate with each other using SIC. SIC is based on SSL with digital Certificates. When a Security Management Server is installed, a Certificate Authority (CA) is created. The CA issues Certificates for all components that need to communicate with one another.

For example, a remote Security Gateway needs a Certificate from the Security Management Server before a Security Policy is installed, or before a license can be attached to the Security Gateway. Whenever any two entities in a site (Security Management Server, Security Gateway) need to communicate, the sic_policy.conf file is referenced.

Communication takes place over the Check Point communication layer. This channel is encrypted in various ways. This layer can be called the SIC layer. The SIC ports used are:

Port 18209, which is used for communication between the Security Gateway and the CA for status, to issue, and revoke.
Port 18210, which is used to pull certificates from the CA.
Port 18211, which is the port used by the cpd daemon on the Security Gateway to receive the Certificate (by clicking "Initialize" in SmartDashboard).
Port 18191, which is used for policy install,... ( More read here: R80.x - Policy Installation Flowchart )
Port 18192, which is used for get topology,...
Other ports...

PS:
There is no keep-alive mechanism involved.

Re: A question on SIC

Uchiha_Itachi — Sun, 05 Apr 2020 12:33:53 GMT

Hi,

Could you please explain difference between the two steps 18210 and 18211

It seems 18211 is sufficient since this would allow to push certificates from ICA (SMS) to Security Gateway...

You said that port 18210 is used to pull certificate from CA, and I am just wondering why do we need this since security Gateway could receive certificates from SMS (port 18211)

what am I missing??

Thank you

Re: A question on SIC

spottex — Wed, 26 Aug 2026 00:49:11 GMT

This is the question I have right now and looking for actual evidence specifying it. You push it from the manager, If that has an issue try and pull it down from the firewall.

But is there a need for the gateway to respond to a push with a pull to complete an initial SIC comms?

Looking for documentation and not sk97833. As that is just CP talk to cover them which is enable it anyway.

Our configuration has another FW between the gateway and the Manager which does not allow 18210 traffic. SIC did not complete and we had to roll back to previous snapshots before we realised this is the possible fix.

A few say yes it is needed, But looking for evidence that states it. Our VSX update to a new major version is 2 month approval and a 8 hour process so really want to have it acknowledged because if we do the change again and it fails we are out another month or two.

Update but not conclusive. I'm still keen to find the evidence:
I just read a CM post where a new SIC request was failing, but once 18210 was allowed their SIC issue was fixed.

Re: A question on SIC

PhoneBoy — Wed, 26 Aug 2026 20:01:00 GMT

When you establish SIC with non-Check Point devices (e.g, OPSEC clients), it requires a connection to TCP 18210: https://support.checkpoint.com/results/sk/sk93538
The "pull" in this case is for the certificate issued by the ICA, which is generated as part of the SIC process.
That's why we list this as a requirement in sk97833.

Re: A question on SIC

spottex — Tue, 29 Sep 2026 22:54:00 GMT

I did find some traffic in our latest attempt to upgrade VSX. 18210 was used and was failing when blocked. I believe it is used for the virtual systems as it has a weird way to reinitialize and reconnect SIC outside of the VSX0 SIC process.