Cloud VPN securely connects another network to your Google Cloud network over the public internet, using encryption.

The problem

Most companies do not move everything to the cloud at once. Some systems stay in their own data centers for legal, technical or financial reasons. Others live in a second cloud. This mixture is called a hybrid or multi-cloud environment. The pieces must communicate using private addresses and with the same safety as if they sat in one building. Sending that traffic across the open internet unprotected would be like shouting your bank details across a crowded market.

What is a VPN?

A virtual private network makes two separate networks behave as if they were one private network, even though the data travels over a shared public path. It does this by wrapping each piece of data in an encrypted envelope, sending it across the internet, and unwrapping it at the other end. The path an encrypted conversation takes is called a tunnel.

What is Cloud VPN specifically?

Cloud VPN is Google Cloud’s managed service for creating site-to-site IPsec VPN tunnels. “Site-to-site” means it joins two whole networks together, such as your office network and your Google Cloud network, not one person’s laptop to a network. “IPsec” is the standard set of rules for encrypting and authenticating network traffic. Because Google runs the gateway on its side as a managed service, you do not build, patch or scale a VPN server. You configure it, and Google operates it.

Five small ideas make everything else easy: IP addresses, private ranges, routing, encryption and BGP.

IP addresses and ranges

Every device on a network has an IP address, like a house number. A group of addresses is written as a range using slash notation, such as 10.0.0.0/16, which means “all addresses beginning with 10.0”. Private ranges such as 10.x.x.x, 172.16.x.x to 172.31.x.x and 192.168.x.x are reserved for internal use and are not reachable directly from the public internet. A VPN lets two networks use each other’s private addresses.

Routing

A route is a rule that says “to reach this range of addresses, send traffic this way”. A network device checks its routes for every packet, much as a traveler checks road signs. VPN traffic works only if both sides have routes that point to the tunnel.

Encryption and authentication

Encryption scrambles data so only someone with the right key can read it. Authentication proves that the other side is who it claims to be, and that the data was not altered on the way. IPsec provides both. The keys used for encryption are created fresh and changed regularly, so even if one were stolen, it would expose only a small slice of traffic.

IPsec and IKE

IPsec is the family of standards for protecting traffic at the network layer. A companion protocol, IKE (Internet Key Exchange), is the negotiation step: the two ends use it to agree on algorithms, prove their identities, and generate the shared keys. Cloud VPN’s high availability service uses version 2, called IKEv2.

BGP: routes that update themselves

Writing every route by hand is slow and error-prone. BGP, the Border Gateway Protocol, lets two networks tell each other which address ranges they can reach, and update automatically if something changes. It is the same protocol the whole internet uses to find its way around. On Google Cloud, a service called Cloud Router speaks BGP for you.

Cloud VPN has a handful of building blocks. Meeting them one by one makes any diagram easy to read.

The gateway and its interfaces

The Cloud VPN gateway sits in a specific region, such as Mumbai or Frankfurt, and belongs to one VPC network. In the high availability type, each gateway has two interfaces, each with a separate external IP address allocated by Google. Think of them as two separate front doors to the same mailroom. Having two doors is the heart of the high availability design.

Tunnels

A tunnel connects one Google interface to one interface on the peer. You usually build at least two tunnels, one from each Google interface, so that the loss of one does not break connectivity. Each tunnel carries both directions of traffic and has a bandwidth limit that we will examine in a later chapter.

Cloud Router and BGP

With dynamic routing, Cloud Router exchanges routes with the peer over BGP. When your office adds a new address range, the peer announces it, Cloud Router learns it, and routes in your VPC update themselves. When a tunnel fails, the matching routes are withdrawn and traffic moves to a healthy tunnel automatically. With static routing, you write the routes manually, and nothing updates itself.

Regional resources, global reach

A gateway lives in one region, but with global dynamic routing the learned routes can be shared across all regions of the VPC, so virtual machines in other regions can also reach on-premises networks through that gateway. We cover this in the routing chapter.

Cloud VPN comes in two types. One is the modern recommendation. The other is older and being phased out.

HA VPN: the modern choice

HA VPN stands for high availability VPN. Its gateway has two interfaces, each with its own external IP address. Google offers a 99.99 percent availability service level agreement for the Google Cloud side, provided you configure it in the recommended redundant way: two tunnels, one on each interface, with dynamic routing, to a properly redundant peer. It requires dynamic routing through Cloud Router and BGP, uses IKEv2, and supports both IPv4 and, in dual-stack setups, IPv6 traffic.

Classic VPN: the legacy option

Classic VPN has a single interface with a single external IP address, and a lower availability commitment, around 99.9 percent. It supports static routing, and in the past a form of dynamic routing. Google has deprecated Classic VPN, which means that you should not use it for new designs and should plan to migrate existing tunnels. Check Google’s current announcements for timelines and for any remaining supported scenarios.

Why two interfaces matter

Google needs to perform maintenance on its gateways from time to time. With one interface, maintenance means interruption. With two, Google can service one interface at a time while the other carries traffic. The 99.99 percent figure depends on you having tunnels on both interfaces, so that the surviving one picks up the load.

Let us put the building blocks together into a complete picture of a typical HA VPN connection.

flowchart LR
  subgraph ONP["Your data center or office"]
    SRV["Servers and users on 192.168.0.0/16"]
    PR1["Peer VPN device interface 0"]
    PR2["Peer VPN device interface 1"]
    SRV --- PR1
    SRV --- PR2
  end
  subgraph NET["Public internet"]
    T1["Encrypted IPsec tunnel 1"]
    T2["Encrypted IPsec tunnel 2"]
  end
  subgraph GCP["Google Cloud region"]
    GI0["HA VPN gateway interface 0"]
    GI1["HA VPN gateway interface 1"]
    CR["Cloud Router with BGP"]
    VPC["VPC network 10.0.0.0/16"]
    VM["Virtual machines and services"]
    GI0 --- CR
    GI1 --- CR
    CR --- VPC
    VPC --- VM
  end
  PR1 --- T1 --- GI0
  PR2 --- T2 --- GI1
    

Read the diagram from left to right. On the left is your own network with its servers. It connects to a VPN device, often a firewall or router, with two interfaces. Each interface builds an encrypted tunnel across the internet to one of the two interfaces on the Google Cloud VPN gateway. Inside the tunnels, Cloud Router and the peer router run BGP and exchange the address ranges they can reach. The learned routes appear in your VPC, so virtual machines can send traffic to on-premises addresses and have it automatically enter the tunnels.

Where each piece lives

• Google-managed: the VPN gateway service itself, its availability, and its software upkeep.
• In your Google Cloud project: gateway resources, tunnels, Cloud Router, routes, firewall rules and the VPC.
• Outside Google Cloud, your responsibility: the peer VPN device, its configuration, its internet connection and its availability.

The control side and the data side

It helps to separate two kinds of activity. The control plane is the set of conversations that set things up: negotiating keys with IKE and swapping routes with BGP. The data plane is the actual traffic of users and applications flowing through the tunnels. Problems in the control plane stop tunnels from forming or routes from appearing. Problems in the data plane show up as slow or broken applications even though everything looks “up”.

Different peers, same pattern

The right-hand and left-hand sides of the picture can be replaced by many things. The peer can be a hardware firewall in a branch office, a virtual router in a colocation facility, a gateway in another public cloud, or even another Google Cloud VPC with its own HA VPN gateway. The structure stays the same: gateways, tunnels, and routes.

Before any user data flows, the two gateways must introduce themselves, agree on rules and create keys. This is the work of IKE.

Phase one: building a secure conversation

The two gateways first send each other messages in the open to agree on which encryption methods they both support, and to run a mathematical exchange that lets both sides derive the same secret key without ever sending that key across the wire. Then they prove who they are, using the pre-shared key that an administrator typed in on both sides. After this step they have a protected channel for further negotiation. In IKEv2 this is called the IKE security association.

Phase two: creating the data tunnel

Next, within the protected channel, the gateways agree on which traffic will be sent through the tunnel and which keys will encrypt it. This creates the child security association, which uses a protocol called ESP (Encapsulating Security Payload). ESP wraps each packet in an encrypted envelope, adds a check value to detect tampering, and gives each packet a number to prevent replay attacks, where an attacker records a packet and sends it again later.

sequenceDiagram
  participant P as Peer gateway
  participant G as Cloud VPN gateway
  P->>G: IKE_SA_INIT with supported algorithms and key exchange values
  G->>P: IKE_SA_INIT with chosen algorithms and key exchange values
  Note over P,G: Both sides now compute the same shared keys
  P->>G: IKE_AUTH with identity and proof using pre-shared key
  G->>P: IKE_AUTH with identity, proof and traffic rules
  Note over P,G: Tunnel is established
  P->>G: ESP encrypted data packets
  G->>P: ESP encrypted data packets
  Note over P,G: Keys are refreshed periodically using rekey
  P->>G: Keepalive and dead peer detection messages
    

What goes over which port

IKE messages travel over UDP port 500. If a device in the path performs network address translation, that is, rewriting addresses on the fly, the traffic is switched to UDP port 4500 using a technique called NAT traversal. The encrypted data itself uses the ESP protocol. Firewalls on your side must allow these, or the tunnel will never come up.

Keeping the tunnel healthy

• Rekeying: Both sides replace the encryption keys on a schedule, so a stolen key has a short useful life. Mismatched lifetime settings are a common cause of brief outages.
• Dead peer detection: Small keepalive messages check that the other end is still alive. If the peer goes silent, the tunnel is marked down, and routes can fail over.
• Replay protection: Packet numbering lets the receiver discard duplicates.

Algorithms: the agreed recipe

Both ends must agree on a combination of methods for key exchange, encryption and integrity checking. Google publishes a list of supported ciphers, and recommends modern ones such as AES in Galois/Counter mode with strong key exchange groups. Using weak or obsolete settings might still connect, but weakens protection. Always check the current supported and recommended list before configuring the peer device.

A tunnel is only a road. Routing decides which traffic uses it.

Static routing

With static routing, an administrator writes down which ranges are reachable through which tunnel. It is simple and predictable, and fine for tiny, unchanging networks. But nothing adapts: if a tunnel fails, the static route may still point at it, and traffic is lost until a human fixes it. For this reason, HA VPN does not use static routes. It relies on dynamic routing.

Dynamic routing with Cloud Router

Cloud Router is a managed service that speaks BGP. It forms a BGP session with the peer router through each tunnel. The two exchange advertisements: Cloud Router tells the peer “I can reach these VPC ranges”, and the peer says “I can reach these on-premises ranges”. Routes then appear automatically, and disappear again if a session drops.

How BGP sessions are set up

• Each BGP session runs between two special addresses from the link-local range 169.254.0.0/16, a tiny private link used only for this conversation.
• Each side has an autonomous system number (ASN), an identity for a routing domain. Cloud Router and your peer must use different numbers, and private ranges of numbers are available for use.
• Sessions are kept alive by regular messages. If the messages stop for longer than a hold time, the session is considered down and its routes withdrawn.
• Optional BFD (Bidirectional Forwarding Detection) can detect failures in a second or so instead of tens of seconds.

Advertising the right ranges

By default, Cloud Router advertises the subnets of the VPC network. You can change this with custom advertisements, which allow you to announce additional ranges, for example a peered network’s ranges, or to announce only selected subnets. On the other side, you choose which on-premises ranges your peer announces. Advertising too much, or too little, is a frequent source of mysterious “I can ping A but not B” problems.

Dynamic routing mode: regional or global

A VPC network has a setting called dynamic routing mode. In regional mode, routes learned by Cloud Router are available only to subnets in the same region as the router. In global mode, they are available to subnets in every region of the VPC, and the VPC’s subnets in all regions are advertised to the peer. Global mode is convenient and is often needed for multi-region applications. Regional mode gives tighter control.

Priorities and choosing among tunnels

When two tunnels both lead to the same on-premises range, which is used? Two behaviors exist:

• Active/active: if routes have equal priority, traffic is shared across tunnels using ECMP (equal-cost multi-path routing), which spreads different flows over different tunnels. This adds up bandwidth and improves use of resources.
• Active/passive: if you give one set of routes a worse priority, using a value called MED, traffic uses the preferred tunnel, and the backup carries traffic only if the first fails. This is simpler to reason about but leaves the backup idle.

flowchart TB
  subgraph OP["On premises"]
    PR["Peer router with ASN 65001 announces 192.168.0.0/16"]
  end
  subgraph GC["Google Cloud"]
    CR["Cloud Router with ASN 64512 announces 10.0.0.0/16"]
    RT["VPC route table"]
    VMS["Virtual machines"]
    CR --> RT
    RT --> VMS
  end
  PR -- "BGP session over tunnel 1" --> CR
  PR -- "BGP session over tunnel 2" --> CR
  CR -- "Learned 192.168.0.0/16 via tunnel 1 and tunnel 2" --> RT
    

Networks fail. Good design assumes every piece will fail at some point and makes sure no single failure cuts the connection.

What can fail?

• A tunnel, because of an internet path problem or a configuration change.
• A Google gateway interface, during maintenance or a fault.
• Your peer device, from hardware failure or a software update.
• Your internet connection to a provider.
• A whole site, such as an entire data center.

Peer topologies recommended for HA VPN

flowchart LR
  subgraph PEERS["Two peer devices in your data center"]
    PA["Peer device A"]
    PB["Peer device B"]
  end
  subgraph GW["Google HA VPN gateway"]
    I0["Interface 0"]
    I1["Interface 1"]
  end
  PA -- "Tunnel A with BGP" --> I0
  PB -- "Tunnel B with BGP" --> I1
  DC["Your servers"] --- PA
  DC --- PB
  I0 --- CRT["Cloud Router"]
  I1 --- CRT
    

Capacity during failure

Redundancy is not just about connection but about capacity. If two tunnels each carry 2 Gbps and one fails, can the other carry the full 4 Gbps? If not, you will keep your connection but suffer congestion. Plan so that either path alone can handle your peak traffic, or accept and document the reduced performance.

Multi-region redundancy

If a whole Google Cloud region is unavailable, the VPN in that region cannot help you. Critical designs create HA VPN gateways in two regions, with Cloud Routers and tunnels in each, and use global dynamic routing and route priorities so traffic prefers the nearest region and falls back to the other.

A VPN rides the public internet, so its speed has natural limits. Knowing them avoids unpleasant surprises.

Bandwidth per tunnel

Each Cloud VPN tunnel supports a maximum bandwidth of about 3 Gbps in total, counting traffic in both directions, along with a limit on the number of packets per second. These are ceilings, not guarantees. Actual throughput depends on packet sizes, encryption overhead, the capacity of your peer device, and the quality of the internet path between the two ends. Many peer devices struggle to encrypt at high speed, so the device is often the real bottleneck.

Scaling out with more tunnels

If one tunnel is not enough, you add more tunnels and use ECMP to spread traffic across them, so total bandwidth rises. There are limits on the number of tunnels per gateway and per region, so check current quotas. An important detail is that ECMP balances by flow, meaning each individual connection stays on one tunnel. A single very large file transfer will not be spread across several tunnels, but many different connections will.

MTU and why packets get stuck

The MTU (maximum transmission unit) is the largest packet size a link will carry. Ordinary networks use 1500 bytes. Inside Google Cloud, the default VPC value is lower, and the VPN adds its own wrapper, which uses additional bytes for headers. The usable packet size inside the tunnel is therefore smaller than normal. If an application sends packets that are too large, they must be split into fragments, which slows everything, or they are dropped, and the connection hangs mysteriously. A classic symptom is that small requests work, such as pinging or logging in, but large transfers stall.

The usual cure is to set the MSS (maximum segment size) so that TCP connections naturally send smaller pieces, often done on the peer device, and to follow the MTU values that Google recommends in its documentation for tunnel traffic.

Latency and jitter

Traffic over the internet takes whatever route providers choose at the moment, so delay varies. Latency, the time for a message to travel, and jitter, the variation of that time, can be higher and less predictable than on a private line. This matters for voice, video, trading and chatty database calls. Measure real round-trip times between your site and the Google Cloud region, and choose a region near your users or data center.

Let us follow a single request from an on-premises computer to a virtual machine in Google Cloud, and see where each feature plays its part.

flowchart TD
  A["On-premises server sends packet to 10.0.1.5"] --> B["Peer router checks routes"]
  B --> C["Route says 10.0.0.0/16 is via the VPN tunnel"]
  C --> D["Peer gateway wraps packet in ESP and encrypts it"]
  D --> E["Packet crosses the public internet"]
  E --> F["Cloud VPN gateway receives and decrypts it"]
  F --> G["Packet enters the VPC network"]
  G --> H{"Firewall rules allow it?"}
  H -- "No" --> I["Packet dropped and optionally logged"]
  H -- "Yes" --> J["Virtual machine receives packet"]
  J --> K["Reply is sent to 192.168.4.20"]
  K --> L["VPC route sends reply via the tunnel"]
  L --> M["Cloud VPN gateway encrypts and returns it"]
    

Step by step

Symmetry matters

The reply must come back through the same VPN, or at least through a VPN that the original side recognizes. If the reply leaves through a different path, such as straight to the internet or through another tunnel that the peer’s firewall does not expect, connections break. This is called asymmetric routing, and it is a classic cause of connections that start but never complete.

A tunnel opens a road between two networks. Firewalls and permissions decide who may use it.

The VPN does not bypass the firewall

Traffic coming out of a VPN tunnel into your VPC is treated like traffic from any other source. VPC firewall rules still apply. By default, a VPC network blocks all incoming connections unless a rule allows them. So after you build a perfect tunnel, you will still need a rule that says “allow traffic from the on-premises range to these virtual machines on these ports”. Forgetting this is one of the most common reasons that a working tunnel seems broken.

Writing good firewall rules for VPN traffic

• Be specific about sources: use the on-premises ranges as the source, not “anywhere”.
• Be specific about destinations: target particular virtual machines using tags or service accounts, not every machine.
• Be specific about ports: allow only what is needed, such as database or web ports, rather than all traffic.
• Think in both directions: VPC rules control incoming traffic to cloud machines. If you restrict outgoing traffic, also allow replies and outgoing calls to on-premises.
• Use firewall policies at the organization or folder level for common rules, such as blocking risky ports from on-premises ranges everywhere.
• Turn on firewall logging for key rules, so you can see allowed and denied connections.

The on-premises side

The peer’s firewall must permit the IKE and ESP traffic that builds the tunnel, and must also allow the traffic inside it. Many data centers have security policies that treat VPN traffic as a separate zone. Make sure policies in that zone are reviewed, and not simply “allow any”.

Who can manage the VPN itself?

Google Cloud Identity and Access Management controls who can create or change gateways, tunnels, routers and routes. Network administrators need powerful roles, such as the Compute Network Admin role. Others should have read-only roles. Changing a tunnel’s settings or deleting it can take down production connectivity within seconds, so restrict these permissions to a small group and review them regularly.

A VPN exists to protect data in motion. Here are the layers that make that protection real.

Strong encryption and modern algorithms

Cloud VPN uses IPsec with encryption and integrity checks. Choose current, recommended algorithms, such as AES with Galois/Counter mode and strong key exchange groups, and disable old ones that are known to be weak. IKEv2 is required for HA VPN and is generally more robust and secure than the older IKEv1.

Pre-shared key hygiene

The pre-shared key is the secret by which the two ends recognize each other. A weak or leaked key lets an attacker try to impersonate a gateway. Good habits:

• Use a long random key, not a word or phrase. Google can generate one for you.
• Use a different key for each tunnel.
• Store keys in a secret manager and not in emails, chat messages or documents.
• Rotate keys on a schedule and after staff changes.
• Share keys over a secure channel, never in plain text.

Perfect forward secrecy

With perfect forward secrecy, every rekey creates fresh keys that are mathematically unrelated to previous ones. If an attacker somehow gets the key for today’s traffic, they still cannot decrypt yesterday’s recorded traffic. Make sure it is enabled on both ends, using the supported groups.

Limit exposure and blast radius

• Advertise the minimum ranges needed over BGP.
• Segment networks: use separate VPCs, or separate tunnels, for production and test, or for different business units.
• Apply organization policies to restrict who can create VPN resources and where.
• Keep the peer device secure: patch it, restrict administrative access, and monitor it. A compromised VPN device is a direct door into your cloud.
• Protect against route hijacking: filter routes accepted from the peer so that a mistake or attack cannot redirect your traffic.

Encryption is not everything

A VPN protects data while it crosses the internet. It does not protect data at rest, it does not stop a compromised machine inside the tunnel from sending harmful traffic, and it does not replace application security such as sign-in and authorization. Keep these in mind and treat the VPN as one layer of defense.

Logging and auditing

Cloud Logging records VPN gateway and tunnel events, such as tunnel establishment, IKE negotiation messages and errors. Admin activity audit logs record who changed what. Send alerts for tunnel flaps, unexpected configuration changes and BGP session drops. Keep logs long enough for investigations and compliance.

Cloud VPN is not only for connecting to physical offices. It also joins cloud networks to each other.

Google Cloud VPC to Google Cloud VPC

Two VPC networks can be joined by creating an HA VPN gateway in each and connecting them with tunnels. Both sides are managed in Google Cloud, so there are no third-party devices to configure. This is useful when VPC peering is not suitable, for example when you need to connect networks with overlapping features, need encryption between them, or need to control routing in detail. Peering is usually simpler and faster when it fits, but a VPN gives you the control that peering does not.

Connecting to another cloud provider

Companies using two or more clouds often connect them with VPN. The pattern is identical: a gateway on each cloud, tunnels between them, and BGP to exchange routes. Because each cloud has its own naming and its own details, the main tasks are matching the cipher settings, and configuring each side’s route tables and security rules. Google publishes guides for connecting to common providers. A typical arrangement uses four tunnels to match the number of interfaces on the other side’s gateway and to reach full redundancy.

Connecting a branch or a store

Small sites such as shops or branch offices can use a normal internet connection with an IPsec-capable router. With dozens or hundreds of sites, automation becomes essential: use templates and infrastructure as code to create tunnels consistently. For many small sites, you can also connect them through a hub, as described in the next chapter.

Typical multi-cloud checklist

When you have many networks, you need a design that stays understandable as it grows.

Hub and spoke

In a hub-and-spoke design, one central VPC, the hub, holds the VPN connection to on premises. Several other VPCs, the spokes, connect to the hub and use its VPN to reach on-premises. This avoids building a separate VPN for every spoke, centralizes security controls and keeps costs down.

flowchart TB
  DC["On-premises data center"] -- "HA VPN tunnels" --> HUB
  subgraph GCP["Google Cloud"]
    HUB["Hub VPC with HA VPN and Cloud Router"]
    S1["Spoke VPC: production"]
    S2["Spoke VPC: development"]
    S3["Spoke VPC: data platform"]
    HUB --- S1
    HUB --- S2
    HUB --- S3
  end
  FW["Central inspection and firewall rules"] --- HUB
    

The transitivity trap

A surprise that catches many beginners is that routing is not automatically transitive across VPC peering. If the hub is peered with a spoke, the spoke can reach the hub’s own subnets, but it does not automatically learn routes that the hub learned from the VPN. By default, the spoke cannot reach on-premises through the hub. Two common ways to solve this are:

• Custom route export and import: the hub exports its custom and dynamic routes over the peering, and the spokes import them. Cloud Router also advertises the spoke ranges to on-premises using custom advertisements.
• Network Connectivity Center: a Google Cloud service that acts as a managed hub, letting VPN tunnels and other spokes connect and exchange routes, including transit between on-premises sites over Google’s network.

Shared VPC

With Shared VPC, one project, the host project, owns the network and the VPN resources, while other projects, the service projects, run their virtual machines in subnets of that network. This lets many teams use one VPN connection without each building their own, while keeping central control of networking and security. It is a very common enterprise pattern.

Site-to-site data transfer through Google

With Network Connectivity Center, you can connect multiple on-premises sites, each with its own VPN to Google Cloud, and let them exchange data with each other across Google’s backbone network instead of the public internet. That makes Google’s network act as a private wide-area network between your sites.

VPN is one of several ways to connect to Google Cloud. Choosing well depends on bandwidth, reliability, cost and urgency.

The main choices

• Cloud VPN: encrypted tunnels over the public internet. Quick, low cost, moderate bandwidth.
• Cloud Interconnect, Dedicated: a physical connection from your network to Google at a colocation facility, with high capacity and consistent performance.
• Cloud Interconnect, Partner: a connection through a supported service provider, for places where you cannot reach Google’s facility directly, with a wide range of capacities.
• Cross-Cloud Interconnect: a dedicated link between Google Cloud and another cloud provider.
• Direct and carrier peering: ways to reach Google’s public services over a more direct path, but not for private VPC addresses.

Using them together

• VPN as backup for Interconnect: if the physical link fails, traffic fails over to VPN tunnels using route priorities. It is a cost-effective way to add resilience.
• HA VPN over Interconnect: runs IPsec tunnels across an Interconnect connection to add encryption where required by policy.
• VPN first, Interconnect later: start with VPN to get going, then add Interconnect when traffic grows.

Remote access for individuals is different

If you want employees to reach cloud resources from home, Cloud VPN is not the right tool, since it joins networks, not people. Options include identity-aware access to applications and administration tools, and client VPN software running on a virtual machine. Choose based on whether you need to reach a few applications or a whole network.

This chapter explains the order of work in plain words, so you understand what each step is for. Exact screens and commands change, so always follow the current documentation as you build.

flowchart TD
  A["Plan ranges, regions, peer type and redundancy"] --> B["Create or choose the VPC network"]
  B --> C["Create a Cloud Router with an ASN"]
  C --> D["Create the HA VPN gateway in the region"]
  D --> E["Describe the peer gateway as an external VPN gateway"]
  E --> F["Create tunnels: one per Google interface"]
  F --> G["Configure the peer device with matching settings"]
  G --> H["Create BGP sessions on Cloud Router"]
  H --> I["Configure BGP on the peer device"]
  I --> J["Add firewall rules for on-premises ranges"]
  J --> K["Test connectivity, performance and failover"]
  K --> L["Add monitoring, alerts and documentation"]
    

Infrastructure as code

Once you understand the steps, capture them in a tool such as Terraform. Written definitions are repeatable, reviewable and ideal for creating the same design in a test environment. They also leave a history of exactly what was changed, which is valuable when something goes wrong at midnight.

A tunnel that nobody watches is a tunnel that will fail quietly. Observability makes problems visible early.

What to measure

The tools

• Cloud Monitoring: gives metrics for gateways, tunnels and Cloud Router, with dashboards, uptime-style checks and alert policies.
• Cloud Logging: collects VPN gateway logs, including IKE negotiation messages, which are invaluable when tunnels refuse to come up.
• Audit logs: record administrative changes to VPN resources.
• VPC Flow Logs: sample the traffic flowing through the VPC, showing which on-premises addresses talk to which cloud machines.
• Firewall logs: show which connections were allowed or blocked.
• Network Intelligence Center: includes connectivity tests that analyze configuration and trace a hypothetical packet path, and topology views that show your network visually.
• The peer device’s own monitoring: do not forget it. Many problems begin on that side.

Alerts worth having

• Tunnel down for more than a short period.
• BGP session down or flapping repeatedly.
• Only one healthy tunnel remains, meaning redundancy is lost even though service continues. This is easy to miss and important to catch.
• Bandwidth above 70 to 80 percent of the planned capacity for a sustained time.
• Route count changes outside expected limits.
• Configuration changes to VPN resources outside change windows.

Most VPN problems fall into a few families. Work from the bottom up: tunnel, then routes, then firewalls, then applications.

A calm troubleshooting method

Plan for what happens on the bad days, because they will come.

Walk through the failures

Maintenance

Google periodically performs maintenance on VPN gateways. With HA VPN, only one interface is updated at a time, so correctly built redundant tunnels continue to carry traffic. During the short moment of switching, a few packets may be lost and some connections may reset. Applications should therefore retry briefly. On your side, plan firmware upgrades for peer devices one device at a time, never both together.

Recovery targets in plain words

Think about how long you can tolerate disconnection and how much traffic loss you can accept. If your application cannot survive even a minute of lost connectivity, you need redundant paths, fast failure detection with BFD, and applications with retry logic. If a short outage is acceptable, a simpler setup may be enough.

Practice failover

• Disable each tunnel in turn during a quiet period and measure the switch time.
• Simulate a peer device failure by shutting down its interface.
• Confirm that monitoring raised the right alerts and that the people on call knew what to do.
• Update runbooks with real timings and lessons.

Cloud VPN is one of the cheaper ways to connect networks, but costs still deserve attention.

What you pay for

Prices change and differ by region, so use Google’s current pricing page and calculator for exact figures. In many setups, the tunnel fees are small, and the egress traffic is the main driver.

Ways to spend less

• Right-size the number of tunnels. Two redundant tunnels are enough for many cases. Do not build ten unless you need the bandwidth.
• Reduce egress. Keep heavy data processing close to where data lives, compress data, cache results and avoid chatty calls across the link.
• Choose regions wisely. Rates and latency differ. Placing workloads in the same region as the gateway avoids extra inter-region transfer.
• Move bulk transfers to Interconnect if you constantly send many terabytes, since lower data transfer rates may outweigh port fees.
• Remove unused tunnels from old projects and experiments.
• Label and track costs by project and environment.

An honest view of strengths and limits helps you decide when Cloud VPN is the right connection and when it is not.

Choosing a connection style

Patterns are proven solutions. Anti-patterns look reasonable but lead to pain.

Patterns worth knowing

Anti-patterns to avoid

If you remember only one chapter for real work, make it this one.

A practical order of work for a production connection

Common mistakes beginners make

• Building one tunnel and believing the connection is redundant.
• Overlapping address ranges between networks.
• Forgetting VPC firewall rules and blaming the tunnel.
• Mismatched settings between the two ends, such as key, IKE version, lifetimes or ciphers.
• Ignoring MTU until large transfers fail.
• Using static routes and expecting automatic failover.
• Assuming routes pass through peering without exporting and importing custom routes.
• One peer device, one internet provider, or both tunnels on the same line.
• Sharing one key across all tunnels and sites.
• No alert for lost redundancy, so the second failure becomes the outage.
• Upgrading both peer devices at once during maintenance.
• Leaving Classic VPN in place without a migration plan.

Here are the common ways organizations use Cloud VPN, based on typical industry practice. Google publishes customer stories for named examples, and you should consult them for current details.

Once the basics are solid, a few extra topics make hybrid networks smoother and more robust.

Name resolution across the tunnel

Machines are usually reached by name, such as “billing.internal”, not by number. Both sides need to resolve each other’s names. Cloud DNS supports forwarding zones, which send questions about on-premises names to your internal DNS servers, and inbound server policies, which allow your on-premises servers to ask Google Cloud for names of cloud machines. Without DNS set up, the tunnel works for numbers but applications fail with confusing “host not found” messages.

IPv6 and dual stack

As the internet moves to IPv6, HA VPN supports dual-stack setups where tunnels carry both IPv4 and IPv6 traffic, with BGP exchanging both kinds of routes. If your organization is adopting IPv6, plan address ranges and firewall rules for both families, and verify that your peer device supports it.

Faster failure detection with BFD

BGP normally notices a dead peer only after a hold timer expires, which can take tens of seconds. Bidirectional Forwarding Detection sends tiny, frequent probes and can declare a path dead in about a second. It speeds up failover but can cause false alarms on noisy links, so tune thresholds with testing.

NAT and the peer behind a router

Sometimes the peer device sits behind another device that performs address translation. IPsec can still work using NAT traversal, which encapsulates the traffic in UDP port 4500. Make sure the translating device allows it and keeps the mapping alive.

Network Connectivity Center and site-to-site transit

For organizations with many offices, Network Connectivity Center can use VPN tunnels as spokes. It lets sites exchange traffic through Google’s network and share routes in a managed way, avoiding a tangle of one-to-one tunnels.

Migrating from Classic VPN to HA VPN

flowchart TD
  A["Inventory Classic tunnels, routes and peers"] --> B["Design HA VPN with two tunnels and BGP"]
  B --> C["Create HA gateway, Cloud Router and tunnels in parallel"]
  C --> D["Configure peer for new tunnels and BGP"]
  D --> E["Verify routes and test traffic"]
  E --> F{"Is HA VPN healthy?"}
  F -- "No" --> G["Fix and retest"]
  G --> E
  F -- "Yes" --> H["Shift traffic: prefer HA routes over Classic"]
  H --> I["Watch for a stable period"]
  I --> J["Remove Classic tunnels, routes and gateway"]
    

Building the new connection beside the old one means you can test without risk, prefer the new routes using priorities, and keep the old tunnels as a fallback until you are confident. Pay attention to address ranges and static routes that referred to the old gateway, and plan the work according to Google’s current deprecation timeline.

Operating at scale

• Quotas: know the limits on tunnels, routes and BGP sessions, and request increases early.
• Route limits: too many advertised routes can exceed limits, so summarize ranges where possible.
• Change control: treat routing and tunnel changes as production changes with review and rollback plans.
• Documentation: keep diagrams, address plans and contact details up to date.

Cloud VPN gives you a fast, affordable and encrypted way to join your networks to Google Cloud over the public internet. HA VPN, the recommended type, uses two interfaces, IKEv2 and dynamic routing through Cloud Router, and offers a strong availability commitment when built with two tunnels and a redundant peer. Behind the scenes, IKE builds keys, ESP wraps each packet, and BGP keeps routes current, so failures are handled automatically. Performance is bounded by per-tunnel limits, your peer device and the internet path, which makes MTU tuning, extra tunnels and sometimes Interconnect important. Security depends on strong settings, unique keys, least-privilege firewall rules and careful route control. With a good address plan, monitoring for lost redundancy, rehearsed failover and automation, a VPN becomes a dependable bridge between your worlds.