GCP VPN route only works in one region: check dynamic routing

The US workload reaches the office prefix over the HA VPN without a problem, while the European workload in the same VPC gets nothing at all. Its route table carries no entry for the prefix, no tunnel is down, and no firewall rule changed. The tunnel and its BGP session are healthy in both directions. A VPC that spans regions is not the same thing as its learned routes spanning regions, and that gap explains the whole symptom.

Two properties are being confused here: where the subnets live, and where a learned next hop may be used.

Where the regional scope comes from

Cloud Router installs learned routes with a scope that follows the VPC's dynamic routing mode. In regional mode a route learned in one region is usable only by that region's resources, which is why the European table is empty instead of showing a broken next hop. In global mode eligible learned routes become available to resources in every region of the VPC. Read the current value before changing anything, because regional is the default. The setting lives on the network, not on the tunnel or on the router.

The inventory command is read-only and answers it in one line:

gcloud compute networks describe VPC_NAME --format='value(routingConfig.routingMode)'

Run it in the host project when the VPC is shared. The network belongs to that project, and a viewer role in the workload project may not even show the routing configuration. A quick answer from the wrong project is worse than no answer.

The change is one command and one direction

Switching is a VPC-wide control-plane edit, not a per-VM workaround: gcloud compute networks update VPC_NAME --routing-mode=GLOBAL. It is also one-way, because a network set to global cannot be returned to regional. Check the project and network name once more before running it, since the command does not ask for confirmation. The change deserves a maintenance note and the network owner's approval rather than a quick experiment on a shared VPC.

Every Cloud Router, VPN and Interconnect attachment in that network inherits the new scope at once. That includes the attachments nobody mentioned in the change request. Regions that never had the route before start receiving it as soon as the change lands, which is why there is no staged rollout for this switch.

Global is a scope, not a guarantee

Eligibility and preference are separate from scope. A route that conflicts with a more specific prefix, loses best-path selection, or is filtered by policy behaves exactly as it did before. Global mode widens where a route may be used; it does not decide which route wins. A learned route can be in scope and still lose to a static or more specific path on the same VPC.

That distinction matters because the mode change is easy to blame later. If the European subnet still has no route after the switch, the question is whether the route exists and is eligible, not whether the scope took effect. Prefix conflicts and next-hop health are the next two things to read.

The remote side advertises differently too

Advertisement behaviour follows the same setting. With default behaviour, a router in regional mode advertises the subnets of its own region, while global mode advertises the VPC's subnets more widely. Changing the mode therefore changes what the far side installs, not only what your own regions may use.

A custom advertisement list does not expand when the mode changes. If the on-premises router holds a hand-written list of ranges, the European prefix remains absent from it. The return path stays broken in that case even though the outbound route now exists. Check what the remote side installed rather than what you exported.

What the mode will never repair

Global routing does not grant public internet access, transit between unrelated VPCs, or missing static routes. It does not alter firewall rules or IAM, so a connection refused by policy stays refused.

Those failures look alike from inside a workload and have nothing to do with route scope.

Test from the far region to the real service, then confirm the reply comes back through the intended tunnel. Record the mode, the advertisement configuration and the destination you tested. If the test still fails, compare the remote router's BGP table with the VPC route list before touching the mode again. The next cross-region report then starts from facts instead of from a mode change.