Currently, there’s a GCP VPC Peering restriction for “transitive peering”
Only directly peered networks can communicate. Transitive peering is not supported. In other words, if VPC network N1 is peered with N2 and N3, but N2 and N3 are not directly connected, VPC network N2 cannot communicate with VPC network N3 over VPC Network Peering.
When you use a GCP Cloud SQL instance with a private IP, it will automatically create a VPC peering with a different GCP project and yours, this will happen for “Project A” and the moment you peer with “Project B”, then you will fall onto this transitive peering limitation.
Here are a couple solutions in order to work around this:
- Use a Shared VPC in order to have a virtual machine in project b but with a project a network. (limitation, both projects must be on the same organization)
- Replace the VPC peering between project A and B, with Cloud VPN (I would recommend setting up a Dynamic (BGP) one HA/Classic). (limitation, you will be charged with “egress traffic” on each side)
- Create a virtual machine that can be used as a bridge between them, I tested this before with the following iptables and ip forward enabled:
iptables -t nat -A POSTROUTING -s <source-ip-range> -o <network-interface> -j MASQUERADE iptables -t nat -A PREROUTING -i <network-interface> -p tcp --dport <cloud-sql-port> -j DNAT --to <cloud-sql-ip> iptables -A FORWARD -p tcp -d <cloud-sql-ip> --dport <cloud-sql-port> -j ACCEPT
(limitation, depending on what type of VM you choose, you could be limited in bandwidth)
CLICK HERE to find out more related problems solutions.