To define and create a subnet within a VPC network, use the GCP console or the gcloud CLI. If you’ve ever wished it was easier to extend a subnet range after creating it and assigning IP addresses to resources, then GCP has you covered—you can extend a subnet range without disrupting running services. For example, you can expand a subnet with a prefix mask of /20 to a prefix max of /16 without having to reconfigure your existing workload.
Routing is the process where network packets are directed from their source toward their destination through intermediate network nodes. When you’re managing an on-premises network, these intermediate network nodes are typically network hardware devices such as routers, gateways or firewalls.
Routing on GCP is carried out through Google’s software-defined network (SDN). GCP routes tell the VPC network where to send packets destined for a particular IP address. When you create a network, it has default routes created that let instances in a network reach each other across subnets as well as for internet traffic. You can also add user-defined routes for specific destination ranges that direct traffic to a VPN tunnel, a specially configured instance, or some other destination that you can configure using the console or the gcloud CLI.
A route alone is not enough to get a packet to its destination. You’ll need to configure firewall rules to permit the packet to reach its destination.
With a traditional on-premises stateful firewall, you have a firewall within your network, and all traffic between subnets or the internet passes through it. With these on-premises firewalls, you’re required to configure a set of rules that set up access lists between source and destination IP addresses or ports. You configure actions for each rule: allow (accept), drop (deny), track and log. Many of these firewalls have additional functionality, but all have the core ability to define the rules.
The difference when using GCP networking is that every VPC network functions as a distributed firewall. Firewall rules are defined at the network level and connections are allowed or denied on a per-instance basis. You can think of GCP firewall rules as existing not only between your instances and other networks, but between individual instances within the same network.
GCP firewalls are stateful, and as with traditional on-premises firewalls, also provide the core capability of setting up accept/deny rules. However, there are some other GCP firewall configuration capabilities that are definitely worth understanding to give you a lot more flexibility.
One feature is the ability to set up source and target filtering rules for ingress rules by using service accounts. A service account represents an identity associated with a Compute Engine virtual machine (VM) instance. This means that you focus on setting up rules where the source or destination is an identity rather than an IP address. When you set up a rule with a service account as the source, it matches connections that have a source IP address the same as the primary internal IP address of the instances you created with that service account. Where the target is a service account, the rule is assigned only to instances in the network that were created by that service account. This adds flexibility and helps reduce human error by allowing the configuration of firewalls by intent. For example, if you name your service accounts so they reflect their role, you are essentially telling the web servers (a service account ID = web server) to communicate with the application servers (service account application servers).You do not need to worry about IP addresses.
Another option for firewall routing with GCP is network tags, which are a way for networks to identify which instances are subject to certain firewall rules and network routes. Network tags are less secure than service accounts, but they’re a good fit for specific use cases with less stringent security requirements, like development configurations. You cannot use both service accounts and tags in the same rule.
An IPSec virtual private network (VPN) allows you to connect your VPC network to your physical, on-premises network or to another cloud provider. At the on-premises site, you will need an IPSec VPN gateway. At the GCP end, the Cloud VPN lets you set up a virtual VPN gateway running in GCP, which allows you to forward packets through the VPN. This can be configured via the console or the gcloud CLI.
When configuring the VPN between your on-premises network and a VPC network, you can dynamically advertise routes using the internet routing protocol Border Gateway Protocol (BGP) through the VPN connection established with GCP. In GCP, you’ll create BGP peering between the on-premises network and a Cloud Router on GCP, dynamically exchanging all relevant routes. At the on-premises end, you therefore need to configure a VPN gateway or router with BGP capabilities.
This diagram shows how this setup works in practice: