Virtual Private Cloud (VPC)


Intro

My notes on networking. Most are copy/paste from GCP’s docs on areas that I thought were important to know.

 


Tips and Tidbits

  • VPC networks only support IPv4 unicast traffic. They do not support broadcast, multicast, or IPv6 traffic within the network;

  • Every VPC network has two implied firewall rules.

    • One implied rule allows most egress traffic,

    • and the other denies all ingress traffic.

      • For one instance to be able to communicate with another, appropriate firewall rules must also be configured because every network has an implied deny firewall rule for ingress traffic


VPC network overview

  •  A Virtual Private Cloud (VPC) network is a virtual version of a physical network

  • A VPC network is a global resource that consists of a list of regional virtual subnetworks (subnets) in data centers, all connected by a global wide area network.

  • VPC networks are logically isolated from each other in Google Cloud.

  • Projects can contain multiple VPC networks.

  • New projects start with a default network that has one subnetwork (subnet) in each region (an auto mode VPC network).

    • The default network is an auto mode VPC network with pre-populated firewall rules.

    • You can disable the creation of default networks by creating an organization policy with the compute.skipDefaultNetworkCreation constraint.

      • Projects that inherit this policy won't have a default network

Specifications

  • VPC networks, including their associated routes and firewall rules, are global resources. They are not associated with any particular region or zone.

  • Subnets are regional resources. Each subnet defines a range of IP addresses.

  • Traffic to and from instances can be controlled with network firewall rules.

  • Resources within a VPC network can communicate with one another by using internal (private) IPv4 addresses, subject to applicable network firewall rules

  • An organization can use Shared VPC to keep a VPC network in a common host project. Authorized Cloud IAM members from other projects in the same organization can create resources that use subnets of the Shared VPC network.

  • VPC networks can be connected to other VPC networks in different projects or organizations by using VPC Network Peering.

  • VPC networks can be securely connected in hybrid environments by using Cloud VPN or Cloud Interconnect.

  • VPC networks only support IPv4 unicast traffic. They do not support broadcast, multicast, or IPv6 traffic within the network;

  • VMs in the VPC network can only send to IPv4 destinations and only receive traffic from IPv4 sources. However, it is possible to create an IPv6 address for a global load balancer.

Source: Google

Networks and subnets

  • A subnet is not the same thing as a (VPC) network. Networks and subnets are different types of objects in Google Cloud.

  • Each VPC network consists of one or more useful IP range partitions called subnets.

    • Each subnet is associated with a region.

    • VPC networks do not have any IP address ranges associated with them. IP ranges are defined for the subnets.

  • A network must have at least one subnet before you can use it.

  • Auto mode VPC networks create subnets in each region automatically. Custom mode VPC networks start with no subnets, giving you full control over subnet creation.

  • You can create more than one subnet per region. 

  • If you configure a VM with multiple network interfaces, each interface must be in a separate VPC network. 

Subnet creation mode

  • When an auto mode VPC network is created, one subnet from each region is automatically created within it.

    • Having subnets automatically created in each region is useful.

  • These automatically created subnets use a set of predefined IP ranges that fit within the 10.128.0.0/9 CIDR block.

  • When a custom mode VPC network is created, no subnets are automatically created.

    • We recommend that you use custom mode VPC networks in production.

    • Use custom mode if you plan to connect VPC networks by using VPC Network Peering or Cloud VPN.

    • Because the subnets of every auto mode VPC network use the same predefined range of IP addresses, you cannot connect auto mode VPC networks to one another.

  • You can switch a VPC network from auto mode to custom mode.

    • This is a one-way conversion; custom mode VPC networks cannot be changed to auto mode VPC networks. 

Subnets and IP ranges

Primary IP address range: You can choose any private RFC 1918 CIDR block for the primary IP address range of the subnet.

A VPC in an auto mode will get IP ranges for its subnets fit inside the 10.128.0.0/9 CIDR block. 

 

Reserved IPs

Reserved IP address

Description

Example

Reserved IP address

Description

Example

Network

First address in the primary IP range for the subnet

10.1.2.0 in 10.1.2.0/24

Default gateway

Second address in the primary IP range for the subnet

10.1.2.1 in 10.1.2.0/24

Second-to-last address

Second-to-last address in the primary IP range for the subnet that is reserved by Google Cloud for potential future use

10.1.2.254 in 10.1.2.0/24

Broadcast

Last address in the primary IP range for the subnet

10.1.2.255 in 10.1.2.0/24

 

Routes and firewall rules

 

Every new network starts with two types of system-generated routes:

  • The default route defines a path for traffic to leave the VPC network. It provides general internet access to VMs that meet the internet access requirements. It also provides the typical path for Private Google Access.

  • A subnet route is created for each of the IP ranges associated with a subnet. Every subnet has at least one subnet route for its primary IP range. Subnet routes define paths for traffic to reach VMs that use the subnets. You cannot remove subnet routes manually.

 

Internet Access

If a VM instance does NOT have a public IP address assigned at creation for one of its NICs, then it can’t access the internet by default. There is, however, a way to have instances without external IP addresses send outbound packets to the internet and receive any corresponding established inbound response packets. This is done via Cloud NAT (Network Address Translation)

Internet access requirements

The following criteria must be satisfied for an instance to have outgoing internet access:

  • The network must have a valid default internet gateway route whose destination IP range is the most general (0.0.0.0/0). This route defines the path to the internet. For more information, see Routes.

    • If you allow GCP to create the subnetworks for you, it will automatically create this routing rule for you.

 

 

  • Firewall rules must allow egress traffic from the instance. Unless overridden by a higher priority rule, the implied allow rule for egress traffic permits outbound traffic from all instances.

  • One of the following must be true:

    • The instance must have an external IP address. An external IP address can be assigned to an instance when it is created or after it has been created.

    • The instance must be able to use Cloud NAT or an instance-based proxy that is the target for a static 0.0.0.0/0 route.

Cloud NAT

 

  • It's not based on proxy VMs or appliances.

  • The Cloud NAT gateway and the Cloud Router provide a control plane—they are not involved in the data plane, so packets do not pass through the Cloud NAT gateway or Cloud Router.

 

  • Provides source network address translation (SNAT) for VMs without external IP addresses.

  • Cloud NAT also provides destination network address translation (DNAT) for established inbound response packets.

  • Cloud NAT does not implement unsolicited inbound connections from the internet. DNAT is only performed for packets that arrive as responses to outbound packets.

    • Cloud NAT does not permit unsolicited inbound requests from the internet, even if firewall rules would otherwise permit those requests. 

  • You configure a NAT gateway on a Cloud Router, which provides the control plane for NAT.

  • The existence of an external IP address on an interface always takes precedence and always performs one-to-one NAT, without using Cloud NAT

  • To fully utilize a Cloud NAT gateway, your VPC network needs a default route whose next hop is the default internet gateway

 

  • Each Cloud NAT gateway is associated with a single VPC network, region, and Cloud Router

  • A single Cloud NAT gateway provides NAT for the primary internal IP addresses of eligible VMs whose network interfaces use a subnet in the region.

    • This option uses exactly one NAT gateway per region.

 

Firewall rules

 

  • Firewall rules apply to both outgoing (egress) and incoming (ingress) traffic in the network.

  • Firewall rules control traffic even if it is entirely within the network, including communication among VM instances.

  • Every VPC network has two implied firewall rules.

    • One implied rule allows most egress traffic,

    • and the other denies all ingress traffic.

      • For one instance to be able to communicate with another, appropriate firewall rules must also be configured because every network has an implied deny firewall rule for ingress traffic

    • You cannot delete the implied rules, but you can override them with your own. 

  • Google Cloud always blocks some traffic, regardless of firewall rules; for more information, see blocked traffic.

 

Always blocked traffic

Google Cloud always blocks the traffic that is described in the following table. Your firewall rules cannot be used to allow any of this traffic.

Always blocked traffic

Applies to

Always blocked traffic

Applies to

GRE traffic

All sources and destinations, whether the source or destination is an internal IP address or an external IP address.

Protocols other than TCP, UDP, ICMP, AH, ESP, and SCTP to external IP addresses of Google Cloud resources

The type of resource further limits the protocol. For example, Network TCP/UDP Load Balancing supports only TCP and UDP, and a forwarding rule for protocol forwarding only processes a single protocol.

Egress traffic to TCP destination port 25 (SMTP)

Traffic from:

  • instances to external IP addresses on the internet

  • instances to external IP addresses of instances

 

Traceroute to external IP addresses

 

  • Tools like traceroute and mtr might provide incomplete results because the TTL doesn't expire on some of the hops. Hops that are inside and outside of Google's network might be hidden in these circumstances:

    • When you send packets from Compute Engine instances to external IP addresses, including external IP addresses of other Google Cloud resources or destinations on the internet.

    • When you send packets to the external IP address associated with a Compute Engine instance or other Google Cloud resource