0

we are dividing our Google Cloud infrastructure into multiple projects, each with it's own VPC. We have one central VPC, let's call it vpcA, to which we connect via pritunl VPN and site-to-site tunnel from the outside.

We've also connected vpcA to multiple different other projects B with vpcB and C with vpcC using VPC peering. This works great in that everything can see the contents of vpcA, and vpcA can see the contents of vpcB and vpcC. Everything has unique 10.0.0.0 IPs. Each vpc has it's own unique CIDR range (eg. 10.96.0.0/16 for vpcA, 10.97.0.0/16 for vpcB, etc). All subnets are located in the same region.

Our problem now is that vpcB can not see anything in vpcC. The VPC peering only routes between the local vpc networks, and not the peered networks of that vpc (eg. from vpcB to vpcA only the 10.96.0.0/16 range is routed). There seems to be no way to modify this to route all other traffic as well.

While we can directly interconnect vpcB and vpcC using a separate peering, that quickly becomes complex as the number of vpcs increases. Also, and this is really the breaker right now, when we connect our on-premise infrastructure with vpcA using a Google Cloud VPN Gateway/Tunnel, it also only sees vpcA's content. Creating a direct VPN Tunnel to every single of our VPCs would create a lot of overhead, and a lot of additional cost (with 10 VPCs that would be $360/month without any traffic, just to peer).

Now, the question is, are we missing anything? Is there some way to create a partially connected mesh topology with VPCs on Google Cloud?

Thanks, Volker

Volker Schönefeld
  • 3
  • 1
  • 2

2 Answers2

2

According to the GCP documentation, it is not possible for vpcB and vpcC to communicate:

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 also directly connected, VPC network N2 cannot communicate with VPC network N3 over the peering.

Also, VPN connections are not exported to peered VPCs:

The following types of endpoints/resources are NOT propagated to directly peered networks: Static routes, VPNs

Cedric Meury
  • 138
  • 7
0

When you use VPC peering, GCP will create routes in each VPC to link them. Since VPCb and VPCc are not peered, there are no routes between them so it won't work.

There are a couple of workarounds:

  1. Manually create routes to send traffic from VPCb destined for VPCc to VPCa and vice versa (there is still a limit on the number of routes you can have)

  2. use a single Shared VPC instead of multiple separate VPCs that are being peered. Shared VPCs will scale better than multiple peered VPCs

Concerning the Cloud VPNs, make sure your network is configured to use Global routing mode so that the VPN can communicate with every zone and subnet globally. Again, using a Shared VPC will mean a single VPN gateway

EDIT

Things have changed over the years. Transitive peering still does not work so a full network mesh would be the way forward. Keep in mind, there are limits to how many network peering you can configure in a project which will limit the peering, and thus the number of VPCs you can use.

As for the routing, this will only work if there is a router that can be routed to in the "hub" VPC. Deploying something like nginx, HA proxy, or a 128T can handle proper routing through all the peers.

Patrick W
  • 582
  • 2
  • 8
  • Thanks for the reply, Patrick! Regarding 1, I wasn't able to figure out how to set up routes manually, as I can't specify next hops that are outside of the local VPC itself, and I can't tell it to route traffic through a VPC peering tunnel. We've tried 2, and it might be the best solution here, but the problem is that it makes the firewall set up a lot more complex. Tags aren't supported across shared VPCs (yet), and we also can't target a subnet. We might have to look into using service accounts to drive the targeting for this. – Volker Schönefeld Jun 21 '18 at 09:13
  • if it weren't for overhead, peering would probably be a good option for you. Including full mesh topology would be a good idea, worth submitting as a feature request – Patrick W Jun 21 '18 at 18:30
  • The issue might get settled down by this time but I want to add security advice for future readers: As per google security best practices, always use service accounts instead of tags for firewall rules. – khichar.anil Jun 14 '19 at 11:49