The Latest Check Point News
Product and Solution Information, Press Releases, Announcements

By Jonathan Maresky, CloudGuard Product Marketing Manager, published November 10, 2020

Cloud security is not a trivial practice of “click-and-deploy”, “one-size-fits-all” or even “my cloud vendor is responsible for cloud security”. The shared responsibility model is a critical component of a cloud user’s ability to protect their organization’s cloud assets in the long term and perhaps even before then.

Cloud vendors understand these customer needs and provide new services and capabilities to enable their users to design secure cloud deployments and continuously improve their cloud security posture.

Earlier today, Amazon Web Services (AWS) announced its launch of AWS Gateway Load Balancer (GWLB), a new cloud service that makes it easy for customers to deploy, scale and manage multiple inline network virtual appliances for many networking purposes. AWS customers are thus able to deploy these virtual appliances with high availability, scaling, and load balancing while using the rich features from the appliances and appliance vendors.

One example of such a virtual appliance is a CloudGuard security gateway. Check Point CloudGuard Network Security is participating in the launch of Gateway Load Balancer with the integration of CloudGuard Network Security and Gateway Load Balancer.

“Check Point’s integration with AWS Gateway Load Balancer can simplify how customers run network appliances in the cloud,” said Dave Ward, General Manager of Elastic Load Balancing, Amazon Web Services, Inc. “Customers will be able to benefit from CloudGuard’s advanced threat prevention technologies in a more scalable and highly available way.”

This blog post provides some insight into the value that Gateway Load Balancer provides, how CloudGuard integrates with Gateway Load Balancer, and how AWS customers can use CloudGuard to add an additional layer onto their AWS security.

What is CloudGuard and how does it further enhance your AWS security?

Check Point is a trusted cloud security advisor for thousands of customers globally, including organizations migrating their workloads to AWS and securing these cloud assets and workloads.

Check Point CloudGuard provides unified cloud native security for all your assets and workloads, giving you the confidence to automate security, prevent threats, and manage posture across your cloud deployments.

Cloud Network Security is one of the CloudGuard capabilities and provides advanced threat prevention and automated network security through a virtual security gateway, with unified security management across all your cloud and on-premises deployments. AWS customers use CloudGuard to securely migrate on-premises workloads to AWS and protect these assets with advanced security technologies including Firewall, IPS, Application Control, IPsec VPN, DLP, Antivirus and Anti-Bot. Threat Extraction and Threat Emulation provide industry-leading protection from zero-day attacks.

CloudGuard promotes automation of processes using APIs and supports Infrastructure As Code practices.

Additionally, CloudGuard provides security teams with Unified Security Management of all their hybrid and on-premises deployments from a single pane-of glass. This promotes consistency of security policies across AWS and hybrid-clouds and is much more efficient than using one management console for each deployed cloud.

CloudGuard integrates with a wide range of AWS services including AWS Security Hub, VPC Ingress Routing, Transit Gateway, Traffic Mirroring, CloudFormation and many others.

What is GWLB and what value does it provide AWS customers?

GWLB combines the functionality of a L3 gateway and a L4 load balancer, allowing customers to transparently insert virtual network appliances like firewalls, deep packet inspection appliances and URL filtering devices.

The diagram below explains the flow and functionality of the GWLB.

AWS Gateway Load Balancer- Flow and Functionality (source: AWS)

Traffic that would otherwise flow from source directly to destination is routed to the GWLB using route tables. GWLB has a frontend, which faces the traffic source and destination, and operates in bump-in-the-wire mode, acting as the next-hop gateway, with no packet rewrite.

GWLB’s backend, which faces the fleet of virtual appliances, operates as a load-balancer for routing traffic flows to and from one of multiple equivalent target appliances. GWLB ensures stickiness of flows in both directions to target appliances, performs regular health checks of the appliances, and reroutes flows if the selected appliance becomes unhealthy.

GWLB receives a traffic packet, processes it at layer 3, encapsulates it with a Geneve protocol (Generic Network Virtualization) encapsulation and sends it to the appliance without any change to the original traffic packet (also known as “packet-in, packet-out”). This is in order to achieve transparent forwarding.

It is important to explain an additional component of GWLB: the GWLB Endpoint (GWLBE). The GWLBE (one GWLBE per VPC) behaves as a mirror image of a GWLB’s frontend, thus acting as the next-hop gateway for each subnet that needs traffic inspection, different from the VPC that hosts the corresponding GWLB. Thus, the GWLBE enables deploying multi-tenanted traffic filtering service in a Service Provider VPC (different from the VPC/s of the GWLBE/s).

The diagram below shows a simple architecture with GWLBE.

Access via GWLBE (source: AWS)

GWLB thus allows users to design fault-tolerant architectures in an easier and more intuitive way, specifically regarding the addition of multiple virtual appliances. Additionally, it allows IT teams to maintain consistent security practices between in-cloud and on-premises deployments, to leverage the existing skill-set of security engineers who understand and trust these security appliances, and to expand existing technology investments and relationships with their preferred and trusted security appliance partners.

This blog post is not a full explanation of GWLB – readers who would like more detail should read the GWLB launch announcement.

How does CloudGuard integrate with GWLB and how do customers use this?

The first requirement for the integration was to support the Geneve protocol encapsulation/decapsulation and to add the capability to configure a Geneve tunnel for receiving/sending traffic from/to the GWLB. This allows GWLB to keep the original packet intact and make no changes, the fundamental requirement for a transparent behavior.

The second requirement is the ability to encode and decode GWLB metadata (e.g. source and destination of traffic) that GWLB adds to the newly encapsulated packets for use by CloudGuard gateways to make intelligent decisions e.g. whether to inspect, block or allow the traffic packet. GWLB embeds the metadata in form of Type, Length, Value triplets (TLVs). CloudGuard can parse and consume the TLVs (and return the packet with the TLVs intact).

To understand how CloudGuard and GWLB/GWLBE interact for inbound Internet traffic using ingress routing, please consider the demo environment used before launch, in the diagram below.

Demo environment to show inbound Internet traffic with ingress routing, GWLB and GWLBE

The demo environment has two VPCs: The Customer VPC (left side) and the Security VPC (right side).

The customer VPC has two subnets: the top subnet is for the GWLBE and the bottom application subnet is for the web server. The VPC also includes an Internet Gateway with route tables defined for Ingress Routing.

The Security VPC also has two subnets: the top subnet includes the GWLB and a CloudGuard Network Security gateway, and the bottom subnet has a Check Point Unified Security Management server (although this can be located anywhere in your cloud deployment, in another public or private cloud deployment or even installed on a physical device on-premises).

The Internet Gateway has a route table that directs routes for the application subnet through the GWLBE. This is how we enforce ingress routing through the GWLBE for incoming traffic from the Internet Gateway. (Note that this demo environment is to show inbound traffic, however GWLB supports inbound and outbound traffic.) Thus, traffic from the Internet to the web server is routed from the Internet Gateway to the GWLBE, and moves from there to the GWLB. The GWLB encapsulates the packet and forwards to the CloudGuard security gateway for inspection in the Security VPC. If the traffic is allowed, it is returned via the GWLB to the GWLBE and from there to the web server. Note that the traffic is transparent to the user and the application during the entire process with no need for source NAT.

The benefits to customers include:

• Reduced network complexity because there is no need for traffic translation (the original source and destination are not changed) and traffic inspection is transparent.
• Ease of use during and after deployment, because deployment can be completely automatic, and traffic inspection is enforced flexibility using subnet tags.

And everything functions as expected.

During our beta testing, we presented the integration between GWLB and CloudGuard to a Check Point customer: a large multinational financial services company with a large and extensive AWS deployment. Their head of Cloud Security Engineering said, “We’re very excited about AWS Gateway Load Balancer. It simplifies a lot of the designs that we have to consider for our solutions today.”

Check Point leadership also spoke about AWS’s new service and the integration with CloudGuard:

“AWS continues to deliver advanced cloud services to respond to customer needs and help organizations build secure cloud deployments”, said Itai Greenberg, VP Product Management at Check Point Software. “We are pleased to be integrated with AWS Gateway Load Balancer at launch; this will simplify the design of cloud architectures and allow customers to use CloudGuard’s advanced threat prevention technologies in an easier and more intuitive way”.