Newly deployed AWS Security Gateway installs policy but times out on SMS

[israelsc]

Hello everyone,
I hope you are doing well.

Yesterday we deployed a Security Gateway on AWS for one of our customers.
We complete the configuration (hostname, DNS, NTP, etc) and configured a new policy package for the firewall.

When we installed the policy, we monitored with “fw stat” on the firewall and observed that the policy was installed, but on the SmartConsole side we got a policy installation error.

In the firewall, we observe that the policy is installed:

In the SMS we see the following error when the policy installation timeout is reached:

Gateway: AWS-Gateway
Policy: Policy-package
Status: Failed
- Installation failed. Reason: Due to a timeout value of 600000 (millisecond) (port=18191) (IP=x.x.x.x), Security Management Server aborted the connection with the peer.

We found the following SK but it only mentions that there may be a slow connection between the SMS and Firewall and therefore the timeout
https://support.checkpoint.com/results/sk/sk138172

But this is strange, because it is a firewall that we just implemented yesterday and we have not been able to register with the Management Server. And also, it is outbound with IGW from AWS, which makes us almost rule out that it is a network speed issue.

Security Gateway has the latest JHF: JHF GA Take 156
Management Server has JHF: JHF GA Take 129

I have tried to reset SIC but I get the same result.

What else can I do?
Would it be worth to align the JHF version between SMS and FW?
What else can we check?

Greetings to all!

 

[Jeff_Engel]

Hi @israelsc 

Where is your Security Management deployed?  It is likely that there is an NSG blocking or that your Mgmt is behind NAT which we need to account for.

Best Regards!

Jeff

[israelsc]

Hello Jeff!

SMS is deployed on AWS as well
The IP that appears in SmartConsole for the SMS object, is the private IP of the Public subnet of that VPC.
and we reach that SMS by SmartConsole through the public IP that is managed in AWS and linked to that private IP.
In the SMS object in SmartConsole, there is no NAT configuration for that private IP <=> Public IP relationship.

It is worth mentioning that, the SMS is in a VPC in one AWS Account and the firewall is in another VPC in another AWS Account.

The firewall has its own Public IP and reaches the SMS through the public IP of the SMS.

On the Check Point side is there anything else I can check?
I comment because the customer is the one who has access to AWS and would have to ask him to check the NGS, although I do not think it is necessary because, there are already other AutoScaling GW also from AWS managed by this same SMS and these firewalls if they work well, the problem is only with this new firewall.

Regards.

[Jeff_Engel]

Couple of basic questions that might help pinpoint the issue.  Are you getting logs from the firewalls?  I assume no?

The working Autoscaling GWs are likely also in a separate VPC than the new GW?

[israelsc]

Hello Jeff,

We only received logs from the AutoScaling GWs, they are working correctly since their deployment.
We do not receive logs from the new AWS Single Security Gateway (the new firewall).

The Autoscaling GWs and the SMS are in the same VPC.
In fact we use this CFT template to deploy those appliances:
>>"AWS CloudFormation Templates - https://support.checkpoint.com/results/sk/sk111013"
>>Section: CloudGuard Network for AWS Auto Scale Group
>> Deploys an Auto Scaling group of Security Gateways into an existing VPC.
>> Launc Stack: https://console.aws.amazon.com/cloudformation/home#/stacks/create/review?templateURL=https://cgi-cft...

Regards!

For the simple AWS Security Gateway, we use the CFT:
>> Section: CloudGuard Network for AWS Single Gateway
>> Deploys a Security Gateway into an existing VPC.
>> Launch Stack: https://console.aws.amazon.com/cloudformation/home#/stacks/create/review?templateURL=https://cgi-cft...

This is why:
-SMS and AutoScaling GWs are in one VPC.
-Firewall is in another VPC

[the_rock]

I cant say I had ever seen scenario like that, whether be on prem mgmt, cloud one, Azure or AWS, its first one for me. Personally, I would make sure there is communication between mgmt/gateway, because its strange SIC issue comes up, yet from command line, as you showed, fw stat indicates updated policy.

Just wondering, can you make full bidirectional rule for mgmt/gw access for any service and try apply that policy see what happens?

Something like src : gw + mgmt, dst - same as src, service any, accept, log

Andy

[Jeff_Engel]

Ok, I have similar setup in one of my labs.  The new firewall must have an allow all NSG for inbound and outbound traffic since we are trusting it to be a proper firewall anyway.  Secondly, you need to create a dummy Check Point Host object (I usually call it Mgmt-Logger) , enable Logging & Status on it, and set it's IP address to be the Public IP address aliased to your Security Mgmt server.

Then, for that new GW you need to edit its Logs properties to point at this dummy object so that logs and alerts can make it back to Security Management.

Hope that makes some sense.  I can provide screenshots if needed.

BR!

Jeff

[israelsc]

Hi Jeff,
Sounds good to try.

It would be very helpful if you could help me to share the AWS NSG settings and the checkpoint configuration regarding the dummy object.

I would appreciate it very much
Best regards.!

[Jeff_Engel · Accepted solution]

Here are the Check Point dummy object configurations for logging and return communications to Security Mgmt...

A security group should exist that is exclusive to the GW as it is wide open like this...not a great screenshot but I think you will understand.

[israelsc]

Hi Jeff, that's the solution!

I created the dummy object as you said and I see that now I can install policies without problems and also, the firewall is already showed correctly in the SMS.

Thank you very much for your help!
Best regards.

[Amir_Senn]

On the upcoming version we'll have a new feature called MGMT behind NAT that will add new options for defining NAT IPs that is very suitable for AWS gateways. Main issue is that if not all component on the same VPC, you might have a situation that some of the resources need to communicate with private IP and some with public IP.

[israelsc]

Hello Amir,

Thank you very much for the comments, these previews of future versions are appreciated to comment to our customers about new developments.

Greetings to all!