New Cloud SQL instances in new projects use Private Service Connect and come back without ipAddresses. Why the Auth Proxy on a laptop times out, and two bastion routes over IAP.
Since 13 October 2026, a Cloud SQL instance created in a new project gets Private Service Connect as its private connectivity unless you choose private services access or both. Ask the Admin API about such an instance and the response has no ipAddresses field. It has a dnsName that ends in a dot and a pscServiceAttachmentLink, and nothing you could hand to psql.
Two days after the change I created a throwaway PSC instance in a demo project to see what my own app would do with it. Its Cloud SQL table showed a dash in the Private IP column, and Open Tunnel did nothing.
An instance on the older private services access setup does show an address, something like 10.50.0.7, and a laptop can't reach that one either. Both kinds need a machine inside Google's network that can reach the database, and with IAP that machine doesn't need an external IP.
Why the Cloud SQL Auth Proxy on a laptop times out
With private services access the instance runs in a VPC that Google manages, peered to yours. Your laptop has no route into either. Peering isn’t transitive, so a VM in a second VPC peered to yours can’t get to the database through it.
The proxy’s README says it under –private-ip: "there must be a network path present for this to work." Google's connection page says the proxy "must be on a resource with access to the same VPC network as the instance." Run it on a Mac, or in Cloud Shell, which isn't in your VPC either, and it times out dialing port 3307, the port the proxy connects to on the instance:
dial tcp 10.127.0.4:3307: connect: connection timed out
Start it without –private-ip against an instance that has no public IP and it fails earlier, with Config error: instance does not have IP of type "PUBLIC".
–sql-data is described as "Enable SQL Data to tunnel through the Cloud SQL Admin API without needing network access to your public or private IP". It came with the change titled "Support Developer Edition connections", and the commit message says Developer Edition instances allow connections through the SqlDataService. Nothing I found says it works for other editions, so for a production instance I'd still plan on a network path.
A PSC-only instance needs an endpoint in your VPC
PSC has no peering. The instance publishes a service attachment, and you reach it through an endpoint in your own VPC, which is an internal IP address on a forwarding rule whose target is that service attachment. You reserve the address and create the endpoint yourself, or a service connection policy creates it. Since 27 August the instance creation flow can also create the policy and the endpoint for you, if you ask it to.
The project that holds the endpoint has to be on the instance’s allowlist (pscConfig.allowedConsumerProjects; Google asks for at least one project). An endpoint in a project that isn't on the list stays PENDING.
If someone else set up the instance and you’re looking for its endpoint, start from the instance. Its pscServiceAttachmentLink is what the endpoint's forwarding rule names as target, so look through the forwarding rules in the instance's project and in each allowed consumer project. The two APIs spell the link differently: Cloud SQL returns a relative path starting with projects/, Compute returns a full URL, so a script has to compare from projects/ on. The rule you find gives you two things: the IP to forward to, and the VPC your bastion has to be on.
Google recommends connecting to a PSC instance by its DNS name, and the Auth Proxy requires the DNS name. That means a private DNS record for dnsName on the bastion's VPC. An SSH forward to the endpoint IP works without one.
Route 1: an SSH forward through a bastion over IAP
The IAP hop needs the same things for both routes:
- an ingress firewall rule from 35.235.240.0/20 on tcp:22 (2600:2d00:1:7::/64 for IPv6)
- roles/iap.tunnelResourceAccessor for whoever connects
- SSH access to the VM, through OS Login or a key in metadata
- a VM on the instance’s VPC, or on the VPC that holds the PSC endpoint. It needs no external IP; IAP connects to the primary internal address of nic0.
gcloud compute ssh bastion-01 --tunnel-through-iap \
--zone=europe-west1-b --project=acme-prod \
-- -N -L 5432:10.50.0.7:5432
psql "host=127.0.0.1 port=5432 user=postgres dbname=orders sslmode=require"
For a PSC instance, put the endpoint IP where 10.50.0.7 is. –tunnel-through-iap makes gcloud go through IAP even when the VM has an external IP; without the flag it uses IAP only for a VM that has none.
Nothing here talks to the Cloud SQL API, so you need no Cloud SQL role, and the database checks its own user and password. Keep sslmode=require, or verify-ca with the server CA. verify-full, and VERIFY_IDENTITY on MySQL, fail because the client is connecting to 127.0.0.1.
An instance that enforces the Cloud SQL connectors for every connection refuses this.
Route 2: the Auth Proxy on the bastion, listening on loopback
On the bastion:
./cloud-sql-proxy --private-ip --port 5432 acme-prod:europe-west1:orders-db
# PSC instance:
./cloud-sql-proxy --psc --port 5432 acme-prod:europe-west1:orders-db
From the Mac, forward to the bastion’s own loopback:
gcloud compute ssh bastion-01 --tunnel-through-iap --zone=europe-west1-b \
--project=acme-prod -- -N -L 5432:127.0.0.1:5432
The proxy binds 127.0.0.1 by default. On Stack Overflow the accepted fix for “the proxy on my bastion is unreachable” is –address 0.0.0.0, which opens the database port on the VM's network interface. With the forward pointed at 127.0.0.1 on the bastion, you can leave the default alone.
This route costs more: a binary and a service on the VM, the Cloud SQL Admin API enabled, and roles/cloudsql.client for the identity the proxy runs as, here the bastion's service account. For that you get IAM-authorized TLS to the instance, and it works when the instance enforces connectors. A PSC instance still needs the endpoint and the record on the bastion's VPC.
What I built for this
I manage VMs in more than ten Google Cloud organizations from a Mac, and before I built Ostgate the commands above lived in aliases and scripts. Ostgate does route 1 without gcloud. Open Tunnel on an instance targets its private IP on the engine’s port, offers a running VM on the instance’s VPC as the bastion, and forwards 127.0.0.1 through that VM over one SSH session carried by IAP.
For a PSC instance it runs the search from the endpoint section. In the test run before the release, I created a throwaway PSC instance and it showed “no endpoint”; after I created an endpoint in prod-vpc, the cell showed 10.10.0.12, bastion-01 was preselected, and the server answered an SSLRequest through 127.0.0.1:5432.
With no endpoint, Open Tunnel stays off and names the projects it searched. Ostgate never creates endpoints, addresses or DNS records. It doesn’t speak the Auth Proxy protocol, so an instance that enforces connectors refuses it like any direct connection, and it needs a running VM you can SSH to. The setup and its limits are in the guide: https://ostgate.app/guides/cloud-sql-private-ip-mac
I build Ostgate, a paid macOS app with a 7-day trial. It isn’t affiliated with Google.
Cloud SQL’s new default has no IP address. Reaching it from a Mac through IAP was originally published in Google Cloud – Community on Medium, where people are continuing the conversation by highlighting and responding to this story.
Source Credit: https://medium.com/google-cloud/cloud-sqls-new-default-has-no-ip-address-reaching-it-from-a-mac-through-iap-4b68fd756df9?source=rss—-e52cf94d98af—4
About the Author
