Cloud VPN is Google Cloud’s managed service for creating encrypted site-to-site connections over the internet.

VPN stands for Virtual Private Network. A network is simply a group of computers that can talk to each other. A private network is one that only trusted members can use. A virtual private network gives you a private connection even though the cables underneath are shared with the public internet. The word virtual means the privacy is created by software and encryption, not by laying your own private wire.

Cloud VPN connects a peer network, such as your office or data center, to a Virtual Private Cloud network in Google Cloud. It can also connect two Google Cloud VPC networks to each other. The traffic travels across the internet, but it is wrapped in IPsec, a well-known set of security rules, so outsiders cannot read it or change it without being noticed.

What Cloud VPN is and is not

Cloud VPN is a site-to-site service. It joins whole networks together so that machines on one side can reach machines on the other using private addresses. It is not a service for individual laptops dialing in from a coffee shop, and it does not send your traffic out to the public internet. Its only job is to connect your private network to your Google Cloud network through an encrypted tunnel.

Almost every company that uses the cloud ends up needing a private link between the cloud and somewhere else.

Very few organizations move everything to the cloud overnight. They keep some systems in their own data centers, some in other clouds and some in Google Cloud. These systems must talk to each other, and the conversations often contain sensitive business data. A private, encrypted link makes this safe without needing every server to be exposed to the internet.

The main alternatives

A VPN is not the only way to connect to Google Cloud. Dedicated physical links called Cloud Interconnect offer higher bandwidth and steadier performance, but cost more and take longer to arrange. Some teams start with a VPN and move to Interconnect later. Others keep the VPN as an encrypted backup. We will compare these options in detail later in this guide.

Networking has many short, confusing words, so let us define each one before we use it.

Cloud VPN comes in two gateway types, and one of them is clearly the modern choice.

HA VPN is the high-availability gateway. HA stands for high availability, which means the service is designed to keep working even when something fails. An HA VPN gateway has two interfaces, each with its own external IP address drawn from a separate pool. Each interface can hold multiple tunnels, so you can build redundancy and add capacity.

Classic VPN is the older gateway. It has a single interface and a single external IP address, and it supports static routing only. It does not support IPv6. Google recommends HA VPN as the highest-availability option, and offers a guide for moving from Classic to HA.

Throughout the rest of this guide we focus on HA VPN, because it is the gateway you should design with today. We will return to Classic VPN in the migration chapter.

A working HA VPN setup has a small set of building blocks that always appear together.

On the Google Cloud side you create a VPC network, a Cloud Router and an HA VPN gateway. On the other side you have a peer gateway, which Google Cloud represents with a resource describing its IP addresses. Between them you create VPN tunnels, and over each tunnel you run a BGP session so the two sides learn each other’s networks.

flowchart LR
  A["On-premises network"] --> B["Peer VPN gateway"]
  B -->|"Tunnel 1"| C["HA VPN gateway interface 0"]
  B -->|"Tunnel 2"| D["HA VPN gateway interface 1"]
  C --> E["Cloud Router"]
  D --> E
  E --> F["VPC network"]
        

What each part does

Before any data flows, the two gateways hold a carefully ordered conversation.

When a tunnel starts, the two gateways first need to prove they are who they claim to be. Cloud VPN uses a pre-shared key for this proof. They then negotiate which encryption methods they both support, and they create fresh secret keys. Only after all of this does encrypted traffic begin to flow.

sequenceDiagram
  participant A as Peer gateway
  participant B as HA VPN gateway
  A->>B: Start key exchange with proposals
  B->>A: Choose settings and respond
  A->>B: Authenticate with pre-shared key
  B->>A: Authenticate with pre-shared key
  A->>B: Create child keys for data
  B->>A: Confirm tunnel is established
  A->>B: Encrypted data packets
  B->>A: Encrypted data packets
        

Tunnel mode and what travels inside

Cloud VPN uses ESP in tunnel mode. That means the entire original packet, including its own addressing, is encrypted and placed inside a new outer packet addressed from one gateway to the other. Observers on the internet can see only the outer addresses, not what is inside.

Encryption builds the tunnel, but routing decides which traffic uses it.

A router is like a traffic sign that says which road leads to which city. With static routing, a person writes the signs by hand. If a new network appears on one side, someone must go and add a new sign. With dynamic routing, the routers tell each other automatically which networks they can reach, and they update the signs on their own when something changes.

HA VPN uses BGP only

Tunnels on an HA VPN gateway must use dynamic routing with BGP. The BGP sessions run on a Cloud Router. Your Cloud Router advertises the VPC subnets to the peer, and the peer advertises its own networks back. Google Cloud then adds those learned routes to the VPC so that virtual machines can reach the remote network.

Priorities and preference

When more than one path leads to the same destination, BGP needs a way to choose. Google Cloud lets you set priorities on the routes a Cloud Router advertises. Lower numbers are usually preferred, so you can make one tunnel the main road and another the backup. The best practice is to advertise the same prefixes on all links and use priorities, not different prefixes, to express preference.

With two tunnels you must decide whether both carry traffic or one waits as a spare.

In an active-active design, both tunnels carry traffic at the same time. The routers use equal-cost multipath to spread flows across both. Your total capacity is the sum of both tunnels, which is attractive for bandwidth. In an active-passive design, only one tunnel carries traffic while the other stays ready as a backup, and traffic moves to it only if the main tunnel fails.

Think about the failure case

A common planning mistake is to measure only normal conditions. Suppose each tunnel can carry a certain amount and your traffic needs most of the combined total. In active-active mode, when one tunnel fails, the survivor cannot handle everything and users feel slowness. Always ask: if one tunnel disappears, can the other still carry my busiest hour?

Google’s guidance is to prefer active-passive with a single HA VPN gateway, and active-active when you use multiple gateways, and to avoid active-passive setups with more than two tunnels, because available bandwidth can be wasted.

An SLA is a promise, and the promise only holds when you build the connection the recommended way.

SLA means service level agreement. For HA VPN, Google offers a 99.99 percent availability target for recommended topologies. That is roughly under an hour of allowed downtime in a whole year, compared with about nine hours for 99.9 percent. But the promise has conditions, and it applies to Google’s side of the connection together with a correctly built peer.

Common topologies

Conditions for the highest SLA

Each interface of the HA VPN gateway needs at least one tunnel to the matching peer interface. A single tunnel from a single interface does not qualify. The peer side must also be configured to meet the same level of redundancy, because the promise cannot cover a device Google does not control. Finally, an HA VPN gateway with only one interface in use has no availability SLA at all.

flowchart TD
  A["HA VPN gateway interface 0"] -->|"Tunnel A"| C["Peer interface 0"]
  B["HA VPN gateway interface 1"] -->|"Tunnel B"| D["Peer interface 1"]
  C --> E["On-premises network"]
  D --> E
        

A tunnel is a pipe of limited size, and knowing the size avoids surprises.

Each VPN tunnel has a limit on how many packets it can process every second. For Cloud VPN this limit is about 250,000 packets per second, counting traffic in both directions together. Depending on the average packet size, that limit corresponds to somewhere between about one and three gigabits per second of throughput. Small packets reach the packet limit sooner, so they bring the bandwidth down.

How to get more capacity

Why real speeds are often lower

Throughput also depends on distance and quality. Longer round-trip time and any packet loss reduce how fast a single connection can move data. Testing with a single stream often gives disappointing numbers, so engineers measure using several parallel streams to see the real capacity. Remember also that the tunnel carries traffic both ways in one shared limit.

The strength of your tunnel depends on the settings both gateways agree to use.

A cipher is a recipe for scrambling data, and a key is the secret ingredient. Both sides must use the same recipe, or they cannot understand each other. Cloud VPN supports both IKE version 1 and IKE version 2. IKEv2 is the modern version and is required for IPv6 on HA VPN. Only IKEv2 lets you choose which ciphers are used, which is a strong reason to prefer it.

Cipher families

Rules that prevent most problems

Three small technical details cause a surprising share of real-world VPN headaches.

MTU stands for maximum transmission unit, which is the largest packet size a network link will carry in one piece. When you wrap a packet in IPsec, the wrapping adds extra bytes, so the outer packet becomes bigger than the original. If it grows beyond the allowed size, it must be broken into pieces, which is slow and can fail on some devices.

Gateway MTU and payload MTU

Google’s documentation distinguishes two sizes. The gateway MTU applies to the outer encrypted packets that cross the internet. The payload MTU applies to the original packets before wrapping and after unwrapping, and it is smaller, because the wrapping needs room. Applications and operating systems should send packets that fit within the payload size, or fragmentation and slowdowns follow. The exact numbers are listed on Google’s MTU considerations page, so check it for your configuration.

IKE fragmentation

Some key exchange messages are large, especially when certificates or many proposals are involved. Cloud VPN supports IKE fragmentation, and you should enable it on the peer. Without it, large key exchange packets exceeding the gateway size can be dropped, and the tunnel may fail to come up. Some opening messages cannot be fragmented at all, which is another reason to keep proposals short.

NAT traversal

NAT, network address translation, rewrites addresses as traffic passes through a router. If a peer device sits behind such a router, the IPsec packets can be confused by it. NAT traversal solves this by wrapping IPsec packets in UDP on port 4500, which NAT devices handle well. Peers behind NAT must support it. Remember too that the peer needs a static, internet-routable address, so a device with a changing address is not suitable.

Cloud VPN is not only for offices; it also joins cloud networks to each other.

VPC to VPC

You can place an HA VPN gateway in each of two VPC networks and join them with tunnels. This is useful when the networks belong to different projects, different organizations or different regions, and you want an encrypted private link without using other peering methods. Because both ends are in Google Cloud, setup is simpler, with no third-party device to configure.

Google Cloud to another cloud

For Amazon Web Services and Microsoft Azure, you create the HA VPN gateway on the Google side and a matching VPN gateway on the other cloud, then build tunnels between them. Each provider has its own redundancy design. For example, a connection to AWS typically uses four tunnels to match how AWS organizes its gateway tunnels. Always follow the current official tutorial for the specific provider.

VPN can also run on top of dedicated links and act as the glue between many sites.

HA VPN over Cloud Interconnect

Cloud Interconnect provides dedicated physical connections between your network and Google. By default, Interconnect traffic is not encrypted, because it is private but not wrapped in IPsec. HA VPN over Cloud Interconnect places IPsec tunnels over the Interconnect connection, so you get both the reliability of a dedicated link and the encryption of a VPN. The traffic stays off the public internet entirely, which suits strict compliance rules.

Network Connectivity Center

Network Connectivity Center is a hub where you connect many sites and networks as spokes. HA VPN tunnels can serve as spokes, so branch offices can talk to each other through Google’s network, using the cloud as a backbone. This replaces a messy web of direct connections between every pair of sites with a tidy hub.

flowchart TD
  H["Network Connectivity Center hub"]
  A["Branch office A over HA VPN"] --> H
  B["Branch office B over HA VPN"] --> H
  C["Data center over HA VPN"] --> H
  H --> V["VPC network"]
        

Other advanced uses

Cloud VPN also supports reaching Google APIs privately from on-premises hosts, and terminating GRE tunnels on virtual machines for software-defined wide area network designs. These are specialized topics, and Google notes that troubleshooting overlay networks built this way is outside its support scope.

A smooth setup is mostly decided before you create the first resource.

Beginners often open the console and start clicking. A better habit is to prepare a short plan first, because several settings cannot be changed later, such as the gateway’s IP stack type and a tunnel’s cipher choices. A few minutes of planning avoid hours of rebuilding.

The decisions to make first

The setup workflow

A VPN is a security tool, but it needs its own care to stay secure.

Security for Cloud VPN has several layers: who can create and change VPN resources, how strong the encryption and secrets are, which traffic is allowed across the tunnel, and how you detect problems. Weakness in any layer can undo the strength of the others.

Remember the trust boundary

A VPN protects traffic while it travels between gateways. It does not protect data once it arrives inside either network. If a compromised machine sits in your office network, the VPN will faithfully carry its traffic into your cloud. That is why firewall rules, segmentation and application-level security remain essential even with a VPN.

Audit and change control

Record who changed tunnels, routes and keys. Review changes in a formal process, because a small routing change on a VPN can expose a network or cut off a whole office. Keep clear documentation of which tunnel connects which site and who owns each peer device.

If you cannot see the tunnel, you cannot trust the tunnel.

Google Cloud integrates Cloud VPN with its monitoring and logging tools. You can watch whether tunnels are established, how much data they carry, how many packets are dropped and whether BGP sessions are healthy. You can also read logs that record events such as tunnel negotiation steps and failures, which are very useful when something goes wrong.

What to watch

Alerts that pay off

Create alerts for a tunnel leaving the established state, for a BGP session going down, and for throughput approaching the capacity you planned. Send alerts to the people who can actually act on them, and test the alert path occasionally so you know it works.

Testing the path

Google’s Network Intelligence tools include connectivity tests that analyze whether a path between two endpoints should work, checking routes and firewall rules. They are a quick way to find out whether a problem lies in the VPN or in a rule somewhere else.

Most VPN problems fall into a handful of families, and a calm checklist solves them faster than guessing.

Work from the bottom up. First ask whether the two gateways can reach each other, then whether the tunnel is established, then whether BGP is up, then whether routes are present, and finally whether firewalls allow the traffic. Each step isolates a different layer.

Good troubleshooting habits

Change only one thing at a time and write down what you changed. Keep the logs from the moment of failure, since they may rotate away. When you contact support or the peer’s vendor, share tunnel names, regions, timestamps and exact error text so they can help quickly.

Every service has edges, and knowing them early prevents bad designs.

Other details to remember

The bill has a few simple parts, and the biggest one is often data leaving Google Cloud.

Cloud VPN pricing has three kinds of charges. First, an hourly charge for each tunnel attached to a gateway, at a rate that depends on the gateway’s location. Second, a monthly charge for IPsec traffic, which is billed as data transfer. Third, an hourly charge for an external IP address that is reserved for a gateway but not used by any tunnel.

For a feel of the numbers, Google’s own pricing example for a US region used a rate of a few cents per tunnel per hour for two tunnels, plus per-gigabyte transfer charges for outgoing data. Rates differ by region and change over time, so always use the pricing page and the calculator for your own location.

Where costs surprise teams

The best choice depends on bandwidth, budget, timeline and security needs.

A simple way to decide

If you still run Classic VPN, a planned move to HA VPN is the safest long-term direction.

Classic VPN gateways have one interface and use static routes, with a lower availability promise. With BGP for Classic tunnels deprecated, any design that needs dynamic routing, or any rebuild of an existing BGP tunnel, must go to HA VPN. Existing unmodified Classic tunnels continue to pass traffic, but BGP-based ones have no availability SLA, so waiting carries a risk.

A careful migration approach

flowchart LR
  A["Classic VPN in production"] --> B["Build HA VPN in parallel"]
  B --> C["Test routes and traffic"]
  C --> D["Shift preference to HA VPN"]
  D --> E{"Stable"}
  E -->|"Yes"| F["Remove Classic VPN"]
  E -->|"No"| G["Roll back and investigate"]
  G --> C
        

Teams that succeed repeat a few habits, and teams that struggle repeat a few mistakes.

Helpful patterns

Anti-patterns to avoid

A short checklist of habits shared by teams that run reliable VPNs.

Ownership and communication

VPN projects involve network engineers on both sides, security staff, cloud teams and application owners. Agree who owns each tunnel and who is called when it fails. Share peer device contacts in advance, because a failed tunnel at night is much worse when nobody knows who administers the other end.

Review regularly

Traffic grows, devices age and business needs change. Review capacity, cipher choices and routing every few months. A VPN that was perfect two years ago can be the bottleneck today.

These typical situations show how the ideas fit together.

The common thread is planning. Success depends less on clever settings and more on clear address plans, matching configuration on both sides, tested failover and steady monitoring.

Because HA VPN depends entirely on BGP, a little extra understanding here pays off for the whole life of the connection.

A BGP session is a conversation between two routers over a tunnel. The Cloud Router on the Google side and the router on the peer side introduce themselves, share which networks they can reach, and then keep checking that the other is still alive. When something changes, such as a new subnet or a failed tunnel, an update is sent immediately, so nobody edits tables by hand.

The settings you will meet

Regional or global learning

A common surprise is that learned routes may be visible only to subnets in the same region as the Cloud Router. If your applications run in several regions and all need to reach the office, choose the dynamic routing mode that shares learned routes across regions, or build gateways in each region. This single setting explains many cases where one region works and another does not.

Control what you share

Advertising everything is convenient, but it also tells the peer about every subnet you own. Use custom advertisements when only certain ranges should be reachable from the other side. In the opposite direction, apply filters on the peer so that unexpected routes are ignored. Both habits reduce the harm of a configuration mistake.

A VPN that has never been measured is a surprise waiting for the busiest day of the year.

Capacity planning means estimating how much traffic will cross the tunnel and making sure the design can carry it, even when part of it fails. Testing means proving those estimates are right and that failover behaves as expected. Both are easy to skip when everything seems fine, and both are very valuable when it does not.

Estimating the demand

Start by listing what will cross the link: database replication, file transfers, backups, application calls, monitoring data and user traffic. For each, estimate both the average and the peak, since the tunnel must survive the peak. Include growth for the next year, and remember that backups and batch jobs often create short, intense bursts that dwarf normal traffic.

Types of tests

Write acceptance criteria

Before the drill, write down what success looks like: how long failover may take, how much traffic loss is tolerable, and what throughput must be reached. With written targets, the result is a clear pass or fail, not an argument.

Building the tunnel is a project, but keeping it healthy is a habit.

After the first success, attention drifts elsewhere. Months later, a key expires, a peer device is upgraded, a new subnet is added and nobody remembers how the tunnel was set up. Good operations prevent these slow surprises through a few simple routines.

Keep the documentation alive

Maintain one diagram and one table that show each tunnel, its two endpoints, its ASNs, its address blocks, its owner and its purpose. Update them with every change. When an incident happens at night, this single page can save an hour of searching.

Practice incidents

Hold occasional tabletop exercises where the team talks through a scenario: a tunnel drops, BGP flaps or throughput collapses. Walk through who checks what, in which order. These conversations reveal missing contacts, unclear ownership and unclear alerts, all at no risk to production.

Keep an eye on the platform

Google announces changes through release notes and deprecation pages, as it did when BGP for Classic VPN was deprecated. Assign someone to follow them, so you learn about changes from a notice and not from an outage.

No. Cloud VPN connects whole networks to each other. It does not provide client-to-gateway or SSL VPN access for individual users on their own devices.

Use HA VPN for any new design. Classic VPN is legacy, supports only static routing and has a lower availability promise, and BGP for Classic tunnels is deprecated.

At least two for the highest availability, with one from each HA VPN interface to the matching peer interface. Add more for extra bandwidth, and follow the provider’s tutorial when connecting to another cloud, since some use four.

Each tunnel is limited by packet rate, roughly equal to between one and three gigabits per second depending on packet size. Real speeds also depend on delay, loss and the peer device.

For HA VPN, yes. Tunnels on HA VPN gateways must use dynamic routing with BGP through Cloud Router. Static routing applies to Classic VPN only.

In active-active both tunnels carry traffic at once, giving more capacity but less headroom after a failure. In active-passive one tunnel carries traffic and the other waits as a backup.

Yes, traffic through HA VPN tunnels is encrypted with IPsec, even when both ends are Google Cloud networks. Choose it when you specifically need that encryption or routing control.

Usually a firewall rule, a missing route or overlapping address ranges. An established tunnel proves encryption works, not that traffic is permitted.

No. Cipher settings cannot be edited after creation. You delete the tunnel and create a new one, so plan a maintenance window.

Yes, the peer needs a static, internet-routable IP address. Peers behind NAT must support NAT traversal.

No. Incoming traffic from the peer is free. You pay for tunnel hours and for outgoing data, plus any unused reserved external address.

When you need large, steady bandwidth or more predictable performance than the public internet can give. Many teams use Interconnect as the main path and HA VPN as the backup.

Yes. HA VPN over Cloud Interconnect adds IPsec encryption to a private dedicated connection, which suits strict compliance needs.

Routes through the failed tunnel are withdrawn and traffic moves to the remaining tunnel. This can take a little time, and the survivor must have enough capacity for peak load.

Watch tunnel state, BGP session state, throughput and dropped packets in monitoring, and set alerts for changes. Test real application traffic regularly as well.

The pre-shared key, IKE version, cipher choices, key lifetimes, the tunnel addresses and the ASNs used for BGP. Differences in any of these are the most common reason for failed or unstable tunnels.

Trust the official documentation. Supported ciphers, limits and prices change, and an article is only correct on the day it was written.

Learned routes may be limited to the region of the Cloud Router. Check the dynamic routing mode of the VPC network, or build gateways in each region that needs access.

Follow your organization’s security policy, and rotate immediately when someone who knew the key leaves or the key may have been exposed. Coordinate the change with the peer team, since both ends must update, and plan for a brief tunnel restart.

Yes, a gateway can hold several tunnels to different peers, using separate peer resources and BGP sessions. For many sites, consider a hub design with Network Connectivity Center to keep management tidy.

No. It protects traffic while it crosses the internet between gateways. Firewalls, segmentation, patching and application security are still needed on both sides.

Connect two test VPC networks with HA VPN. You avoid third-party devices, can practice BGP, tunnels and routes, can test a failover by disabling one tunnel, and can delete everything afterward to avoid ongoing charges.

A single stream is limited by round-trip time, packet loss and the way traffic is spread across tunnels. Test with several parallel streams, and compare results in both directions before drawing conclusions.

Usually the two sides use different ASNs, because the routers treat the connection as one between separate networks. Follow the guidance for your peer vendor and Google’s documentation, and agree on the values before building.

A diagram of gateways, tunnels and peers, the address and ASN plan, key storage location, contact details on the peer side, alert descriptions, the failover test results and a short runbook for common failures.

Cloud VPN gives you a quick, encrypted and well-understood way to connect your networks to Google Cloud, to other clouds and to each other. HA VPN is the gateway to build with today, combining two interfaces, BGP routing through Cloud Router and a strong availability target when built with redundant tunnels. The technology is only half the story. Careful address planning, matching settings on both sides, sensible capacity, strong secrets and regular failover testing are what turn a working tunnel into a dependable connection your business can trust.