Skip to content
Nick SelpaSep 22, 2022 12:00:00 AM13 min read

A Layperson's Guide to GCP Network Firewalling

A Layperson's Guide to GCP Network Firewalling

A Layperson's Guide to GCP Network Firewalling

A companion to OSI Layer 3/Layer 4 firewalling in GCP

Firewalls have been, and continue to be, an evergreen technical domain for managing network communications for decades. Despite how storied firewalls have been in managing network communications over the years, firewall management details can vary wildly between vendors and cloud providers.

In this article, we’ll focus on network firewalling and its rules and policy management in Google Cloud Platform. The intent is to provide you, the reader, with a comprehensive landscape of firewall configuration options in GCP as a starting point. A core outcome, using this broader point of view, is to encourage better design choices around enforcement and lifecycle management for GCP firewalling.

By the end, you should be armed with a foundational overview of what’s involved with GCP firewall management and understand:

  • The Anatomy of a Firewall Rule
  • GCP Firewalling Foundational Facts
  • Firewall policies and how they enable firewall rules management at scale

Following defense in depth, cloud providers often provide a suite of complementary security services to achieve networking security at different layers of the OSI model. In GCP, this includes VPC Service Controls, BeyondCorp (for Zero Trust), and Cloud Armor for Layer 7 network protection.

VPC Service Controls

VPC Service Controls

This article is focused on OSI Layer 3/Layer 4 network protection using GCP firewall rules. Additionally, firewall features described in this article will focus on generally available (GA) features.

Reader Assumptions

This article is going to assume that the reader has foundational working knowledge of networking concepts. (e.g., the OSI model, classful and classless subnets, network protocols) The article also assumes that the reader has had some exposure to general firewall management, be it on another cloud platform, vendor solution, and the like.

Another assumption is that the reader is familiar with the GCP Resource Hierarchy as this information is relevant to using firewall policies.

Additionally, while this article assumes that the reader has limited knowledge of GCP firewalling, this article may also act as a refresher or companion reference for experienced GCP users to springboard into different facets of GCP firewalling.

The Anatomy of a Firewall Rule

Before we dive into some of the more particular details around GCP firewalling, it’s important to level set firewall rules terminology used in GCP.

While GCP's firewall administrative patterns are relatively standard in the market at large, there are still some vendor-specific terms that are used and can have multiple contexts.

Level setting GCP-specific firewall terms are foundational to this article. Since this is a companion reference, it is important that you’re able to springboard into GCP documentation from here in a predictable and reliable manner.

Let’s run through what a firewall rule looks like in GCP. The graphic below will act as a visual map to describe the firewall rule components:

A visual map to describe the firewall rule components

A visual map to describe the firewall rule components

Firewall Rule Component Description


A rule toggle that acts as a means to enforce or disable a firewall rule.

This is helpful for, but not limited to:

  • Troubleshooting
  • Rules Testing
  • Near real-time enforcement changes for deployments

Rule Direction

Can be INGRESS or EGRESS only. Firewall rules in GCP are stateful, automatically permitting the return traffic for an established connection between a client and a target. Directionality is relative to the resource the rule becomes attached to (VPC network, hierarchical policy, etc)


A whole number that specifies the firewall rule’s priority during rules processing.

The lower the number, the higher the priority since it puts it towards the top of the list.


Can be configured with allow or deny for firewall rules. Rules configured within firewall policies can use the verb goto_next.


Target and Filter are used to match what originators of network traffic are interesting for this firewall rule.

The Target and Filter context changes based on direction:

  • INGRESS: Target for destination, Filter for source.
  • EGRESS: Target for source, Filter for destination.


Ports and Protocols

A combination of network protocols (i.e.: TCP, UDP, ICMP) and protocol ports to further refine the selection criteria for a firewall rule.

Foundational facts about GCP Firewalling

Regardless of the technical domain, while a solution may offer ways to apply different types of grouping and conditionals to help organizations achieve configurations aligned with technical and non-technical requirements, there are foundational truths that inform how the configuration is modeled and firewalling is no exception to that. These truths for firewalling in GCP are:

  • Firewall rules are managed using the Compute Engine API
  • All firewall rules are stateful
  • Firewall rules can be attached to a VPC network or a firewall policy
  • All firewall rules have a configurable priority
  • GCP has a collection of globally blocked or limited traffic, managed by Google

Firewall rules are managed using the Compute Engine API

Firewall rules are managed under the Compute Engine API umbrella. If you’re provisioning from scratch, you’ll fumble across this fact using the Cloud Console within a new project.

1. Cloud Console has a discrete interface for VPC networking...

1. Cloud Console has a discrete interface for VPC networking...

2. ...that when you load it without enabling the Compute Engine API, the Cloud Console redirects you...

2. ...that when you load it without enabling the Compute Engine API, the Cloud Console redirects you...

3. enable the Compute Engine API

3. enable the Compute Engine API

Example 1 (images above): Ordered screen snips showing how the Cloud Console guides users to the appropriate API to enable (in this case, Compute Engine API) networking services in a GCP project.

If you’re working with GCP resources in a brownfield environment for the first time, this detail may not be immediately apparent while using the Cloud Console.

gcloud commands, however, do a better job of self-describing that firewall management is under the Compute Engine API:

Example 2: Google Cloud SDK documentation filtering for commands that match firewall

Example 2: Google Cloud SDK documentation filtering for commands that match firewall

All GCP firewall rules are stateful

In GCP, when a firewall rule is created and traffic matches the rule, the return traffic for that match is permitted. You cannot configure a firewall rule to deny associated response traffic.

GCP tracks connections for network protocols, even for protocols that aren't stateful (like UDP).

Return traffic must match the source IP, destination IP, source port, destination port, and protocol of the accepted request traffic, but with the source and destination addresses and ports reversed.

Firewall rules can be attached to a VPC network or a firewall policy

Once the Compute Engine API is enabled, firewall rules can be configured and directly attached to the VPC network for filtering. Firewall rules attached to a VPC network are not readily portable to other VPC networks in other GCP projects.

Example 3: Conceptual diagram showing firewall rules attached to the distributed firewall that’s part of a VPC network

Example 3: Conceptual diagram showing firewall rules attached to the distributed firewall that’s part of a VPC network

If you need to manage firewall rules at scale for your organization, it is recommended that you use firewall policies. Firewall policies are a container for firewall rules that can be attached to supported GCP resources within the Resource Hierarchy. We’ll expand on firewall policies later in this article.

All firewall rules have a configurable priority

GCP firewall rules have a configurable priority associated with them. The configured priority determines which order rules are evaluated. As such, the principle of a rule being used based on “first hit, not best fit” applies.

Firewall rules matching is done by “first hit, not best fit”

The phrase First Hit, Not Best Fit is used to characterize and emphasize how the configuration of firewall priority on a rule is important.

Let’s create an academic example to demonstrate this. In this scenario, you were interested in denying network access to services from a contiguous half of a private subnetwork’s address space ( Below is a simplified and egregiously configured list of firewall rules and their priority to attempt to meet that objective:

Priority Action Direction Target Filter
1500 allow INGRESS All Networks
2500 allow INGRESS All Networks
3500 deny INGRESS All Networks

While rule 3500 is valid, it is superseded by rule 2500, which will permit those clients who you want to deny. Flipping the rule definitions of rules 2500 and 3500 will result in the desired behavior:

Priority Action Direction Target Filter
1500 allow INGRESS All Networks
2500 deny INGRESS All Networks
3500 allow INGRESS All Networks

Contextual differences on firewall rule priority

Firewall rules in GCP will always have a priority associated with them. However, the constraints around how priorities are configured differ depending on usage context. See the table below which illustrates the differences between firewall rule and firewall policy usage contexts:

Firewall Rule Attached To Highest Priority1 Lowest Priority1 Duplicate Rule Priority?
VPC Network Firewall 0 65535 Allowed
GCP Firewall Policy 0 2147483647 Denied

Regarding duplicate firewall rules configured within a VPC Network Firewall, there is an order of operations that reconciles what takes precedence in the event a set of rules share a common priority.

Being mindful of these priority rules is not necessary for a firewall policy. This is because all rules defined within a firewall policy must have discrete priorities. This condenses the consideration for firewall rules order in a firewall policy down to “First hit, not best fit” when crafting rules for a firewall policy.

Additional details around GCP firewalling

Targets and Filters can use service accounts and tags

In addition to using traditional CIDR notation for address ranges to define in rules, you may also use service accounts and tags (network tags on VMs or secure tags2).

Preferring service accounts and tags over CIDR-based rules provides an opportunity to filter traffic based on application usage context and makes porting or duplicating deployments needing firewall rules easier and more predictable.

Auto-configured firewall rules

For the ‘default’ VPC network that is created with a GCP project, there are a collection of predefined rules that are automatically applied and enforced. The rules permit all intra-network traffic within the VPC, as well as permissive rules allowing ICMP, SSH, and RDP access to GCP resources.

Implicit firewall rules

The following implicit firewall rules are catch-all default rules that are applied if none of the configured firewall rules match a traffic flow:

  • Implied allow egress rule
  • Implied deny ingress rule
This is a speculative side note here, however, it is assumed those implicit firewall rules, as well as the auto-configured rules applied to the default network, are provided as a courtesy to expedite GCP service usage and testing. As such, these defaults should not be considered appropriate or secure for sensitive environments.

Understanding what these defaults are is important when trying to level set the desired security posture you’re trying to achieve to align with technical and non-technical requirements.

Google manages a collection of globally allowed, blocked, or limited traffic for GCP

With Google advocating for Shared Fate along with Shared Responsibility when operating in GCP, it’s important to understand, or at least have reference to, what GCP is always allowing, blocking, and limiting as part of its service provider offering.

Reviewing, understanding, and accepting the risks related to what a service provider's operating constraints are is globally important to an organization and not solely security's responsibility.

Firewall policies and management at scale

Let’s pivot to talking about firewall policies in GCP. So far, we’ve focused on attaching firewall rules to a VPC network. However, let’s say your organization’s scale is outstripping the administrative capabilities provided for managing firewall rules in a GCP project. Problems you’d be encountering include:

  • Inconsistent application of common firewall rules across multiple projects in a GCP organization
  • Delegating a level of autonomy to teams within your organization to self-manage firewall rules in your GCP projects without violating the organization’s desired firewall hardening posture

Enter firewall policies. Firewall policies are a logical container consisting of firewall rules. Those rules containers can then be attached to supported GCP resources within the hierarchy.

There are three types of firewall policies:

  1. Hierarchical Firewall Policies
  2. Network Firewall Policies
  3. Regional Firewall Policies

Fortunately, there are a lot of common traits across the different policy types. We’ll focus on those and then raise some key differences in policy types.

Common facts regarding GCP Firewall Policy Types

Creating a policy does not automatically apply the configured rules to any network

When creating a new firewall policy, the policy is not attached to any GCP resource by default. Only when the policy is attached to a supported resource, will the rules in the firewall policy be evaluated.

Rules evaluation for attached firewall policies follow the resource hierarchy

While firewall policy association constraints vary across the different firewall policy types, they all adhere to the GCP Resource Hierarchy for parent/child resource relationships. Having working knowledge of how the resource hierarchy is structured in GCP will lead to more impactful design and architectural choices throughout your management lifecycle on Google Cloud.

Firewall policies enable centralized rules management and governance

Firewall policies enable one policy to many resource relationships. These one-to-many relationships allow for consistent management and enforcement of firewall rules across your GCP organization.

Additionally, firewall policies introduce a new action, goto_next. When a rule is configured with this action, the rules processing is deferred to a child policy or rule downstream. This allows for a layered approach on what rules are globally enforced. This logical flow diagram illustrates a chain of firewall policies and rules mapped onto a generic GCP resource hierarchy:

A logical diagram illustrating a set of chaining hierarchical policies using goto_next. The GCP project also uses Firewall Rules for additional rules coverage.

A logical diagram illustrating a set of chaining hierarchical policies using goto_next. The GCP project also uses Firewall Rules for additional rules coverage.

For all firewall policy types, there are a set of IPv4 and IPv6 rules with the lowest priority and an action of goto_next. This differs from the implicit firewall rules, which will result in an allow or deny. Additionally, while you may author a firewall policy to supersede these implicit rules, they cannot be modified or deleted.

Having covered the common features of each firewall policy, here are the key differences for each firewall policy type:

Hierarchical firewall policy

The biggest distinction of a hierarchical firewall policy is where the policies are created and what resources they can be associated with. A hierarchical policy can be created at and attached to organization and folder nodes.

Network firewall policy

A network firewall policy is created at the VPC level. Policies created at the VPC level can be shared with other VPC networks that have a common GCP project.

While hierarchical firewall policy authoring may be similar to authoring firewall rules in a VPC network, network firewall policies have very stark differences when contrasted against a VPC firewall rule:

  Network firewall policy rules VPC firewall rules
Priority Unique Duplication allowed
Service account Target service account only (no source service account) Yes
Tag Secure tag Network tag
Name and description Policy name, policy and rule description Rule name and description
Batch update Yes(policy clone, edit, and replace functions) No
Reuse Yes No
Quota Attribute count Rule count

Secure tags are another name for Resource Manager tags. Using secure tags allows for access control to be managed by IAM. If your organization has a requirement of marshaling what tags to use via IAM, then you’ll need to use Network firewall policies, as Network tags for VMs do not have an access control mechanism.

While not in the name of the policy type, these firewall policies are global. When associated with a VPC network, the rules apply across all regions in the VPC network.

Regional network firewall policy

Finally, there are regional network firewall policies. They share a lot of the same traits as a (Global) Network firewall policy except:

  • They target one and only one region
  • Only one regional firewall policy can be associated within a network

Closing Remarks

After providing a lay of the land around GCP Firewalling, you should now be:

  • Armed with foundational information around GCP firewalling, increasing or reinforcing your understanding of firewall rules and policy management
  • Able to conceptualize how to rationalize risk and manage GCP firewall defaults in your GCP organization and/or projects
  • Review your resource hierarchy and rationalize a strategy to effectively use firewall policies in your GCP organization
  • More effectively interpret the firewall related recommendations made in the Networking Security section for VPC architecture and best practices

  1. A smaller firewall rule priority supersedes a larger firewall rule priority and vice versa.↩︎

  2. Secure tags can also be called Resource Manager tags. This is touched upon in the firewall policies section later in this article.↩︎


The information presented in this article is accurate as of 7/19/23. Follow the ScaleSec blog for new articles and updates.