Ingress traffic from internet with CloudGuard for AWS cross AZ cluster for AWS transit gateway

[AK2]

Hi,

I have deployed CloudGuard for AWS cross AZ cluster for AWS transit gateway R81.20

Routing and passing traffic from a spoke VPC to the transit gateway through the cluster and out to the internet works ok using hide NAT

Routing and passing traffic from Azure across a S2S VPN terminating on the cluster, through the cluster, then to the spoke VPC (no NAT) works ok.

I have a requirement for ingress traffic from the internet to public IPs (e.g. AWS elastic IPs) to be directed to the cluster, where the traffic can be NAT-ed to the EC2 instances which are on private IP addresses in Spoke VPCs. This will typically be https traffic on port 443 and will require many (greater than 10) public IP addresses in the production state.

I understand that the CloudGuard cluster public IP "floats" between the cluster members.

I looked into using AWS load balancers however:

1. They will send the traffic with a destination address of the Check Point requiring adding multiple IPs on the Check Point interfaces and static NAT. Still need to know how to add 10 (public) IP addresses on the Cloud Guard Cluster members, so that the public IPs stay with the active member.

2. Return traffic may be asymmetric, if the traffic source IP address is untranslated, the return traffic will exit to the internet via the cluster and the load balancer won't see it.

I am currently reading sk174447 and it hints that ingress traffic isn't a valid use case with Security VPC and TGW, although it doesn't say it's not possible....

Before I scrap what I am doing and choose option 3 in sk174447 is there any way to make Ingress traffic from internet to ec2 instances (through the CloudGuard cluster) work for maybe a dozen webservers?

Thanks in advance

Andrew

[avivs]

Hi AK2,

AWS Cross-AZ Cluster supports 2 ways for North-South traffic enforcement:

1. The ingress routing method
In this method, we are setting the Elastic IPs of the protected hosts on the IGW and configure the routing table to pass incoming traffic to these IPs onto the cluster VIP for enforcement.
This is the recommended way to go as long as the protected hosts are deployed in the same VPC as the cluster - otherwise you will not be able to set these hosts EIPs in the IGW.
The advantage in this method is that you are not limited by the number of EIPs you can publish (max supported by AWS) and you do not need to use NAT.

2. The inbound NAT method
In this method, we are using the cluster's VIP to publish application and using NAT to direct the inbound request to the correct hosts using NAT rules on the cluster.
This method enables you to perform inbound traffic inspection for traffic destined to other (spoke) VPC, utilizing the cluster VPC as a hub,

At this point, AWS Cross-AZ Cluster supports using this method only for the cluster VIP.
Adding support for additional EIPs that will be automatically moved between members on failover is coming soon.

However, if you want to enable inbound traffic enforcement at scale (multiple protected hosts and EIPs in multiple spoke VPCs), I would strongly recommend evaluating CloudGuard AWS GatewayLoadbalancer architecture which sounds more suitable for this usecase 

@DmitryG @RomanK 

Can you advise what are the parameters that lead you to prefer Cross-AZ cluster over GatewayLoadbalancer?

[AK2]

Hi Avivs, many thanks for this. For option 2, the inbound NAT method, what's the expected timeframe for this (additional public IPs) to be released as a feature? If it is a few weeks we might consider it, and we would also like to be early release testers for it 🙂 Cheers, Andrew

[Roman_Kats]

Hi @AK2 
We are targeting the feature release for the end of Q1/beginning of Q2

Thanks

[avivs]

Hi @AK2 ,

We should probably be able to provide this feature as EA (Early Availability) within a few weeks.

We will be able to share a more accurate timeline next week.

Can you please advise why AWS GatewayLoadbalancer architecture does not meet your requirements?

[AK2]

Hi avivs, actually, since this discussion we are looking towards AWS Gateway Load Balancer solution. I just need to get a bit more comfortable with how it works and how to build it 🙂