VPN into the VPC works, but the managed service times out

Reaching a managed database through a VPN usually fails for a reason nobody wrote in the runbook: the tunnel terminates at your network edge, while the service never sat on your side of it. The route table looks correct, the tunnel reports up, and the connection times out anyway. Work the four checks below in order and stop at the first one whose pass condition is false, because every check after it assumes the earlier ones held.

Check one: where does the endpoint actually live?

A VPN gateway joins two networks whose addressing you control. A managed service is operated behind the provider own front door, and that door takes one of three shapes depending on the product. If you do not know which shape you are dealing with, no amount of routing work will help, because the failure may not be a routing failure at all.

Most wasted afternoons come from skipping this classification and going straight to the route table. A provider-hosted service with a public endpoint is not behind your tunnel whatever the diagram says, and a VPC-attached one will never turn up in a public DNS answer.

Check two: a VPC-attached service such as ElastiCache

Caches of that kind are addressed inside your own VPC and have no internet-facing listener at all. A client VPN terminated in that same VPC can reach them, but only when three conditions line up. The cache endpoint has to be associated with subnets your tunnel can see, its security group has to permit the address your clients arrive from, and the client side needs a route that covers the cache subnets.

The common mistake is assuming that a connection somewhere nearby counts. Attaching the VPN to a different VPC, or leaning on peering alone, does not extend the cache security group or its subnet route table to your clients. When the existing tunnel terminates elsewhere, a jump host or a VPN server placed inside that VPC is the usual fallback. That fallback is a workaround rather than a design, and it should be labelled as one in the runbook.

Check three: a PaaS endpoint with a public name

Azure Database for PostgreSQL presents a public server name. It does not hand you a private address that you can pin in a hosts file and route through a gateway. Virtual network service endpoints restrict which subnets may reach a resource; they do not authorize an on-premises client that arrives over a VPN.

Getting private access means introducing a private endpoint or a private-link design, then adding a private DNS zone so the public name answers with that endpoint instead of the internet. A VPN combined with a service endpoint rule is a different architecture that only looks similar in a diagram. App Service follows the same logic from the other direction: VNet integration lets the app make outbound calls into a VNet, and it does not create an inbound private path from your tunnel. Inbound private access therefore requires a private endpoint, an App Service Environment, or a gateway placed ahead of the app, and which of those you can use depends on the plan.

Check four: products with their own front door

Firebase Hosting cannot be attached to a Cloud VPN, because the hosting tier is a global front end rather than something inside a project VPC. The documented alternative is to build the controlled entry point yourself, with a proxy instance or a load balancer backed by a bucket. Either way the site stops being a pure hosting product and becomes infrastructure you now operate. That trade is worth naming before someone promises the tunnel will cover it.

Private API Gateway sits closer to the VPC-service side: an interface VPC endpoint publishes a hostname whose answers are private addresses, and traffic from your premises arrives over the tunnel or a dedicated interconnect. The endpoint has to be associated with the API, and the certificate plus hostname have to match the custom domain callers use.

Google Cloud VPN tunnels bind to peer IP addresses, not to names. DNS forwarding is configured separately, which is why a tunnel can be perfectly healthy while lookups in the remote private zone still fail.

Then locate the boundary

Run the same connection from a VM inside the VPC. When it succeeds there and fails from the VPN client, the gap sits between the client path and the service endpoint: a route, a security group, an endpoint policy or a name. When both attempts fail, nothing in that network can reach the service, and the VPN was never the obstacle.

getent hosts db.internal.example
nc -vz db.internal.example 5432

Do the name lookup and the port check separately, because they fail for different reasons and the pair tells you which half of the path is broken. A name that resolves to a public address is telling you the private DNS zone is not in play.