Hi,
I am having difficulty understanding how traffic initiated from a VPC makes its way through Cloudguard to the Internet. My environment is Cloudguard IaaS in AWS, using Transit Gateway. Cloudguard is setup for auto-scaling and egress only, to provide outbound internet access to VPCs. We are running R80.40 on the gateways and the on-prem management server. The management station is reachable via AWS Direct Connect. With TGW we use BGP VPNs, etc.
[Client VPC]---[TGW]---[Security VPC with Cloudguard ASG]-->[Internet]
The minimum number of gateways in the autoscaling group is 3, scalable to 6. Each gateway performs NAT using the private eth0 IP, but it is also occurring at the instance level with the public IP associated with eth0:1, which is seen on the Internet.
Observation:
These gateways are all independent. They don't share NAT IPs. Traffic passing through a gateway is NATed with a the unique public IP associated with eth0:1.
My question:
How can session stickiness be maintained for egress traffic through Cloudguard? We see a situation where a single host in the client VPC initiates two TCP connections to a single destination IP on the Internet. The server on the Internet expects these connections to all come from a single public IP. But the two sessions are being sent across different Cloudguard gateways, and therefore have different NAT IPs. The internet server rejects the second connection and the session breaks.
I see articles from Checkpoint about ELBs, but they are always talking about ingress traffic from the Internet. What about egress? If this were a traditional setup with either a single firewall or ClusterXL load sharing and a hide NAT range for egress, stickiness would by based on the IP of the inside host. But here, each gateway is doing its own NAT independently. Is there a solution to this problem (other than asking the vendor to rewrite their app to use cookies or something to manage sessions)?
Ray
