Support Center > Search Results > SecureKnowledge Details
CloudGuard Network Security for AWS Gateway Load Balancer Architecture Options Technical Level
Solution

AWS Gateway Load Balancer (GWLB) is a new type of Elastic Load Balancer intended to simplify the insertion of network appliances into VPC Traffic flows while providing dynamic capacity scaling and HA for appliance failure or maintenance activities.  Check Point CloudGuard Network Security (CGNS) appliances are deployed in an Auto Scaling Group (ASG) targeted by the GWLB Target Group (TG).


GWLB encapsulates the initial source IP Addresses with a GENEVE header to preserve the source IP while performing the Load Balancing operations.  Check Point CloudGuard listens for GENEVE, removes the header, and processes traffic through our standard inspection mechanisms.  When CGNS arrives at a policy decision to allow the traffic, CGNS re-encapsulates with GENEVE and forwards the packet back to GWLB.  Check Point’s CME controller handles auto-scaling group management to automatically add or remove CGNS Gateways from SMS on scale-out or in operations.  Review AWS Blog's for a detailed description of AWS GWLB GENEVE operations.

The related Gateway Load Balancer Endpoint (GWLBe) allows inspection of Inbound, Outbound, and/or East-West traffic based on its placement and use as a next-hop in AWS VPC routing tables. Behind the Scenes, GWLBe uses AWS Private Link to forward all the received traffic to it's parent GWLB for inspection by CGNS. This allows a simple-to-understand per-hop Route Table (RT) behavior to be applied to packets as they are redirected to the Security VPC for inspection at CGNS.

This article list the relevant AWS blog posts on GWLB to learn more and detail use cases and caveats of different AWS Architectures featuring GWLB.

Table of Contents

  • Notes
  • Known Limitations and Issues
  • Prerequisites
  • Licensing Considerations
  • Reference Architectures
  • Security VPC (Standalone)
  • Security VPC + TGW
  • Security VPC + Internet VPC + TGW
  • CME Considerations and Tagging Requirements
  • NLV/ALB vs GWLBe deployment location for Inbound traffic inspection
  • GWLB Failure Scenarios and AZ Considerations
  • SMS/MDS Management of CGNS in GWLB ASG
  • Check Point GWLB CloudFormation Template Nesting
  • Troubleshooting and CGNS Traffic Capture

Notes

  Description Note CFT Admin Guide Use Cases CME
#1 Security VPC Standalone AWS refers to this as a “Distributed Deployment” with GWLEe outside of the Security VPC

 Egress Internet Traffic via EIP

Ingress Internet Traffic via EIP on EC2 or ELB		 Manages CG NS ASG

Creates Objects and rules for inbound/outbound traffic in VPC’s tagged appropriately
#2 Security VPC + TGW AWS Refers to this as a “Centralized Deployment” with GWLBe inside the Security VPC Egress Internet Traffic via NATGW


E/W Traffic		 Manages CG NS ASG
#3 Security VPC + Internet VPC + TGW AWS "Centralized" Deployment w/ Security VPC (GWLB + GWLBe) & Internet VPC (NATGW & optional ALB)   included in this SK Egress Internet Traffic via NATGW

Ingress Internet Traffic via ALB

E/W Traffic		 Manages CG NS ASG

 

Known Limitations and Issues


  1. CG NS Gateways used with GWLB are in bridge mode and therefore cannot support VPN.
  2. Because of GWLB’s inherent hashing and failover mechanisms, Check Point CGNS Gateways used with GWLB do not share FW State tables or flow state information.  
  3. AWS GWLB is not able to handle SSL termination or SSL proxy. For SSL traffic termination in AWS, the use of an ALB is recommended, and its architecture caveats are discussed in this article.  Alternatively, Check Point CGNS supports HTTPS Inspection features described below.
  4. CG NS Gateways used with GWLB are in bridge mode and therefore cannot support the "Use this gateway as an HTTP/HTTPS Proxy" in Non Transparent Mode.

 

Prerequisites


Before proceeding, you should have a solid understanding of Cloud Concepts such as VPC’s, Routing, Security Groups, and Transit Gateway.
Check Point’s Cloud Formation templates deploy a Security VPC and optionally an Internet VPC. We do not deploy AWS Transit Gateway or any customer VPC’s, so they must be deployed and configured to work with a Security VPC. Throughout this article, we will point out additional configurations necessary outside of the CFT’s Check Point provides.
 

 

Licensing Considerations


When choosing a licensing option for CGNS w/ GWLB, it's important to note that you cannot mix licensing options or EC2 Instances sizes in an AWS ASG.  

Licensing Option License Management Scaling Events Includes
BYOL Paid up front to Check Point and managed via SMS/MDS Must have sufficient licenses available on CHKP manager to handle increased instances during a scaling event Blades and features per Check Point Contract
PAYG

PAYG w/ Sandblast Protection		 AWS manages licenses and customers pay via AWS MP.

Option to choose an annual license, which is paid up front, or on-demand/per-hour billed monthly with your regular AWS invoice.		 Annual licenses will be applied first up to the quantity of annual licenses available in the AWS Marketplace account.  Any EC2 instances launched with cores exceeding the available annual licenses will be billed at the hourly rate.

With PAYG, you can pay a reduced rate for your steady state CGNS instances and only pay overage charges during a scale up event.  You can purchase additional annual licenses at any time and they will go into use immediately.		 Premium Check Point Support

 

Reference Architectures

  1. Security VPC Standalone (Distributed GWLBe architecture)

    1. Use case: Outbound and/or Inbound traffic in any VPC with a GWLBe deployed into it
    2. Best for: Small deployments with a limited number of VPC’s (due to the fact that each GWLBe adds per/hour AWS costs) and/or Centralized deployments with only a few VPC’s requiring Inbound traffic inspection
    3. Requirements outside of CHKP provided CFT
      1. Outbound:App subnet VPC Route tables (RT) with 0.0.0.0/0 --> GWLBe
      2. Inbound: Ingress VPC Routing IGW (RT attached to IGW) redirecting inbound traffic from the Internet VPC to the GWLBe
    4. Optional Modifications:
      • IGW can redirect traffic to GWLBe or ALB/NLB first.  For pros/cons of NLB/ALB vs GWLBe location regarding Inbound traffic please see the referenced section below.

  2. Security VPC + TGW (Centralized GWLBe architecture)

    1. Use case: East-West Traffic and Oubound Internet traffic
    2. Best for: AWS environments with a large number of VPC’s using TGW as a central routing mechanism and a requirement for E/W traffic inspection
    3. Requirements outside of CHKP CFT:
      1. Add TGW attachments and ingress TGW RT for Security VPC
      2. Modify egress TGW RT pointing to Security VPC attachment
      3. Add RT entries in Security VPC for any Spoke VPC CIDR blocks to:
        • GWLBe subnet RT
        • NATGW subnet RT
    4. Optional Modifications:
      1. If Outbound traffic is not required, NATGW can be eliminated
      2. The GWLBe and GWLB/CGNS Subnets can be combined to reduce the amount of inventory and/or IP address spaced used
      3. GWLBe can be placed in Spoke VPCs to combined a GWLB centralized & Distributed model and achieve Inbound traffic inspection with all the caveats of Architecture 1
      4. DX/VGW can be attached to TGW and routes propagated to TGW egress RT.  In essence, this treats the DX (on Prem) or VGW (IPSec Attached) traffic like another spoke. 
      5. Further, a Check Point CloudGuard dedicated VPN Cluster can be attached to TGW as another VPC spoke for VPN capabilities while still using the GWLB ASG for all traffic inspection.

  3. Security VPC + Internet VPC + TGW (Centralized GWLBe architecture)

    1. Use Case: East-West, Outbound, and Inbound traffic inspection
    2. Best for: Environments with a large number of VPC’s TGW as a central routing mechanism, and Inbound inspection with an application infrastructure featuring ALBs for SSL Termination
    3. Requirements outside of CHKP CFT:
      • This CFT Includes a Lambda Script to create TGW attachments.  Including the TGW ID in this deployment will create TGW attachments and omitting the TGW ID will skip this step
      • This Deployment requires storing the CFT's and lambda.zip file in your own S3 bucket and specifying the bucket as part of deployment
    4. Optional Modifications
      1. NATGW can be removed for environments with no Outbound traffic
      2. NATGW can be moved into Security VPC, but then Spoke VPC routes will need to be manually added to GWLB subnet RT
      3. Depending on how CGNS is managed (SMS/MDS via Internet/on-prem/AWS DX/etc) the Security VPC GWLB RT may need to be modified.  Please see the section below titled "SMS/MDS Management of CGNS in GWLB ASG" for details on routing with this subnet.
      4. DX/VGW can be attached to TGW and routes propagated to TGW egress RT.  In essence, this treats the DX (on Prem) or VGW (IPSec Attached) traffic like another spoke.
      5. Further, a Check Point CloudGuard dedicated VPN Cluster can be attached to TGW as another VPC spoke for VPN capabilities while still using the GWLB ASG for all traffic inspection.

  4. Additional architecture possibilities

    For more architecture examples and traffic flows, refer to: Check Point CloudGuard Network Security - Integration with AWS Gateway Load Balancer workshop.

    The AWS components involved in the architectures can generally be moved around to suit individual customer requirements.  As long as the per-hop behaviors allow a full bi-directional end-to-end traffic flow for all your use cases, feel free to relocate AWS components as necessary.  Please work with your AWS account team to validate any concerns you may have with a specific architecture.

 

CME Considerations & Tagging requirements

CME Must be updated to Take 138 or higher.  For installing CME on a freshly deployed SMS instance in AWS, you may need to uninstall the CPUSE CME Take 83 version first.

  1. from clish type: installer uninstall<tab> to view installed CPUSE packages, and select the package for CME Take 83
  2. Enter expert mode, and follow the directiosn on SK157492 for installing CME in online mode.  Once installed properly with autoupdatercli, CME will automatically update as new takes are released
Tagging: CME looks for tags on the GWLB and ASG to discovery scale-in and scale-out events.  Be sure there are NO EXTRA x-chkp tags on the instances.  Tags included on the ASG should ne enabled for Tag new instances so they are added to any newly spawned instanced

Instance Key Value
GWLB x-chkp-tags management=<cme_gwlb_controller name>:template=<cme gwlb template_name>:ip-address=<public or private>
GWLB


 x-chkp-toplology

 internal
ASG x-chkp-tags management=<cme_gwlb_controller name>:template=<cme gwlb template_name>:ip-address=<public or private>
ASG x-chkp-toplology internal

CME Requirements:
  1. Ensure CME is provisioned with proper AWS permissions (an IAM role applied to EC2 Instance for SMS in the cloud or credentials for an on prem SMS)
  2. Setup the CME template on SMS per the GWLB Admin guide
  3. Ensure controller and template names match identically

 

NLB/ALB vs GWLBe deployment Location for Inbound traffic inspection & HTTPS Inspection considerations

For Inbound traffic inspection, choose an architecture that supports your specific requirements and application architecture.  The table below indicates architectural choices to handle SSL termination on AWS Elastic Load Balancers,

In addition, CGNS supports HTTPS Inspection with GWLB and can handle SSL decryption itself if properly sized and setup with proper certificate infrastructure.  See SK108202 regarding Best Practices for HTTPS Inspection

 
GWLB Architecture supported Traffic Path Pro Con
IGW --> GWLBe --> ALB -- > App Distributed only IGW --> GWLBe --> GWLB --> CGNS --> GWLB --> GWLBe --> ALB--> App Traffic inspected at CGNS will have original Internet SRC IP TLS/SSL traffic being Inspected will be encrypted
IGW --> ALB --> GWLBe Centralized w/ TGW and an Internet VPC only IGW --> ALB (SNAT) --> TGW -- >GWLBe --> GWLB --> CGNS --> GWLB --> GWLBe --> TGW --> App TLS/SSL traffic being Inspected will be decrypted (due to SSL Termination on inbound ALB)
 		 Traffic inspected at CGNS will have SNAT IP address assigned by ALB

 

GWLB Failure Scenarios and AZ Considerations


By Default, AWS attempts to keep a zonal affinity for traffic, meaning that traffic sourced in an AZ maintains that AZ at each hop.

To remedy this behavior and to provide maximum HA coverage for the CGNS Auto Scaling Group, Check Point recommends enabling Cross Zone Load Balancing on GWLB.  This feature allows GWLB to distribute traffic across all targets in all enabled AZ’s to provide greatest HA coverage.  As described in AWS’s blog post, this feature will result in incurring inter-AZ data transfer charges.  Check Point’s CloudFormation deployments for GWLB enable Cross AZ load balancing by default.

Furthermore, enterprises may choose to deploy the application VPC’s with a mismatch of AZ’s from the AZ’s available in the Security VPC based on their individual requirements.  To solve for a mismatch of AZ’s between application VPC’s and Security VPC, we must enable TGW Appliance Mode on the TGW attachment for the Security VPC.  TGW appliance mode for GWLB is described in this AWS Blog post, and is enabled by default in Check Point’s Cloud Formation Template for Deployment #3 Security VPC with Centralized GWLBe architecture and Internet VPC.  The Lambda function code for enabling TGW Appliance mode can be re-used/extended to include automatic Spoke VPC attachment and route propagation.

AWS CLI Commands for TGW appliance mode
  • describe: aws ec2 describe-transit-gateway-vpc-attachments
  • set: aws ec2 modify-transit-gateway-vpc-attachment --transit-gateway-attachment-id tgw-attach-xyz--options ApplianceModeSupport="enable"

 

SMS/MDS Management of CGNS in GWLB ASG


Depending on location of your SMS/MDS, you may need to adjust Route Tables for the public subnets hosting CGNS instances.  The other Route tables created in reference architectures  (GWLBE, Internet, TGW Attachment) impact customer/application/workload traffic flow via GWLB.  

Check Point management traffic falls outside of the Gateway Load Balancer traffic flow as it follows the VPC CIDR block (local) routing in the Security VPC.  As such, as soon as traffic destined for a CGNS Instance enters the Security VPC, it will take local VPC routing hop and be delivered directly to CGNS Instances (bypassing GWLBe/GWLB).  The CGNS internal routing table defaults all traffic back to the subnet default route, and at this point, the CGNS Public subnet routing table would need a route back to SMS/MDS CIDR/IP range.  This same route would be needed for client reachability to the CGNS instance for features like User Check/etc.

 

Check Point GWLB CloudFormation Template Nesting


  1. Tgw-gwlb-master.yaml
    • Purpose: Create VPCs.  Start here to create new VPC's for Security and/or Internet 
    • Launches:
      1. VPC.yaml
        • Purpose: create VPC w/ public and private subnets
      2. Tgw-gwlb.yaml
        • Purpose: create AWS components in Sec VPC (GWLBe, NATGW, IGW, RT + entries).  Start here to re-use existing VPC's for Security and/or Internet
        • Launches:
          1. gwlb.yaml
            • Purpose: create GWLB – adds GWLB template to userdata
            • Launches:
              1. autoscale-gwlb.yaml
                • Purpose: create ASG, TG, HC, Roles, etc
                • Launches:
                  1. amis-gwlb.yaml
                    • Purpose: lookup current AMI list
                  2. management-gwlb.yaml (optional)
                    1. Purpose: deploy mgmt server
          2. tgw-attach.yaml (optional and only included in Architecture #3)
            • Purpose: Create and invoke a Lambda function to create TGW attachments for Security and Internet VPC

 

Troubleshooting and CGNS Traffic Capture

Tcpdump packet capture done on eth0 will show traffic encapsulated with GENEVE. Viewing the pcap files in Wireshark will show the inner packet IP headers/etc. You can notice each packet shows up in the capture two times. One time as it enters CGNS from GWLB before inspection and another time as CGNS returns the packet to GWLB after inspection (provided CGNS policy inspection results in allowing the traffic).

Support for Check Point CloudGuard with AWS Gateway Load Balancer


For advanced scenarios beyond the solution described in this article, please reach out to your AWS

Solutions Architect/Partner Team, your Check Point Account Team, and/or check the Check Point Support Center.

To get support with an existing Check Point CloudGuard Deployment open a Service Request on Checkpoint.com.

Give us Feedback
Please rate this document
[1=Worst,5=Best]
Comment 

SECURE YOUR EVERYTHING™

©

Copyright | Privacy Policy
Follow Us