GCP Cloud VPN: Check Gateway, Tunnel and Firewall in Order

Your console shows a green tunnel, on-premises monitoring still cannot reach a single instance, and rebuilding the tunnel looks like the obvious fix. It rarely is. An established tunnel proves only that two gateways finished the IKE exchange. It says nothing about whether a packet was ever allowed into your VPC.

Four decisions stand between that green icon and a reply, and they fail in a predictable order. Work them cheapest first.

Three objects, and only one of them encrypts

A VPN gateway owns the external address that your peer encrypts to. In the console you never create it by hand: pick or reserve an address inside the connection form and the gateway appears with it. An HA gateway takes two addresses on two interfaces, which matters at the quota check later.

A tunnel is the pairing between that gateway and the peer. It carries the shared secret and the traffic selectors it promises to protect. Those selectors are where most silent failures begin. A tunnel whose local selector covers 10.0.0.0/24 will not deliver 10.0.1.0/24, however healthy the status looks.

The far end keeps its own list, usually called an encryption domain, and the terminating hardware compares it with yours. Neither side negotiates a selector it was never given.

Routing type decides what reaches the route table

Cloud VPN offers three routing shapes and they do not mix cleanly. Policy-based routing keeps the static selector pairs, route-based routing expects you to add static routes yourself, and dynamic routing advertises prefixes through a Cloud Router over BGP. Choose one on purpose.

A dynamic tunnel with hand-written static routes beside it produces a route table that empties whenever the BGP session bounces.

Dynamic is the only shape that lets the protected prefixes change without rebuilding the tunnel, and it drags the Cloud Router into the set of objects you must verify. Static selectors stay workable when the peer is a hardware firewall that cannot speak BGP. Both ends then need the same ranges, and the more specific entry has to win on both. A pair that disagrees by one subnet establishes and then carries half your traffic.

The implied deny sits behind the tunnel

Ingress is evaluated against an implied deny at the lowest priority, and that rule does not care that the packet arrived encrypted. Until a firewall rule names the on-premises range and the port in use, the packet is decrypted, inspected, and dropped. The VPN log stays clean throughout, because the tunnel did exactly what it promised.

Read the firewall denial log instead when the tunnel is up and the probe times out, then scope a rule to the source range and the ports you need:

gcloud compute firewall-rules create allow-from-dc \
  --network=vpn-vpc \
  --direction=INGRESS \
  --source-ranges=192.168.10.0/24 \
  --allow=tcp:22,tcp:5432,icmp

One direction working is a firewall clue

Egress behaves differently, because the implied allow rule lets instances send anywhere. A data centre that cannot reach a VM often sits behind a perfectly working outbound path in the other direction. That asymmetry separates a firewall omission from a routing fault, since a routing fault breaks both directions at once. Test the reverse direction before you edit one more rule.

Address creation is a quota operation as well. A project near its in-use external address limit rejects the connection with an error that reads like a permission failure.

Selectors, quotas, then the four checks

Console-created tunnels sometimes return an empty remote traffic selector from gcloud compute vpn-tunnels describe while generated routes carry traffic correctly. Compare what the API records against the ranges you actually protect before deciding the tunnel is wrong. Creating it through the API or SDK keeps the selector explicit.

Quotas are the other easy miss. Request the increase before the maintenance window rather than during it, and check the address count in the same project as the gateway.

Work from the outside in: peer status, both selector lists, a route for each side, an ingress rule for the source range and port, then a packet capture. Write the gateway address, both selector lists and the routing type into the change ticket while the tunnel is new, because the next engineer to add a subnet will need all three.