Cloud SQL Private IP Over VPN: The Route Nobody Exports

Plenty of teams believe Cloud SQL private IP only works from inside the VPC, and the belief survives because the failure looks like a database problem. Google documents access from networks connected through Cloud VPN or Cloud Interconnect. What those networks need is not a special database feature but two route exchanges that are easy to leave half configured. The tunnel comes up, the compute instances answer, and the database connection times out, which is exactly the combination that sends people to the wrong console.

Myth: private IP means private to the VPC

Private services access is a VPC peering between your network and a producer network owned by Google. The allocated range for the service lives on the producer side, and the instance address is inside it. That peering is why a database in your project can sit on an address your VPC routes to without any explicit subnet of yours containing it.

Because it is a peering, it also has peering behaviour, including the part where custom routes do not automatically cross.

Myth: a working tunnel carries the database route with it

Two ranges have to survive the trip. The first is the client prefix: your on-premises network must be known to the Cloud Router with specific prefixes, because a default route cannot supply the import the producer network needs for the return path. The second is the allocated service range, which the external side has to learn so its packets for the database have somewhere to go. They are different routes maintained at different boundaries, and fixing one leaves the other broken.

On the Google side, that means enabling Export custom routes on the relevant peering connections and adding the allocated service range to the Cloud Router's advertised routes for the tunnel.

Retain the advertisements that are already there. Adding the service range should not remove the VPC routes the same BGP session is carrying for other traffic, and an advertisement set replaced wholesale is a second outage hiding behind the first. Check the effective routes on the external device as well, because being able to reach the VPN gateway or another subnet only proves transport.

Myth: the Cloud SQL Auth Proxy solves the network

The Auth Proxy provides supported authentication and encrypted transport between your application and the instance. It does not create a route. A proxy started on a host with no path to the private network will fail exactly like a direct connection would, and its logs will be less helpful about why. Moving the proxy to a host that does have connectivity changes which leg of the path has to work, and that is a real design decision rather than a workaround.

What it does not do is let a disconnected laptop reach a private-only instance.

Myth: Private Service Connect follows the same rules

Private Service Connect uses an endpoint in your own subnet and a DNS arrangement you control, so the route to it is an ordinary route to an address you own. Peering export settings do not apply to that design, and copying peering changes into a PSC deployment adds risk without adding reachability.

Both give you a private address; the resemblance stops there.

Test the path in the right order

From the external client, test the database TCP endpoint first. A completed TCP handshake means routing, firewall and listener are all in place, and the next test is a permitted authenticated operation. An authentication rejection is actually good news at that point, because it proves a database listener answered. An ICMP timeout says almost nothing about database access, since plenty of paths drop it while forwarding TCP happily.

If your client ranges are outside RFC 1918, review the additional route-export and network-authorization requirements before concluding that the design is unsupported.

Record four objects with the connection: the external prefix, the allocated service range, the peering connections involved, and the router doing the advertising. Those four explain the entire private path, and they replace the folklore that Cloud SQL either always needs a proxy or cannot be reached over a VPN at all.