LinkedIn
Twitter
Special thanks to Ghaleb Al-habian and Susan Wu for the tech and editorial review.
Cloud NAT, Google Cloud’s managed network address translation service, lets your workloads in Google Cloud make outbound connections without exposing them to the outside world. However to further secure workload egress traffic, a lot of our customers have requirements to inspect and apply network security policies on egress packets. We are excited to share about how Google Cloud provides an easy way to secure your network access using Cloud NAT and Cloud Next Generation Firewall (Cloud NGFW) or Cloud NAT with 3rd party firewalls.
Benefits of using Cloud NAT and Cloud NGFW together
When you use Cloud NAT and Cloud NGFW together, you get the following benefits:
- Secure outbound connections: Cloud NGFW rules are evaluated before Cloud NAT for egress traffic, so you can be sure that only authorized traffic is allowed to reach the internet.
- Fixed source IP: Cloud NAT allows you to use specific allowlisted NAT IP’s per destination - allowing easier management on the destination for ingress control.
- Block inbound connections: Cloud NAT automatically blocks unauthorized inbound access to workload VMs secured by native firewall or VM appliances running third party firewalls, thus maintaining the isolation, privacy and security of your Google Cloud VPCs.
Cloud NAT integration with Cloud NGFW
Both Cloud NAT and Cloud NGFW are distributed managed services that help you implement network security at scale. This integration allows you to address your requirements (listed below) to control traffic and secure their private workloads connections to the internet.
Allow and deny egress traffic based on destination address and ports
Most of us are interested in controlling traffic using firewall policies on egress packets with the original source IP. Google Cloud Firewall is a fully distributed, stateful inspection firewall that is built into the software-defined networking fabric and enforced for each workload.
This integration has two benefits:
- Cloud NGFW rules are evaluated before Cloud NAT for egress traffic
- Cloud NAT nor Cloud NGFW require route table changes
The destination IPs on the internet which can be communicated by Google Cloud workloads need to be allowed on Cloud Firewalls first. By default, Cloud NGFW rules and Cloud Firewall policies allow all egress traffic, including internet bound traffic. However, in cases where the default egress rule is removed or an explicit deny rule is set in place, explicit allow rules would be required to access the internet. Once traffic has gone through the Cloud NGFW successfully, it hits the Cloud NAT, where source NAT takes place and traffic is routed towards the internet.
A simple way to visualize the traffic flow from a instance in Google Cloud to internet is to consider following steps in sequence:
- Traffic is initiated from a private Google Cloud instance with a private IP
- Traffic is processed through appropriate Cloud Firewall rules
- A routing decision is made using the VPC routing table
- Cloud NAT is initiated to translate the Private IP to a Public IP address
You can use the Google Cloud Connectivity test (see sample result below) in troubleshooting the cause of traffic drops in such a scenario and visualize traffic flow.
The source IPs used in communication to the internet can be fixed to accommodate Public IP allowlisting at the destination.
A VM without an external IP address, in a subnet served by a Cloud NAT gateway, uses a NAT IP address when it sends packets to a destination on the internet. Cloud NAT allows its users to either use automatically allocated public IP addresses or create and manually assign static (reserved) regional external IP addresses to Cloud NAT gateway. This static public IP address can be allowlisted on destinations on the internet.
For handling multiple destinations Cloud NAT offers destination-based NAT rules which allow users to assign specific NAT IP addresses for different destinations.
Connections initiated from the internet should not be allowed to access private workloads through Cloud NAT.
Cloud NAT allows outbound connections and the inbound responses to those requested connections. Cloud NAT does not permit unsolicited inbound requests from the internet, even if firewall rules would otherwise permit those requests. Integrating Cloud NAT with Cloud Firewall enables implicit protection from unauthorized external requests to your workloads. 
Cloud NAT integration with third-party NGFWs
Deploying third party virtual network security appliances, including virtual NGFWs, to protect internet/SaaS access by workloads is another common Google Cloud customer design pattern. The reasons can be: desire for a consistent security posture across on-prem and Google Cloud, desire for a single pane of policy management across their multi-cloud and on-prem deployments and more familiarity of network operations teams with a particular vendor’s appliances and policy configurations.
To meet the dynamic scale and capacity requirements of cloud workloads, customers often enable auto-scaling on their firewall deployments. In such a deployment model, the workloads' traffic is transparently redirected to an Internal Load Balancer (ILB) that is front-ending the virtual firewall deployments using Managed Instance Groups.
To NAT the traffic egressing from these firewalls, customers have a couple options.
Option 1: Statically assign public IP address to firewall instances’ internet facing interface and configure inbuilt NAT policy on the 3rd Party FWs.
Option 2: Use Google Cloud native Cloud NAT service in a public/untrust VPC and configure a NAT policy on the 3P FWs to translate original source IP to its private NIC IP in the public/untrust VPC.
Considering the options, there are a some reasons why we recommend to Option 2:
A) Assigning public IP addresses to compute instances, including virtual firewalls, exposes them to DoS, DDoS attack attempts and port scans that commonly plague public workloads consuming their CPU cycles. Using Cloud NAT for outbound connectivity optimizes the utilization of these virtual firewall appliances by blocking the unsolicited ingress connections at the network edge before reaching the appliances.
B) Managing source IP-based access control for SaaS apps is difficult when public IPs are associated with auto-scaling firewalls. The reason it is challenging is because customers with auto-scaling firewalls may need static/known IPs for a fixed number of allowlisted IP addresses. If static IP addresses are not a requirement, the best option is to match the Cloud NAT configuration with dynamic Automatic IP settings.
When Cloud NAT is fronting auto-scaling MIGs and static or known IP addresses are a requirement, then there are additional configurations to consider.
The number of VMs a Cloud NAT can support per IP address is inversely proportional to the number of ports per VM allocated. Each custom static IP reserved for Cloud NAT offers 64,512 ports for VMs. Cloud NAT will allocate a configurable number of these ports to each VM. For example, if a single custom (static) IP is allocated for a Cloud NAT and each VM is allocated 4096 ports, that Cloud NAT can theoretically support up to 15 VMs.
Allocating 4096 ports per VM might seem like a lot of ports, but consider that these VMs are virtual firewall appliances and act as network proxies for potentially 1000s of VMs.
It is critical to determine the maximum number of ports each virtual firewall appliance may require as well as the maximum number of VMs that your MIGs may grow to. Based on this information, you can prepare Cloud NAT with the proper number of static IPs to accommodate your environment and help prevent port exhaustion and Cloud NAT errors.
A helpful feature here is Dynamic Port Allocation that optimizes IP and port utilization. With Dynamic Port Allocation, the “Maximum ports per VM instance” is set to at least double the “Minimum ports per VM instance” This provides a little bit of a buffer in case your MIG scales beyond expectation.
The above configuration can safely support 47 VMs each with 4096 ports and possibly up to 94 VMs if all VMs utilized the minimum number of ports. Recall that each IP provides 64,512 ports.
When determining the number of ports to allocate per VM (or 3rd Party NGFW) it is critical to understand that the “ports per VM instance” is NOT the total number of simultaneous connections for that VM. Rather, it is the total number of simultaneous connections to a unique destination IP and port combination for that VM. In our example, by allocating a max of 4096 ports per VM, a single 3rd Party NGFW would be able to make 4096 connections to destination IP1:443, another 4096 connections to IP1:80 and another 4096 connections to IP2:443, etc. Port exhaustion would occur on the 4097th simultaneous connection to IP1:443.
To simplify configuration features such as destination based NAT rules, Dynamic Port Allocation and Auto IP scaling allow for efficient utilization of Public IP addresses while dynamically scaling workloads' traffic demands. On the MIG side, you can set an option to set the max number of instances that it can create.
Do more with Cloud NAT and Cloud Firewall
We have launched some new innovations this year with the public preview of Private NAT and general availability of the FQDN support in Cloud Firewall. Read about how Cloud NAT helped Macy’s strengthen their security posture.
To learn more about how it can help secure your environment, please watch this video on protecting your network with Cloud NAT and Cloud NAT and NGFWs advanced networking demo. You can also get started using our quick start guide.
