Cloud VPN in GCP Explained: HA VPN, Setup, and Troubleshooting

Simple explanation

Your office network and your GCP VPC are two separate environments with no natural path between them. Cloud VPN creates a secure connection across the public internet so they can communicate privately.

On the GCP side, a VPN gateway sits at the edge of your VPC. On the on-premises side, your existing router or firewall acts as the other endpoint. The two gateways negotiate an IPsec session, agree on encryption keys, and then encrypt all traffic flowing between them. Nothing in between can read it.

Cloud Router handles routing on the GCP side. Instead of manually entering static routes on both sides of the tunnel, Cloud Router runs BGP, a protocol that lets both routers automatically tell each other which address ranges they own. Your VPC routes update automatically as tunnels come up or go down.

What is Cloud VPN?

Cloud VPN is GCP’s managed IPsec VPN service. It creates encrypted tunnels between a GCP VPC network and a remote network. This is typically an on-premises data centre, office, or another cloud. All traffic through the tunnels is encrypted using IKEv2 by default.

GCP offers two VPN types. HA VPN (High Availability VPN) is the current recommended option. It creates a gateway with two redundant interfaces, each with its own external IP address, and achieves a 99.99% SLA when configured with BGP and at least two tunnels. Classic VPN is the older option: a single-interface gateway with no high availability SLA. Google recommends treating Classic VPN as legacy and not using it for new deployments.

Cloud VPN is distinct from Cloud Interconnect, which uses a dedicated physical or partner circuit instead of the public internet. VPN is faster to set up and lower cost at moderate throughput. Interconnect is better when dedicated bandwidth, latency predictability, or compliance requirements exclude internet-based connectivity.

Cloud VPN is also unrelated to VPC Peering, which connects two GCP VPC networks directly using Google’s internal backbone. VPC Peering is for GCP-to-GCP connectivity only, not on-premises integration.

How Cloud VPN works

When an HA VPN connection is running, traffic flows like this:

1. A packet leaves your on-premises server heading toward a GCP resource.
2. Your on-premises VPN gateway encrypts the packet using IPsec and sends it over the internet.
3. The GCP HA VPN gateway receives the packet, decrypts it, and forwards it into the VPC.
4. Return traffic follows the same path in reverse. The VPC knows where to send it because Cloud Router has already exchanged BGP routes with your on-premises router.

BGP is what makes the routing automatic. In plain terms, it is a protocol that lets two routers tell each other which IP ranges they own. Your on-premises router says “I own 10.0.0.0/8” and Cloud Router responds “I own 192.168.1.0/24”, and both sides update their route tables without you managing any static routes.

In a fully redundant HA VPN setup there are four tunnels total: two GCP gateway interfaces each connecting to two on-premises gateway interfaces. If one tunnel fails, traffic shifts to the remaining active tunnels automatically. The 99.99% SLA only applies when all four tunnels are configured and both BGP sessions are active.

When to use Cloud VPN

Cloud VPN is a good fit when:

• You are connecting an office, data centre, or colocation site to GCP and internet-based transport is acceptable
• You are running a hybrid migration and need temporary secure connectivity before committing to a permanent architecture
• You need private access from on-premises systems to GCP workloads, databases, or internal services without exposing them publicly
• You are setting up disaster recovery or backup connectivity to GCP where cost matters more than raw throughput
• Your per-tunnel bandwidth requirements are under roughly 3 Gbps (multiple tunnels with ECMP can scale throughput beyond that)

See the hybrid connectivity overview for a full comparison of GCP connectivity options including cost trade-offs and architecture guidance.

When not to use Cloud VPN

• High throughput or predictable latency. If your workload needs sustained high bandwidth or cannot tolerate internet jitter, use Cloud Interconnect instead.
• Connecting two GCP VPCs. If you want to connect two VPC networks within or across GCP projects, VPC Peering or Shared VPC is the right approach, not Cloud VPN.
• Regulatory requirements that prohibit internet transit. Some compliance frameworks require data to travel only over private dedicated circuits. Cloud VPN traverses the public internet even though traffic is encrypted. Cloud Interconnect does not.

HA VPN vs Classic VPN

GCP offers two VPN types. Use HA VPN for all new deployments.

Classic VPN is still available but should be treated as a migration target, not a starting point. If you have existing Classic VPN deployments, plan to move them to HA VPN.

Cloud VPN vs Cloud Interconnect

Cloud VPN and Cloud Interconnect both connect your on-premises network to GCP, but they use fundamentally different transport paths. VPN goes over the public internet; Interconnect uses a dedicated private circuit.

For most teams starting a hybrid deployment, Cloud VPN is the right choice. Interconnect becomes worthwhile when data transfer volumes, latency sensitivity, or compliance requirements push you toward a private circuit.

Cloud VPN vs VPC Peering

VPC Peering connects two GCP VPC networks directly using Google’s internal backbone. There is no internet transit, no encryption overhead, and no VPN gateways involved. It is purely for GCP-to-GCP connectivity.

Cloud VPN connects an on-premises or external network to a GCP VPC over the internet using IPsec. If your goal is to link two GCP projects or VPCs, use VPC Peering or Shared VPC. If your goal is to connect an on-premises network to GCP, use Cloud VPN.

They are not alternatives to each other. They solve completely different connectivity problems.

Setting up HA VPN

An HA VPN deployment has four components: a Cloud Router, an HA VPN gateway on the GCP side, a peer VPN gateway resource representing your on-premises device, and the VPN tunnels connecting them.

Prerequisites

• An existing VPC network in the target region
• A compatible on-premises VPN device that supports IKEv2 and BGP
• The external IP addresses of your on-premises VPN gateway interfaces
• An ASN for your on-premises router (it must differ from the ASN you assign Cloud Router)

Step-by-step

# Step 1: Create a Cloud Router for BGP routing
gcloud compute routers create ha-vpn-router \
  --network=my-vpc \
  --region=europe-west1 \
  --asn=65001

# Step 2: Create the HA VPN gateway on the GCP side
# GCP assigns two external IPs, one per interface
gcloud compute vpn-gateways create ha-vpn-gw \
  --network=my-vpc \
  --region=europe-west1

# Inspect the gateway to note the two external IPs on interface 0 and interface 1
gcloud compute vpn-gateways describe ha-vpn-gw \
  --region=europe-west1

# Step 3: Create a peer VPN gateway resource representing your on-premises device
# Replace these IPs with your actual on-premises gateway addresses
gcloud compute external-vpn-gateways create on-prem-gw \
  --interfaces=0=203.0.113.1,1=203.0.113.2

# Step 4: Create two VPN tunnels, one per HA VPN gateway interface
gcloud compute vpn-tunnels create ha-tunnel-0 \
  --peer-external-gateway=on-prem-gw \
  --peer-external-gateway-interface=0 \
  --region=europe-west1 \
  --ike-version=2 \
  --shared-secret=SHARED_SECRET \
  --router=ha-vpn-router \
  --vpn-gateway=ha-vpn-gw \
  --vpn-gateway-interface=0

gcloud compute vpn-tunnels create ha-tunnel-1 \
  --peer-external-gateway=on-prem-gw \
  --peer-external-gateway-interface=1 \
  --region=europe-west1 \
  --ike-version=2 \
  --shared-secret=SHARED_SECRET \
  --router=ha-vpn-router \
  --vpn-gateway=ha-vpn-gw \
  --vpn-gateway-interface=1

Always specify —ike-version=2 unless your on-premises device cannot support IKEv2. The peer gateway resource is a logical placeholder that stores your on-premises IP addresses so GCP knows where to direct tunnel traffic.

Configuring BGP

After creating the tunnels, configure BGP on the Cloud Router. Each tunnel needs a BGP interface on the Cloud Router side and a corresponding BGP peer entry representing the on-premises router.

BGP sessions inside VPN tunnels use link-local addresses in the 169.254.x.x range. These addresses are not routable on the internet. They exist only inside the tunnel between the two endpoints. Each tunnel uses a unique /30 block from this range, providing two usable addresses: one for the GCP side and one for the on-premises side.

# Add BGP interface for tunnel 0
gcloud compute routers add-interface ha-vpn-router \
  --interface-name=bgp-tunnel-0 \
  --vpn-tunnel=ha-tunnel-0 \
  --ip-address=169.254.0.1 \
  --mask-length=30 \
  --region=europe-west1

# Add BGP peer for tunnel 0
# The on-premises router uses the other address in the /30: 169.254.0.2
gcloud compute routers add-bgp-peer ha-vpn-router \
  --peer-name=bgp-peer-0 \
  --interface=bgp-tunnel-0 \
  --peer-ip-address=169.254.0.2 \
  --peer-asn=65002 \
  --region=europe-west1

# Add BGP interface for tunnel 1 (use a different /30)
gcloud compute routers add-interface ha-vpn-router \
  --interface-name=bgp-tunnel-1 \
  --vpn-tunnel=ha-tunnel-1 \
  --ip-address=169.254.1.1 \
  --mask-length=30 \
  --region=europe-west1

# Add BGP peer for tunnel 1
gcloud compute routers add-bgp-peer ha-vpn-router \
  --peer-name=bgp-peer-1 \
  --interface=bgp-tunnel-1 \
  --peer-ip-address=169.254.1.2 \
  --peer-asn=65002 \
  --region=europe-west1

Verifying tunnel and BGP status

After configuring BGP, run these checks before treating the connection as operational.

# List all tunnel statuses in the region
gcloud compute vpn-tunnels list \
  --region=europe-west1

# Check a specific tunnel in detail
gcloud compute vpn-tunnels describe ha-tunnel-0 \
  --region=europe-west1 \
  --format="get(status,detailedStatus)"

# Check Cloud Router BGP sessions and learned routes
gcloud compute routers get-status ha-vpn-router \
  --region=europe-west1 \
  --format="json(result.bgpPeerStatus)"

A working connection shows ESTABLISHED for both the tunnel status and the BGP peer status. The Cloud Router status output also lists routes learned from the on-premises network and the prefixes being advertised back. Verify that both sides are exchanging the expected prefixes before declaring success.

Verification checklist

• Both tunnels show status: ESTABLISHED
• Both BGP sessions show bgpSessionStatus: ESTABLISHED
• Learned routes include your on-premises prefixes
• Advertised routes include your GCP subnet ranges
• Traffic flows in both directions, tested with ping or curl to an internal IP address

Scaling throughput

Each HA VPN tunnel supports up to approximately 3 Gbps of combined ingress and egress throughput. If you need more, create additional tunnels between the same gateways. Cloud Router uses ECMP (Equal Cost Multi-Path) routing to distribute traffic across tunnels that advertise the same routes at equal BGP metrics.

The four-tunnel fully redundant pattern already provides high availability. Additional tunnel pairs beyond that increase aggregate throughput while maintaining redundancy.

Troubleshooting Cloud VPN

Most Cloud VPN problems fall into four categories. Work through each one systematically rather than guessing.

Tunnel not establishing

• Confirm the shared secret matches exactly on both sides (it is case-sensitive)
• Verify both sides are configured for the same IKE version since a mismatch causes negotiation failure
• Check the peer gateway IPs are correct in the tunnel configuration

BGP not establishing

• Run gcloud compute routers get-status ha-vpn-router —region=europe-west1 and inspect bgpPeerStatus
• Confirm the ASN values are consistent on both sides: Cloud Router’s ASN and the peer ASN you configured must match what your on-premises device expects
• Verify the link-local IPs are correct (Cloud Router uses the .1 address in each /30; the on-premises device should use .2)
• Confirm the tunnel itself is in ESTABLISHED state first, since BGP cannot run over a failed tunnel

Routes not being learned

• Check that your on-premises router is actively advertising the correct prefixes over BGP
• Look at the learnedRoutes section in the gcloud compute routers get-status output
• Check routes in GCP to confirm that Cloud Router-learned routes are appearing in your VPC route table
• Verify Cloud Router is advertising your VPC subnets back to the on-premises router (by default it advertises all primary subnet ranges in the region)

Tunnel established but no traffic flows

1. Confirm both BGP sessions are ESTABLISHED using gcloud compute routers get-status
2. Check route advertisements and learned prefixes in the Cloud Router status output
3. Validate subnet route propagation and route priorities using the routes in GCP guide
4. Check firewall rules allow the expected internal service ports in both directions
5. Confirm you are using private IP addresses since traffic destined for a public IP will not route through the VPN tunnel
6. Follow the systematic diagnostic steps in the troubleshooting network issues guide for further analysis

For broader network security hardening of your hybrid setup, including VPN best practices, see the network security best practices guide.

FAQ

What is the difference between HA VPN and Classic VPN in GCP?

HA VPN uses two gateway interfaces and requires BGP via Cloud Router, giving it a 99.99% availability SLA when configured with redundant tunnels. Classic VPN uses a single interface, has no HA SLA, and supports static routing. For all new deployments, use HA VPN. Google recommends migrating existing Classic VPN setups to HA VPN.

Does Cloud VPN use the public internet?

Yes. Cloud VPN encrypts your traffic using IPsec and sends it over the public internet between your on-premises gateway and GCP. The encryption protects the data in transit, but the path itself crosses the internet. If you need a dedicated private circuit that never touches the public internet, use Cloud Interconnect instead.

Do I need Cloud Router for HA VPN?

Yes. HA VPN requires dynamic routing via BGP, which means Cloud Router is mandatory. You cannot use HA VPN with static routes. After creating your tunnels, you configure BGP interfaces and peer entries on the Cloud Router, and it handles route exchange with your on-premises router automatically.

When should I choose Cloud Interconnect instead of Cloud VPN?

Choose Cloud Interconnect when you need dedicated bandwidth, stable low-latency connectivity, or a transport path that does not traverse the public internet. Cloud VPN is simpler and cheaper to set up but shares the internet path and caps each tunnel at roughly 3 Gbps. Interconnect is the better fit for production workloads where throughput consistency and private connectivity take priority over cost or provisioning speed.

Can Cloud VPN replace VPC Peering?

No. VPC Peering connects two GCP VPC networks directly using Google’s internal routing, with no internet transit, no encryption overhead, and no VPN gateways. Cloud VPN connects an on-premises or external network to a GCP VPC over the internet using IPsec. They solve completely different connectivity problems and are not interchangeable.