0

Please bear with me as my background is development and not sysadmin. Networking is something I'm learning as I go and thus why I'm writing here :)

A couple of months ago I started the process of designing the network structure of our cloud. After a couple of exchange here, I settled for having a project that will host a VPN Tunnel to the on-premise resources and some other projects that will host our products once they are moved from the on-premises servers.

All is good and I managed to set things up.

Now, one of the projects is dedicated to "storage": that means, for us, databases, buckets for statis data to be accessed around , etc.

I created a first mySQL database (2nd gen) to start testing and noticed that the only option available to access the SQL databases from Internal IPs was with the "parent project" subnetwork.

I realised that SQL Engine create a subnetwork dedicated for just that. It's written in the documentation as well, silly me. No problem, I tear it down, enable Private Service Connection, create an allocated IP range in the VPC management and set it to export routes.

Then I went back to the SQL Engine a created a new database. As expected the new one had the IP assigned to the allocated IP range set up previously.

Now, I expected every peered network to be able to see the SQL subnetwork as well but apparently not. Again, RDFM you silly goose. It was written there as well.

I activated a bronze support subscription with GCP to have some guidance but what I got was a repeated "create a vpn tunnel between the two projects" which left me a little disappointed as the concept of Peered VPC is so good.

But anyway, let's do that then.

I created a tunnel pointing to a gateway on the project that will have K8s clusters and vice-versa. The dashboard tells me that the tunnel are established but apparently there is a problem with the bgp settings because they are hanging on "Waiting for peer" on both side, since forever.

At this point I'm looking for anything related to BGP but all I can find is how it works in theory, what it is used for, which are the ASM numbers reserved etc etc.

I really need someone to point out the obvious and tell me what I fucked up here, so:

This is the VPN tunnel on the projects that hosts the databases: enter image description here

And this is the VPN tunnel on the project where the products will be deployed, that need to access the databases. enter image description here

Any help is greatly appreciated!

Claudio
  • 496
  • 2
  • 9
  • 35
  • What architecture do you want to achieve? resource A -> VPN -> projet B -> Cloud SQL private ip ? You want that the resource A reach Cloud SQL hosted by the project B. Am I right ? – guillaume blaquiere Jan 13 '20 at 15:54
  • yes, @guillaumeblaquiere. We're trying to have the SQL private IP available in Resource A. The SQL Engine is on Resource B. – Claudio Jan 13 '20 at 17:06

3 Answers3

3

Regarding the BGP status "Waiting for peer" in your VPN tunnel, I believe this is due to the configured Cloud Router BGP IP and BGP peer IP. When configuring, the Cloud Router BGP IP address of tunnel1 is going to be the BGP Peer IP address for tunnel2, and the BGP Peer IP address for tunnel1 is going to be the Router BGP IP address of tunnel2.

Referring to your scenario, the IP address for stage-tunnel-to-cerberus should be: Router BGP IP address: 169.254.1.2 and, BGP Peer IP address: 169.254.1.1

This should put your VPN tunnels BGP session status in "BGP established".

Marcel P
  • 101
  • 3
  • Thank you so much. That was the mistake. On cerberus, the ip 169.254.0.1/169.254.0.1 was used already by another tunnel with an on-premise network and not being able to see the configuration on the on-premise I thought that the BGP address were only something for internal routing of the requests. As I said, not networking background (but i'm picking up some books first thing). Thanks again! – Claudio Jan 13 '20 at 21:23
  • Years later but this answer saved me as well in attempting to follow this guide: https://cloud.google.com/network-connectivity/docs/vpn/how-to/creating-ha-vpn2#creating-ha-gw-2-gw-and-tunnel – kspector Dec 02 '22 at 18:22
1

You can't achieve what you want by VPN or by VPC Peering. In fact there is a rule in VPC which avoid peering transitivity described in the restriction part

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.

Now, take what you want to achieve. When you use a Cloud SQL private IP, you create a peering between your VPC and the VPC of the Cloud SQL. And you have another peering (or VPN tunnel) for the SQL engine.

SQL Engine -> Peering -> Project -> Peering -> Cloud SQL

Like this you can't.

But you can use the shared VPC. Create a shared VPC, add your 2 projects in it, create a common subnet for SQL Engine and the Cloud SQL peering. That should work.

But, be careful. All VPC features aren't available with shared VPC. For example, serverless VPC connector aren't yet compliant with it.

Hope this help!

guillaume blaquiere
  • 66,369
  • 2
  • 47
  • 76
  • Thank you Guillaume, this seems the most streamlined solution. I've accepted @marcelp answer as it's more pertinent to my question but I'll keep the Shared VPN option in mind and experiment with it! – Claudio Jan 13 '20 at 21:36
  • 1
    No problem, I answered to your global goal. I'm also not a network admin and I don't like network issues! And I wanted to prevent you to spend too much time in useless solution! – guillaume blaquiere Jan 14 '20 at 05:36
  • Despite asking the google support (100£ x month) and following their suggestion to create a VPN (hence this question) apparently you were right as the VPN tunnel doesn't allow me to access the SQL Engine subnetwork anyway. So much for paid support. I'm going to explore the Shared VPC solution you suggested. – Claudio Jan 14 '20 at 16:02
0

The original setup in the OP question should work, i.e.

Network 1 <--- (VPN) ---> Network 2 <--- (Peered) ---> CloudSQL network

(the network and the peering is created by GCP)

Then resource in Network 1 is able to access a MySQL instance created in the CloudSQLz network.

Nazir
  • 1,945
  • 24
  • 27
KenLy.LDK
  • 1