Missing "config-vpn"

[rjpereira]

I'm deployed R80.40 AMI in AWS, with a Transit Gateway integration, that should recognize TGW tags and initiate the configuration of site-to-site VPNs with existing gateways.

I see that on the logs management server issues a "config-vpn" command to gateway, but the reply is "command not found", which I confitm if I login there via SSH.

This config-vpn is also referred in documentation (e.g. https://sc1.checkpoint.com/documents/R80.10/WebAdminGuides/EN/CP_Transit_VPC_for_AWS/html_frameset.h... ).

Does anyone know how to make sure that config-vpn binary is installed on the security gateways ?

Thanks

[G_W_Albrecht]

I would involve TAC here !

[rjpereira]

Problem solved in the meantime, and leaving a suggestion for product team:

On all your sample AWS templates where you configure Security Group ports, you set TCP allow rules for 257, 18191-18192,  18210-18211, 18221, 28264.

You are forgetting to add 18208: without it 

cprid_util -server 10.59.0.28 putfile -local_file /opt/CPcme/features/config-vpn.sh -remote_file /bin/config-vpn -perms 500 with:
data=None
env=None
2020-02-18 10:11:11,267 CME_SERVICE INFO Return code= 3
Output=
Stderr=

, fails for not being able to communicate with the gateway.

It would be much better if Checkpoint published real world templates with strict securitygroup and acl rules that documented requirements, than using always "permissive -1 rules" and not documented it properly....

[chkpyehonatanwe]

Hi rjpereira,

Thank you for your comments.

The issue occurred because the Gateways Security Group that was created by the template, was replaced with the Management Security Group that was created by the template. Meaning, the Gateways and the Management had the same Security Group rules.

The solution templates configure a permissive Security Group for the Gateways, since traffic arriving to the Gateways can be originated from anywhere, for example: the internet, the VPC in which the Gateways are deployed, other VPCs over AWS Transit Gateway and corporate network over Direct Connect.

Therefore, it is impossible to predict the source IP ranges of incoming traffic, and since the Gateways themselves are Firewalls, it is reasonable to allow access to the Gateways from any IP address.

Regards,

Yehonatan

[rjpereira]

I don't agree 100%. I understand that the Cidr ranges may be left open to allow different types of deployment, but you should lockdown the protocol/port rules in network acls and security groups to properly document a secure deployment. Those will not depend on the customer setup.

Cheers