GCP – Basic VPC Networking

This article describes networking within the Google Cloud Platform (GCP). Specifically with the Virtual Private Cloud (VPC), subnets, route and firewall configuration. The following diagram captures the scenario tested.

 

GitHub Terraform Code

The scenario was implemented in Terraform. The Github repo, along with the README file describing the implementation can be found here – https://github.com/kaysal/gcp-terraform/tree/master/vpc-test

 

Compute Instances

Two compute instances are created in europe-west region as shown below.

The public IP addresses of the instances can also be observed from the Terraform output as shown below.

$ terraform apply

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:

... [truncated for brevity]

Apply complete! Resources: 8 added, 0 changed, 0 destroyed.
 
Outputs:
 
instance_1_public_ip = [
    35.x.x.x
]
instance_2_public_ip = [
    35.y.y.y
]

 

The static IP address of the instances can also be confirmed from the kernel as shown below.

kayode@instance-1:~$ ip address
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1460 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 42:01:0a:0a:00:02 brd ff:ff:ff:ff:ff:ff
    inet 10.10.0.2/32 brd 10.10.0.2 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::4001:aff:fe0a:2/64 scope link
       valid_lft forever preferred_lft forever

 

kayode@instance-2:~$ ip address
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1460 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 42:01:c0:a8:0a:02 brd ff:ff:ff:ff:ff:ff
    inet 192.168.10.2/32 brd 192.168.10.2 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::4001:c0ff:fea8:a02/64 scope link
       valid_lft forever preferred_lft forever

 

Note that the static IP addresses of the instances are /32 (255.255.255.255), so the instances send outbound packets to each of their subnet’s gateway MAC address. More information can be found here – Advanced VPC Concepts.

 

VPC Subnets

Custom VPC subnets are created as shown below.

Note that Private Google access is disabled for the 2 subnets. Private Google access feature sets whether VMs in a subnet can access Google services without assigning external IP addresses. In this example, there are no Google services, so the function was disabled for the 2 subnets.

 

VPC Firewalls

Three firewall rules were manually created as shown below.

1) Firewall rule allow-external-ssh
This rule allows SSH traffic from any source (including the internet) to all subnets in the VPC. This means we can establish SSH sessions to the instances located in the 10.10.0.0.16 and 192.168.10.0/24 subnets.

The Terraform script installed a default RSA public key into each instance. We can then use the corresponding RSA private key for the SSH session.

2) Firewall rule allow-external-http
This rule allows HTTP traffic from any source (including the internet) to all subnets in the VPC. This means we can establish HTTP sessions to the instances located in the 10.10.0.0.16 and 192.168.10.0/24 subnets.

Each of the instances has Apache web servers installed with a basic HTML page. To view the web server HTML contents, type the following in the web browser:

Instance 1:
instance_1_public_ip

Instance 2:
instance_1_public_ip or instance_1_public_ip/video

3) Firewall rule allow-internal-only
This firewall rule allows unrestricted communication between instances in the all subnets of the VPC. I decided to use service account as the source filter for this rule rather than tags. This is because service accounts are restricted by IAM permissions, unlike tags which have no restriction. Functionally, tags and service accounts achieve the same purpose.

Now we should be able to ping any instance from the other. See the results below.

kayode@instance-2:~$ ping 10.10.0.2
PING 10.10.0.2 (10.10.0.2) 56(84) bytes of data.
64 bytes from 10.10.0.2: icmp_seq=1 ttl=64 time=1.29 ms
64 bytes from 10.10.0.2: icmp_seq=2 ttl=64 time=0.212 ms
64 bytes from 10.10.0.2: icmp_seq=3 ttl=64 time=0.181 ms
64 bytes from 10.10.0.2: icmp_seq=4 ttl=64 time=0.197 ms
64 bytes from 10.10.0.2: icmp_seq=5 ttl=64 time=0.218 ms
^C
--- 10.10.0.2 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 3999ms
rtt min/avg/max/mdev = 0.181/0.420/1.294/0.437 ms

 

kayode@instance-1:~$ ping 192.168.10.2
PING 192.168.10.2 (192.168.10.2) 56(84) bytes of data.
64 bytes from 192.168.10.2: icmp_seq=1 ttl=64 time=1.10 ms
64 bytes from 192.168.10.2: icmp_seq=2 ttl=64 time=0.194 ms
64 bytes from 192.168.10.2: icmp_seq=3 ttl=64 time=0.185 ms
64 bytes from 192.168.10.2: icmp_seq=4 ttl=64 time=0.174 ms
^C
--- 192.168.10.2 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3000ms
rtt min/avg/max/mdev = 0.174/0.414/1.105/0.399 ms

 

VPC Routes

Default routes are automatically created when we create subnets. One default route is created for each subnet. And one default route is created for outbound internet access. So in this example, we have three default routes – two for our VPC subnets, and one for outbound internet access.

The default route default-route-ad7dbb2b44cbb582 for the 10.10.0.0/24 subnet uses 10.10.0.1 (default gateway) as the next hop. All traffic leaving the instance will be sent to the default gateway. The IP address of the default gateway (10.10.0.1) is the first usable IP address of the subnet (10.10.0.0/24). See kernel routing table below.

kayode@instance-1:~$ netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         10.10.0.1       0.0.0.0         UG        0 0          0 eth0
10.10.0.1       0.0.0.0         255.255.255.255 UH        0 0          0 eth0

 

The default route default-route-51a23baae2f8b913 for the 192.168.10.0/24 subnet uses 192.168.10.1 (default gateway) as the next hop. All traffic leaving the instance will be sent to the default gateway. The IP address of the default gateway (192.168.10.1) is the first usable IP address of the subnet (192.168.10.0/24). See kernel routing table below.

kayode@instance-2:~$ netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         192.168.10.1    0.0.0.0         UG        0 0          0 eth0
192.168.10.1    0.0.0.0         255.255.255.255 UH        0 0          0 eth0

 

The default route default-route-88f12c4710e1a5e8 for outbound internet access applies to all subnets in the VPC. This means all instances in 10.10.0.0/24 and 192.168.10.0/24 subnets can send outbound internet traffic to their default gateways, which then forward the traffic to the internet gateway.

 

Leave a Reply

Your email address will not be published. Required fields are marked *