Internal Routing
Each Security Gateway Dedicated Check Point server that runs Check Point software to inspect traffic and enforce Security Policies for connected network resources. instance in the Check Point Managed Instance Group (MIG) automatically routes
RFC 1918
addresses through its internal network interface (eth1
). RFC 1918
subnets in the External VPC do not route through the Security Gateway unless an explicit route is set.
Configuring the Outbound Protection
The Check Point Managed Instance Group can inspect outbound HTTP/HTTPS traffic.
This is useful for:
-
Servers and containers requiring software and image updates from repositories outside the VPC.
-
Virtual Desktop environments in the VPC accessing the Internet.
For MIG versions starting from R81.10
In the diagram below, the internal VPC has routes configured to redirect all outbound traffic through the Internal Load Balancer (ILB Internal Load Balancer, used to load balance traffic in a virtual network). All outbound traffic from hosts and servers in the Internal VPC is redirected to ILB's targets and then for inspection through the Security Gateways in the MIG.
Google Cloud Platform route-based load balancing distributes outbound connection requests among the Check Point CloudGuard Security Gateways instances. The CloudGuard Security Gateways instance receives the request, inspects it, and, if allowed by the policy, sends it to the Internet.
|
Note - A Check Point Security Management Server |
For MIG versions lower than R81.10
In the diagram below, the internal VPC has routes configured to redirect all outbound traffic through Security Gateways. All outbound traffic from hosts and servers in the Internal VPC is redirected for inspection through the outbound Security Gateways MIG.
Google Cloud Platform route-based load balancing distributes outbound connection requests among the Check Point CloudGuard Security Gateways instances. The CloudGuard Security Gateways instance receives the request, inspects it, and, if allowed by the policy, sends it to the Internet.
This is done by configuring multiple routes to 0.0.0.0/0 with the next hop to a Security Gateway in the Managed Instance Group. Google Cloud Platform does not allow setting a Load Balancer as the next hop. As a result, a different route is required for each Security Gateway in the MIG. But when specifying multiple routes to the same target (0.0.0.0/0) with a different next hop (different Security Gateway instances in the MIG), GCP Google® Cloud Platform is a suite of products and services that includes hosting, cloud computing, database services and more. automatically load-balances this traffic, providing redundancy and load distribution for outbound traffic inspection.
Configuration Steps
To configure the outbound traffic inspection, do these steps:
Step 1 - Create a GCP route:
-
In the GCP console, navigate to VPC Network > Routes to create a new route in the internal VPC for the Internal Load Balancer's next hop.
-
Enter a name for the new route. For example:
"ilb-next-hop"
-
Select the internal Network (MIG Backend VPC).
-
Set the Destination IP range to
0.0.0.0/0
. -
For the Next hop, select Specify a forwarding rule of internal passthrough traffic.
Note - A rule
Set of traffic parameters and other conditions in a Rule Base (Security Policy) that cause specified actions to be taken for a communication session. is created automatically with a Health Check.
-
From the Forwarding rule name list, select the ILB's private IP address.
-
Click Create.
Step 2 - (Optional) – Set up the peered VPC:
If more VPCs are peered to the Internal VPC, the custom route redirecting all outbound traffic through the Internal Load Balancer can automatically be exported to the peered VPCs. To enable custom route export, see Peering in the GCP console connection details and make sure that export is enabled on the Internal VPC. In addition, make sure that import is enabled on the peered VPCs.
Step 3 – Create an access rule:
-
Use the Firewall security access policy to limit outbound access from internal subnets:
-
Create a Group object for the subnets (for example, "WebClients").
-
Set up these Firewall security rules:
Source |
Destination |
VPN |
Services & Applications |
Action |
Track |
Install On |
---|---|---|---|---|---|---|
WebClients |
All_Internet |
*any |
*any |
Accept |
Log |
*Policy Targets |
*any |
*any |
*any |
*any |
Drop |
Log |
*Policy Targets |
Step 4 - Create a NAT rule:
The LocalGatewayExternal dynamic object automatically links to the Security Gateway external interface (eth0
). Use the NAT policy to hide outbound traffic from the "WebClients" Group behind the LocalGatewayExternal dynamic object:
Comment |
Original Source |
Original Destination |
Original Service |
Translated Source |
Translated Destination |
Translated Service |
Install On |
---|---|---|---|---|---|---|---|
Needed for East-West traffic |
WebClients |
WebClients |
*any |
= Original |
= Original |
= Original |
*Policy Targets |
|
WebClients |
All_Internet |
*any |
**[H] LocalGatewayExternal |
= Original |
= Original |
*Policy Targets |
Step 5 - (Optional) – Set up outbound HTTPS Inspection rule:
Follow the steps above to set up outbound HTTPS Inspection Feature on a Security Gateway that inspects traffic encrypted by the Secure Sockets Layer (SSL) protocol for malware or suspicious patterns. Synonym: SSL Inspection. Acronyms: HTTPSI, HTTPSi..
Step 6 - Configure Security Gateway blades in CME:
To enable Application Control Check Point Software Blade on a Security Gateway that allows granular control over specific web-enabled applications by using deep packet inspection. Acronym: APPI. and URL Filtering
Check Point Software Blade on a Security Gateway that allows granular control over which web sites can be accessed by a given group of users, computers or networks. Acronym: URLF. blades (refer to Enabling and Disabling Software Blades), run this command:
|
|
Note - To enable HTTPS Inspection, run this command:
|
Replace <CONFIGURATION-TEMPLATE-NAME>
with the name of the configuration template.
Configuring the East-West Protection
The Internal Load Balancer supports symmetric hashing since June 24, avoiding the need for source NAT. The L4 ILB automatically uses a hashing algorithm of the source and destination IP addresses, protocol, and ports to select a specific CloudGuard Security Gateway instance for a specific flow. Thanks to this support, source NAT is not needed for East-West traffic.
In addition, you can use the Check Point Managed Instance Group to inspect East-West HTTP/HTTPS traffic.
In the diagram below, the Peered VPCs have routes configured to redirect the traffic to the Backend VPC. The Backend VPC has a route configured to redirect the traffic through the Internal Load Balancer. All East-West traffic from hosts and servers in the Peered VPCs is redirected to the Backend VPC and then to the Internal Load Balancer's targets. The traffic is redirected for inspection through to the Security Gateways in the MIG and then to the other Peered VPCs.
Refer to Google Cloud > Symmetric Hashing documentation for more information.
|
Note - The East-West traffic inspection does not require additional configuration when outbound traffic is not used. |