- CheckMates
- :
- Products
- :
- CloudMates Products
- :
- Cloud Network Security
- :
- Discussion
- :
- CloudGuard ASG AWS Gateway LoadBalancer HTTPS Insp...
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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:
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Funnily enough this has been resolved as of today..
Issue was a missing route! NAT GW needed a route back to the GWLBe.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Did you install the the CA certificate into the trusted Root CA certificate store on the clients?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi @JoSec
yes i have the blades enabled in the policies/layers:
This is my CME configuration:
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sure, I understand, but that would mean you are not using UserCheck portal blocked messages when doing URL filtering?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Got it. That explains.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@JoSec yes, i did this yesterday unfortunately it did not resolve the issue.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Did you get a resolution?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Funnily enough this has been resolved as of today..
Issue was a missing route! NAT GW needed a route back to the GWLBe.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
OK, that's good. Also, from my own lesson learned, be cautious with NACLs. Thanks for the update.