Cloud Run to On-Premises VPN: Direct VPC Egress Setup

The tunnel is up, a VM reaches the on-premises server, and the Cloud Run service times out on the same host. That is the normal starting point for this task, and the tunnel is rarely what is wrong. A Cloud Run revision does not sit in your VPC by default, and once it does, it uses its own source addresses rather than the VM subnet you already routed. The runbook below attaches the service, routes its actual source range, and then proves the path from the revision that served the request. Run it in that order, because skipping the first step is why so many of these cases end in a VPN change that fixes nothing.

Attach the revision before debugging the tunnel

Cloud Run supports Direct VPC egress, which puts the service's traffic on a subnet in your VPC without a Serverless VPC Access connector. For an existing service the update looks like this:

gcloud run services update SERVICE \
  --region=REGION --network=NETWORK --subnet=SUBNET \
  --vpc-egress=private-ranges-only

Replace the placeholders, review what the deployment does to live traffic, and choose a subnet in the service's region with enough address capacity and the right network permissions.

Choose the egress mode that matches the destination

private-ranges-only sends the destinations it classifies as private through the VPC. It does not mean "anything reachable over the VPN", and that gap appears when the on-premises service sits in a range the setting does not classify that way. If the destination is not covered, all-traffic is the other documented mode, and it sends everything through the VPC, including the service's public dependencies. Choose deliberately and write the consequence into the change record.

A service already using a connector is a migration rather than a toggle, so plan it instead of configuring both.

Route the Cloud Run source, not a VM source

Direct VPC egress allocates ephemeral addresses from the selected subnet, and the on-premises side has to return traffic to that range. A return route or firewall allowance written for a different VM subnet will look correct in the diagram and fail in practice. Take the subnet CIDR from the VPC rather than from memory, then confirm the remote device's crypto ACL or route table includes it.

With dynamic routing, verify what Cloud Router actually advertises and what the VPC imports, including any custom advertisement policy. A route that exists in the console but is not selected for this destination is the same as no route.

Three conditions that must all hold

A working path needs all of the following, and each one fails in its own way:

• A route in the VPC toward the on-premises prefix through the intended Cloud VPN connection.
• A reverse route on-premises for the Cloud Run subnet.
• Firewall and IPsec protection scope permitting the source, destination and port.

A missing route usually looks like a timeout with no remote-side evidence. A reverse-route problem looks like the request arriving and the reply disappearing. A firewall or selector problem can look like a refusal or like a silent drop, depending on the device. Working out which of the three you have narrows the next command considerably.

Do not allowlist a single temporary Cloud Run address. Use the subnet range and an authorization design that fits the application.

Test the revision that served the request

Inspect the deployed network settings and the traffic allocation before you test, because an update can create a new revision while requests still reach an older one. Then exercise the same operation the user's request exercises, from that revision. If the destination is a private hostname, check its resolution in that environment and the address it produced, since your laptop's corporate DNS answer proves nothing about the service's namespace. Keep TLS hostname verification and the remote application's own authentication in place.

Expect the documented Direct VPC startup connection delays, and give the client a readiness or retry strategy instead of diagnosing every cold start as a broken tunnel.

Rollback and what this does not do

To roll back, revert the service's network and egress settings to their previous values and confirm the earlier revision still serves traffic. Keep the gcloud command in the change record, because the reverse of a partial change is not obvious six weeks later. Removing the VPC attachment returns the service to its previous egress path, which may be exactly what you want during an incident.

This design covers connections Cloud Run initiates and their replies. It does not give the on-premises network an addressable socket inside the service, because inbound exposure is an ingress decision.