Create a Post
Kurpeus
Participant

Deploying Cloudguard on AWS with Autoscaling

Hi everyone

I'm trying to deploy a 2 hubs solution (Northbound + Southbound) using internal and external load balancers  (as per Checkpoint Cloud Security blueprint v1.0 and 2.0)  . Inbound traffic flow would be as follow:

<internet> --- <IGW> --- <external LB> --- <CGI farm> --- <internal LB> --- < Web server farm> 

I'm deploying CloudGuard instances (CGis) with autoscaling using Checkpoint's CloudFormation template. I'm finding myself very confused about how to architect the solution since the gateways deployed by the template only have 1 network interface by default. 

I want the topology to be automated so the gateways deployed should be able to be fully operational without any manual intervention. I like the concept of CGI using 2 interfaces as there is a clear demarcation between trusted and untrusted zones. I get that with one interface i could NAT the inbound traffic  from the external load balancer and send it, after inspection, to the internal load balancer but the demarcation line isn't as clean as it should. I could also use an edge association to force the internet gateway to send  all Internet inbound traffic via the CGI which would then forward it to the external load balancer (and back to the CGI) but that means the same traffic is inspected twice by the security gateway .

All the topologies i saw seem to use 2 NICs except for Gateway load balacing which i haven't tried yet. What am I missing here ?

Do I need to architect my own CF template and modify the user-data to create the dynamic object i desperately need for NAT and sec policy ?

 

 

 

0 Kudos
3 Replies
Nir_Shamir
Employee
Employee

Hi,

the CloudGuard ASG template only deploys one interface per GW . this is by design. 

Traffic goes in , inspected, and redirected back out with the same interface to the internal networks.

You basically don't need more then one interface to inspect the traffic .

0 Kudos
Kurpeus
Participant

Hi Nir

 

I get that but in my view it isn't as secure as it should as you then need to use additional features to make sure traffic cannot bypass the security appliance.  It doesn't cost me more to use an additional interface so why not. The topology is also easier to read and comprehend.

Again every topology in the "CloudGuard NS for Public Cloud, Reference Architectures and Best Practices" use two interfaces, a public and private one. 

0 Kudos
Nir_Shamir
Employee
Employee

From my side the two interfaces topology is there because it makes more sense to people when you look at it from above. basically we only need one interface, in any kind of deployment.

if you really need it then you can edit the template and add a 2nd interface.

0 Kudos