Threat Emulation blade don´t connect to Checkpoint Cloud

[Ronald_Canchica]

Dear, 

I'm trying to implement Threat emulation Blade in Chassis 64k, Especifically in one VS. I followed the steps by sk111405. But as I´m implementing ThreatCloud environment, I didn´t follow the step "7. Perform an Offline Update of the Threat Emulation Engine.".  

When I finished this implementation, VS object in the smartconsole showed next Error message:

Error: Update failed: The Security Gateway cannot download the file.The Security Gateway cannot connect to the Internet. We recommend that you check the network connection and proxy settings

My SMS have R80.10 version. I already checked Internet Connectivity of my VS and SMS. 

I would like to know if is there something that I am missing?

I appreciate your help.

Thanks,

[Daniel_Taney]

Did you check connectivity from vs0? I'm not 100% positive, but I think updates and check-in communications originate from vs0 and not from the vs directly running the blade.

[Ronald_Canchica]

Yes, I already tested it. I also have in the VS inside chassis many blades activated, all of them are working and making update everytime. 

I also enabled Threat Emulation Blade on VS0, although I don´t know if it is necessary, and it showed me the same Error message of VS1.

[Daniel_Taney]

When you say you already checked Internet connectivity, do you mean that you specifically tested connectivity to Check Point services? or just the Internet in general? If just the Internet in general, have you seen or tested this sk article? If you run some curl_cli tests, do you see them passing all the way through? I have an environment with multiple layers of Firewalls between it and in the Internet and had to write explicit rules in those other Firewalls to accommodate the implicit rules allowed in others. 

This also may seem like a strange question, but do you use Geo-location enforcement? If you do, I've seen issues post R80.10 where the Gateways try to reach "c12resolver.ctmail.com". It appears that Check Point's Geo-IP Database places this IP in Hong Kong; which we block. I had to put Geo exceptions in for 103.5.198.210 and 84.39.153.31. The function of those IP's is explained in this sk, but not under the context of the connections failing. 

Since it says this is intended for URL Filtering, it may not be related to your issue at all. But I suppose couldn't hurt to check whether connections to this IP's are being blocked.