Understanding Firewalls in GCP

Hey folks! It’s been years since I wrote a blog. In this post, we will learn about the basics of firewalls in GCP and the various types of firewalls available in the Google Cloud Platform.

What is a Firewall? Link to heading

Before we dive in, let’s try to understand what a firewall is in the first place. According to Wikipedia:

In computing, a firewall is a network security system that monitors and controls incoming and outgoing network traffic based on configurable security rules.

To boil it down: A firewall is essentially a filter for network traffic.

In GCP we have three types of firewalls

1. Hierarchical Firewall Policy
2. Network Firewall policy
3. VPC Firewall rules

VPC Firewall rules Link to heading

Let’s start with the oldest firewall type in GCP which is VPC Firewall Rules. As the name indicates, firewall rules are nothing but rules that dictate how traffic flows in the VPC.

Lets try to see some of the important components in the Firewalls

Component Description

Direction	Ingress (incoming traffic) and Egress (outgoing traffic)
Source/Destination	For ingress rules, specify the source from which traffic is accepted. For egress rules, specify the destination to which traffic is allowed.
Protocol and Ports	Specifies which protocol and port the rule is applied to
Action on Match	Action to perform when a rule matches; options are deny or allow
Priority	Integers assigned to rules; lower numbers indicate higher priority

Before starting with the hands-on, I want to specify one more thing. In GCP, there are two firewall rules which will be present in all VPC :

• Implicit Egress allow - This means all egress traffic is allowed by default
• Implicit Ingress deny - This means all ingress traffic is denied by default

Note You can’t delete these Implicit rules

You may ask, isn’t this a security issue? we don’t want egress traffic to be allowed.

Note that the default implicit egress and ingress rules are created with the lowest priority 65535, so we can override them with our custom firewall rules.

Enough of this theory—let’s get started with the hands-on.

First create the Custom VPC using the below command

By default, when you create a custom VPC, only the two implicit firewall rules will be present. Next create the vm in the custom VPC that we have created

Replace the project Name with your actual project name

Once the previous step is completed, let’s try to SSH into the created VM using the following command:

gcloud compute ssh test-vm --zone us-central1-c

If this is your first time connecting, the command will generate SSH keys, add them to the project, and configure the VM accordingly.

Note: During the setup process, press Y for all prompts and leave the options at their default values.

After some time, you may encounter a timeout error. This happens because, by default, ingress traffic is denied in the VPC. To allow SSH access, we need to explicitly allow inbound traffic on port 22.

Lets create the VPC firewall rules to allow ssh connections.

After running the command, try SSH-ing into the VM again using the same SSH command. This time, you should be able to connect successfully.

Note the default traffic direction is ingress so we don’t need to explicitly specify in the Gcloud Command

Targets in Firewall Rules Link to heading

When creating firewall rules, you must specify the network in which the rules should be created. Additionally, you can specify on which instances the rules will apply to. The available options are:

• All instances in the network
• Instances with a specific service account
• Instances with specific tags

Firewalls Policies Link to heading

Next, we will discuss Firewall Policies, also known as Network Firewall Policies. A Firewall Policy is essentially a collection of firewall rules, similar to a container for managing multiple rules.

One key advantage of Firewall Policies is that they can be applied to multiple VPCs within a project. This enables centralized management, making it easier to handle hundreds of firewall rules across different VPCs.

In GCP, there are two types of Firewall Policies:

• Global Policies – Applicable to all regions within the VPC.
• Regional Policies – Applicable only to specific regions within the VPC.

Before we proceed with the hands-on exercise, let’s delete the previously created SSH rules.

Key Components of Firewall Policies Link to heading

ComponentDescription

Policies	A collection of firewall rules.
Rules	The actual firewall rules. These configurations are similar to VPC firewall rules but with some key differences. You can find more details here.
Associations	Bindings that link firewall policies to specific VPCs.

In this section we will create the firewall rules which allows the ICMP ingress traffic to be allowed

Lets get started. First, create a VPC firewall policy to store the firewall rules:

Next associate the firewall policy with the custom VPC that we have created previously using association

Before creating the rules lets try to ping the VM and see if the ICMP traffic reaches the VM.

Get the external IP of the VM:

Lets try to ping the VM with its external IP

ping -c3 -W 10 $VM1_IP 3 packets transmitted, 0 received, 100% packet loss, time 2032ms

You can see from the output ICMP traffic is currently blocked

Next create the firewall rules to allow ICMP traffic

Now try to ping vm again

This time we will be able to successfully ping again.

At this point, you might wonder why we used firewall policies instead of regular VPC firewall rules.Let’s explore some key advantages of firewall policies in the next section.

Firewall Association Link to heading

If you want to attach the same firewall policy to another VPC network, simply run:

gcloud compute network-firewall-policies associations create \ --firewall-policy global-policies \ --network custom-network \ --global-firewall-policy

With VPC firewall rules, you would need to manually copy the rules to each target VPC, making maintenance a pain since you have to manage multiple copies of the same rules. Using firewall policies simplifies this process by allowing centralized management across multiple VPCs.

Go_Next Link to heading

Previously, we saw that VPC firewall rules allow only allow or deny actions. However, Network Firewall Policies support two additional options:

1. apply_security_profile_group: Intercepts traffic and sends it to a firewall endpoint for Layer 7 inspection.
2. goto_next: Simply says continue to process the rules in the below level If this sounds confusing, don’t worry! It will make sense once we dive into the hands-on section.

Regional Firewall policies Link to heading

Regional Firewall Policies are similar to Global Firewall Policies, but they apply only to specific regions instead of the entire VPC.

Now, let’s see how Regional Firewall Policies and the goto_next statement work together.

Basically here what we are doing

Note the order in the image is not correct but the concept is same. You can find the correct evaluation order here

Just like Global Firewall Policies, the process for Regional Firewall Policies follows three steps:

• Create the Policy
• Associate it with a VPC
• Add Firewall Rules

In the command above, we explicitly specify the region where the firewall policy will be applied using the –region flag.

Next create the firewall rules

Next, try to SSH into the VM

gcloud compute ssh test-vm --zone us-central1-c

Now, create another VM in the Asia region and check if SSH access works:

replace the Project-name with your project name

Try SSH access to the newly created instance:

You will get an error because the regional policy only applies to the specified region in our case we can only ssh into the instance which is present in the region us-central1

Now, check if we can ping the VM:

We will be able to ping the instance because Global Firewall Policies allows the ICMP traffic

Hierarchical Firewall policy Link to heading

The last type of firewall we will cover is the Hierarchical Firewall, which allows policies to be assigned at the organization or folder level. This is especially useful in large organizations where firewall rules need to be enforced across multiple projects consistently.

Let’s take a scenario where we want to restrict access to https://www.google.com/ across the entire organization using a Hierarchical Firewall Policy.

Enough of the theory—let’s get started.

Note: To perform this hands-on exercise, you need a Google Organization Account.

First, create the firewall policy using the following command:

Replace the org id with your org id . You can find the org id using the below command

Next associate the firewall policy with the org

Next, create a firewall rule to block egress traffic to https://www.google.com/.

Now, SSH into the VM:

gcloud compute ssh test-vm --zone us-central1-c and try to access the google.com using curl command

You will see a timeout error, confirming that the egress firewall rule is blocking traffic to www.google.com.This policy will be applicable to all vms in the organizations regardless of folders, projects , regions and VPCs.

To summarize what we learned

Firewall TypeScopeDescription

VPC Firewall Rules	Single VPC	Restricts network traffic within a single VPC. Not recommended unless absolutely necessary.
Global Network Firewall	Multiple VPCs (All Regions)	Restricts network traffic across multiple VPCs in all regions.
Regional Network Firewall	Multiple VPCs (Specific Region)	Restricts network traffic across multiple VPCs within a specific region.
Hierarchical Network Firewall	Organization / Folder	Restricts network traffic at the organization or folder level, enforcing policies across multiple projects.

That’s it, folks! I hope you found this blog helpful and learned something new. If you have any feedback or questions, feel free to reach out to me.

Clean up Link to heading

For firewall policies, I recommend you to go to the UI and delete the resources or if you are lazy like me delete the whole project xD.