Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
cdav
Contributor
Jump to solution

CloudGuard ASG AWS Gateway LoadBalancer HTTPS Inspection

Hi CheckMates,

Currently in the process of deploying a proof of concept environment for CloudGuard in AWS. This deployment is for centralised ingress/egress traffic to the internet and therefore I am using the AWS Gateway Load Balancer to send traffic to the ASG. This means that the gateways have a single interface where traffic is sent and received.

I cannot get HTTPS inspection to work for internet facing traffic. I have followed all the AWS CloudGuard documentation and various posts on this form but I cannot get the traffic inspected. 

I have https configured in the autoprov_cfg template and an outbound CA/certificate exists on the manager and gateways. URL filtering blade is configured and an HTTPS inspection policy exists with two rules (inspect traffic to any address for source host. Bypass inspection for everything else).

Is anyone able to help/advise? 

Screenshots for Access Policy, HTTPS Policy and MGMT/GW status:

access_policy.png

 

hi_policy.png

 

cg_gw_mgmt.png

0 Kudos
1 Solution

Accepted Solutions
cdav
Contributor

Funnily enough this has been resolved as of today..

Issue was a missing route! NAT GW needed a route back to the GWLBe. 

 

View solution in original post

19 Replies
JoSec
Collaborator

Did you install the the CA certificate into the trusted Root CA certificate store on the clients?

0 Kudos
cdav
Contributor

Hi @JoSec 

yes I have. If I hadn’t the client would receive a ssl error as it wouldn’t trust the gateaway. The problem I have is I still get the certificate presented by the remote server and I don’t see any logs to indicate inspection has happened. Logs do confirm the https traffic destined to the internet is being accepted by the gateway but SSL inspection is not happening.

0 Kudos
JoSec
Collaborator

On the properties for HTTPS inspection for each gateway, can you view the certificate and is "enable https inspection" is checked (enabled). Did yu deploy this using the CFT from checkpoint? If you did and you did enabled the blades after using autoprov_cfg, it does not automatically enable it on the gateway. You should terminate the gateway and it will bring up a new instance with the features enabled otherwise you have to do it manually. 

Also, be aware of the limitations of Checkpoint and ASG.

Known Limitations
For CloudGuard Network GWLB solution to support subnets traffic across different Availability Zones, you must enable GWLB Cross-Zone Load Balancing.

Supported Software Blades in Bridge Mode (summary table). See "Deploying-Security Gateway or ClusterXL in Bridge Mode" in the R80.40 Installation and Upgrade Guide.

"Internet" object in SmartConsole is not supported.

The CloudGuard Autoscaling solution does not support Check Point blades portals (for example, User Check portal, Identity Awareness Captive portal, DLP portal).

NAT is not supported on CloudGuard Network Auto Scale Group instances behind Gateway Load Balancer.

Site to Site VPN is not supported.

Remote Access VPN is not supported.

IPv6 is not supported.

 

 

https://sc1.checkpoint.com/documents/IaaS/WebAdminGuides/EN/CP_CloudGuard_Network_for_AWS_Gateway_Lo...

0 Kudos
cdav
Contributor

Hi @JoSec 

I have deployed from the CF template and I did update the autoprov_cfg template to enable URL Filtering & https inspection. Once I had updated the template and CME had restarted I then forced the autoscaling group to terminate existing gateways and create new. These appeared to pick up all the settings correctly as SmartConsole confirms blades are installed and enabled.

You can see from screenshots that i have removed the internet object used in dst for https inspeciton policy. I understand this doesnt work for gateways with single interfaces.

0 Kudos
JoSec
Collaborator

BTW, it does work and I have set this up with the GWLB.  Also, did you go into manage polices, edit, edit the layer and add the blades to the policy. You have probably seen the below URL for the CME which indicates the verbiage for the blades. Per your screenshot you only have Firewall, URL and IA indicated.

 

https://sc1.checkpoint.com/documents/IaaS/WebAdminGuides/EN/CP_CME/Content/Topics-CME/CME_Structure_...

0 Kudos
cdav
Contributor

Hi @JoSec 

yes i have the blades enabled in the policies/layers:

policy_blades.png

 

This is my CME configuration:

Screenshot 2023-10-15 223727.png

 

With the above and an CA configured with a distributed cert and  (inspect all https traffic destined to non private ip address sourced from 10.15.81) I would expect to see logs for https inspection when browsing to the internet from the host but i dont.

If i turn the action of the rule to be an inline layer and create an inline rule with an any/any accept and a url category all internet traffic stops working. The rule has an any/any accept with any app/category below. So there is no reason why the firewall would drop the traffic?

If I run an zdebug + drop on gateways whilst attempting to browse the internet I see no packets dropped by the fw. No logs in smartconsole for accepted/dropped or inspected traffic and the connection will time out. 

However if i remove url filtering rule the traffic will resume but no logs for https inspection. 😞

I am very confused.

 

Thanks,

Chris

 

0 Kudos
JoSec
Collaborator

Did you verify on the gateway object that HTTPS Inspection is enabled and the certificate has been applied? Try creating a test rule without an inline layer (no parent rules). Also, does the management and gateways have an EIP attached so they can get updates and connect to Checkpoint services? 

0 Kudos
abihsot__
Advisor

What is the use case for https inspection if UserCheck is not supported? I thought one of the biggest benefits of https inspection  is the ability to inject blocked message.

 

The CloudGuard Autoscaling solution does not support Check Point blades portals (for example, User Check portal, Identity Awareness Captive portal, DLP portal).

0 Kudos
cdav
Contributor

This will be used to control egress internet traffic from various envs/accounts. having some url filtering and other capabilities will be a handy security control.

0 Kudos
abihsot__
Advisor

Sure, I understand, but that would mean you are not using UserCheck portal blocked messages when doing URL filtering?

0 Kudos
cdav
Contributor

That is correct however its not an issue as all traffic will be server/service traffic and would not require a block page for users.

0 Kudos
abihsot__
Advisor

Got it. That explains.

0 Kudos
abihsot__
Advisor

Just a wild guess, but shouldn't you use application objects in "services & applications" field? Maybe only FW blade is engaged if you have https object there?

0 Kudos
cdav
Contributor

@abihsot__ @JoSec 

This has unfolded.. Abihsot you are correct and i have a rule with a service/app configured. The interesting part here is that once that rule is pushed to the gateways all internet traffic fails. For example if a added a rule to the top as follows:

src:10.1.5.81 > dst:any > svc/app:google search > action:accept/drop

Once policy is installed on the gateways all internet traffic times out whether it matches the rule or not. No logs for dropped or accepted traffic and a zdebug + drop on a gateway shows no acknowledgement of the packets being processed by the fw kernel.
Removing the rule from the policy and installing resumes outbound traffic. 

I had a session yesterday and today with aligned SE and Cloud Specialist to which we were unable to identify anything. A case has now been raised with TAC so I will see how it unfolds.

Thanks for both your inputs. 

0 Kudos
JoSec
Collaborator

After you deployed via CFT did you patch the management to the latest HFA? BTW, I did this on R80.40 Gateways with R81.10 management.

0 Kudos
cdav
Contributor

@JoSec yes, i did this yesterday unfortunately it did not resolve the issue.

0 Kudos
JoSec
Collaborator

Did you get a resolution?

0 Kudos
cdav
Contributor

Funnily enough this has been resolved as of today..

Issue was a missing route! NAT GW needed a route back to the GWLBe. 

 

JoSec
Collaborator

OK, that's good. Also, from my own lesson learned, be cautious with NACLs. Thanks for the update.

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.