Stop using NGFW Appliances in Google Cloud
Revisiting an old gripe of mine…
With recent announcements from Google around their newly renamed “Cloud Next Generation Firewall (NGFW).” service. I thought it was time to revisit this topic I first blogged about in July 2022 and see what, if anything, has changed.
I have been a Certified Google Cloud Networking Engineer for over four years, configuring my fair share of network configurations ranging from simple shared VPCs to complex multi-peering and hybrid setups. I have also seen and had the misfortune of configuring NGFW appliances from different vendors in Google Cloud.
But why were NGFW appliances used? Honestly, I think it generally comes down to three main things:
- Familiarity: Networking teams tend to be conservative groups that are often initially blamed for service outages, rightly or wrongly.
- Ignorance: networking teams expect Google’s network to be configured and behave similarly to on-premise networks.
- Functionality: Sometimes, a particular piece of functionality is required (or perceived to be) that the native solution doesn’t offer.
Let’s explore each of these three areas a bit further.
Familiarity
Familiarity is often a strong pull to a given solution, especially in networking, which arguably hasn't experienced too much disruption until the recent pushes towards cloud and Software-Defined Networking (SDN). When speaking to customers' networking teams, they may refer to themselves as a Cisco, Huwawi, Palo Alto, Fortinet, or Juniper shop (other vendors are available!). This often leads to an almost tribal attitude and contempt for other solutions, even when benefits exist.
Ignorance
Many networking teams are often told they need to ‘go cloud’ without the additional training or experience to understand how best to define and configure cloud networks. In my personal experience, this is especially true of Google networking which differentiates itself compared to other clouds and certainly on-premise. Fortunately, Google does make learning about their networking stack comparatively straightforward, with lots of content in all sorts of places and the opportunity to validate your skills with the certification.
Functionality
Now this is an area where I have previously seen legitimate use for NGFW appliances. Where the ‘native’ solution wasn’t feature complete and this is primarily what I want to revisit in light of Google’s recent announcements.
First, let's start with a refresher on Google’s Andromeda SDN stack. This platform has substantial network function virtualisation (NFV). Under the hood, Google’s physical ‘Jupiter’ network fabric is based on the Clos topography designed for incredible throughput and a strong level of resiliency. If you are interested, I highly recommend the whitepaper.
Above this, the Andromeda SDN is also designed to eliminate single points of failure, and as such, common network functions such as the firewall are completely distributed. Indeed, to quote Stephanie Wong on the topic:
“You can think of the GCP firewall rules as existing not only between your instances and other networks, but between individual instances within the same network.” — Stephanie Wong
This was and still is my biggest issue with network appliances in general; you inherently make the network less resilient by adding choke points that Google has worked hard to remove. That said, I fully appreciate IPS protection requires and appliance to sit in the data path.
Focusing on the firewall component, Google now offers three tiers:
- Cloud Next Generation Firewall Essentials
- Cloud Next Generation Firewall Standard
- Cloud Next Generation Firewall Enterprise
Firewall Essentials
‘Essentials is the ‘base’ level functionality provided at no additional charge above standard networking costs. It includes:
- Firewall Policies, both in Global and Regional variants, allowing you to group a collection of rules and apply them to one or many VPCs.
- IAM Controlled Firewall Tags, not to be confused with Network Tags can only be applied to network policies and have IAM-based access control. A comparison of these is below:
- Address Groups, allowing you to group IP addresses into logical blocks that can be applied within multiple different firewall policies.
- VPC Firewall Rules filter and control traffic using service accounts, network tags, or IP ranges. These rules have existed in Google Cloud for years.
Firewall Standard
‘Standard’ builds on essentials with some further functionality, namely:
- FQDN Objects specify firewall policies using DNS rather than IP addresses, which is useful where the addresses change frequently with the DNS lookup done every few seconds.
- Threat Intelligence Rules, enabling you to specify rules based using lists established with Google’s threat intelligence.
- Geolocation Objects restrict traffic using ISO 3166–1 alpha-2 codes, though fair warning: Geolocation isn’t perfect, and VPNs can often be used to bypass it.
If the traffic evaluated by a ‘Standard’ rule is to or from the internet, it is subject to a small data processing charge of $0.018/GB.
Firewall Enterprise
Finally, we have ‘Enterprise’ in common with Google’s increasingly common naming scheme. This is interesting as it has the concept of an ‘endpoint’, a Google-managed appliance running Palo Alto tech. Probably the best information I have found on how this works is this video:
This provides full layer seven protection along with IPS with traffic being intercepted and run through the endpoint. So what’s the catch? An endpoint deployed to a single zone within a region costs $1.75/hr or ~$1260/month for regional resiliency (which you will no doubt want if you want this solution), double or even triple that amount. On top of this, there is the same $0.018/GB data processing charge as ‘standard’.
So, there is quite a lot of functionality within the Google estate covering typical NGFW appliance use cases. Another use case I saw recently was to do some internal NAT for a bank that had run out of RFC1918 address space. The Inter-VPC NAT feature, a fairly recent addition to Google’s lineup, also recently covered this use case.
Going back to my original post, I outlined some reasons I disliked appliances. Let’s revisit these in the context of the new functionality Google offers:
- Appliances make the network fundamentally less resilient—This is still very much the case; I concede that for IPS functionality and deep-level packet inspection, data must flow through a choke point. I would challenge organisations, though, to consider whether they need this functionality or could achieve similar levels of protection using other mechanisms.
- We have to maintain the appliances — The good news is that with Google’s new ‘Enterprise’ offering, there are appliances, but they are fully Google’s responsibility to manage.
- They have to be managed separately from the rest of the infrastructure — Google’s fully managed solution is integrated into the console and other tooling such as cloud logging and Chronicle.
- Troubleshooting has been painful — Native integration with tools such as the Network Connectivity Center, troubleshooting becomes more straightforward with a ‘single pane of glass’ view.
- Integration isn’t great with other Google native tooling — As above this is properly integrated into the Google ecosystem.
- Appliances are somewhat expensive — The enterprise solution is still pricey compared to standing up traditional appliances in a resilient fashion, I think the cost will be comparable if not competitive. The management overhead will also be considerably lower.
Concluding Thoughts
So, in this post, I set out to revisit an old gripe of mine and see what has changed; the answer is a lot (a glowing testament to Google’s ongoing feature development!). I still strongly believe that 3rd party network appliances in Google Cloud are an anti-pattern, especially in the context of Google’s new offerings in the space.
All that leaves me to do then is to say that until next time, keep it Googley ;)
