Creating Firewall Rules on a Google Cloud VPC Network

Hands-On Lab

 

Photo of Matthew Ulasien

Matthew Ulasien

Team Lead Google Cloud in Content

Length

00:30:00

Difficulty

Intermediate

In this hands-on lab, we will be presented with a custom VPC that has four instances spread across three subnets with zero firewall rules created. We will configure two different firewall rules: one to allow SSH access to all instances on the network, and another one using specific network tags to only allow ICMP (ping) access to one instance, and only from a specific subnet. This will demonstrate using both wide-scope and narrow-scope firewall rules.

What are Hands-On Labs?

Hands-On Labs are scenario-based learning environments where learners can practice without consequences. Don't compromise a system or waste money on expensive downloads. Practice real-world skills without the real-world risk, no assembly required.

Creating Firewall Rules on a Google Cloud VPC Network

Introduction

In this hands-on lab, we will be presented with a custom VPC that has four instances spread across three subnets with zero firewall rules created. We will configure two different firewall rules: one to allow SSH access to all instances on the network, and another one using specific network tags to only allow ICMP (ping) access to one instance, and only from a specific subnet. This will demonstrate using both wide-scope and narrow-scope firewall rules.

Solution

Begin by logging in to the GCP Console using the credentials provided on the hands-on lab page. It is recommended to right-click the Open GCP Console button and choose Open in Incognito Window to avoid running into issues with existing Google accounts.

Before we begin, if you have not already, I highly recommend deleting the default VPC network in order to clean up our views. To do so:

  • Go to the top-left menu
  • Scroll down and click VPC Network
  • Click the default network, then click DELETE VPC NETWORK, and accept the additional warning prompt.
  • IMPORTANT: Be sure that you do not delete the custom-vpc network.
  • You can move on to the next steps while the default VPC is deleting

Now that we have our views cleaned up, let’s look at the firewall rules.

  • From the same VPC network screen, click on Firewall rules from the left side.
  • Notice that we do not have any created for the custom-vpc network. Let’s see how this affects our ability to interact with our resources.

Let’s next go to Compute Engine:

  • From the top-left menu, scroll down and click on Compute Engine

From the Compute Engine instance screen, you should have four instances already running. Attempt to connect to any of them by clicking on the SSH button to the right. What should happen is that the SSH session will eventually time out because we do not have port 22 access (SSH) to any instances on our network, and we need to fix this.

Allow SSH access to all instances

We will now create our first firewall rule to allow SSH access to all instances on our network. This rule will be wide in scope. Be aware that you will not likely allow full SSH access from any source in a production environment, however we are demonstrating how it works for the purpose of the lab. Let’s now go back to our firewall rules menu:

  • From the top-left menu, scroll down to VPC network, then click on Firewall rules from the sub-menu

We will now create a wide-scope rule to allow SSH access to the entire network from all public sources:

  • Click Create firewall rule.
  • Name the rule allow-ssh.
  • In the Network dropdown menu, select custom-vpc.
  • In the Targets dropdown menu, select All instances in the network.
  • In the Source filter dropdown menu, select IP ranges (should be the default).
  • In Source IP ranges, enter 0.0.0.0/0. This allows access from any public location.
  • In Protocols and ports, select Specified protocols and ports
  • Place a check in tcp, and enter 22 in the text box to the right of it

Before we click on Create, click the command line link beneath it to view the gcloud command cross reference. This cross reference is useful for learning equivalent gcloud commands and useful for building complex scripts (note there there is sometimes a ‘glitch’ where the network field always says ‘default’ instead of the selected network). Once you are done, click CLOSE on the gcloud cross reference, and click the blue Create button.

Wait about 10 seconds for the rule to finish creating, then let’s test to see if it works. Go back to Compute Engine and click any of the SSH buttons next to our instances, and you should be able to successfully connect to a GCE instance.

Apply network tag to instance-2

Now that we can connect over SSH, we next want to use a much more targeted firewall rule to allow ICMP (ping) access to only our ‘instance-2’ access, and only allow that traffic to come from instances on our subnet-a subnet. This will be much more narrow in scope for both resources the firewall applies to (i.e., the target) and where traffic is allowed to come from (i.e., source filter). Right now, attempting any ping commands to any instance will fail because ICMP has not been allowed. Let’s fix that. We need to first add a network tag to your ‘instance-2’ instance which will allow our rule to target only this one:

  • From Compute Engine, click on instance-2
  • Click the EDIT button at the top
  • Scroll down, and under Network tags, enter icmp-allow, hit enter to confirm the tag, then click Save at the bottom to confirm the change

Create a narrow-scope firewall rule for instance-2

Now that we have applied a network tag to our instance, let’s create a new rule to target only instances with this tag, AND only allow traffic from our ‘subnet-a’ subnet for ping commands:

  • Go back to your firewall menu, and create a new rule
  • Name the rule allow-icmp
  • Choose the custom-vpc network
  • In the Targets dropdown menu, set to specified target tags if not already the default
  • In the Target tags field, type icmp-allow and hit Enter
  • In the Source filter dropdown, choose IP Range
  • Enter the IP range of our subnet-a subnet
  • In Protocols and ports, choose Specified protocols and ports
  • Place a check in Other protocols, and type in icmp (there is no port number for ICMP.
  • If you wish, again view the command line cross reference (may still be glitched for the network field, then close out and click Create to create the rule.

Now that we have created our targeted ICMP rule, let’s test if we can now ping the internal IP address of our ‘instance-2’ instance from each instance in our network.

  • Go back to Compute Engine
  • Next to ‘instance-2’, either write down or highlight/copy the internal IP address for instance-2 (should be 10.0.2.2).
  • SSH into ‘instance-1a’
  • Attempt to ping the instance by entering: ping (internal IP). It should be successful. Hit Ctrl+C to quit ping.
  • Exit out of your ‘instance-1a’ SSH session, and now SSH into ‘instance-1b’, and attempt to ping ‘instance-2’ again, which should also be successful.
  • Exit out of your ‘instance-1b’ session, and SSH into ‘instance-3’.
  • Attempt to ping ‘instance-2’ again. This time it should NOT be successful, because we applied our rule to source traffic from subnet-a only.

Conclusion

Congratulations, you've completed this hands-on lab!