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
You have an interesting scenario. I will cover five methods of supporting the routing of two networks with another network in between.
You asked two questions:
Is there any way to set this up such that:
1) All traffic to 200.0.0.0/24 from VPC 1 is routed via the internal
NIC on the VPN host.
2) All traffic to 200.0.0.0/24 from VPC 2 is routed via the internal
NIC on the 10.0.0.6 host, so that it can be NAT'd ?
1) For Q1, is your VPN host a router that supports adding route entries? If so, then maybe (see the bottom comments on METHOD 3). If no, then review METHOD 3 or METHOD 4.
2) For Q2, look at METHOD 4 to configure a proxy server on that instance. However, don't use that instance for anything else, just proxy serving. The size and type will depend on how much traffic you need to route.
However, if your vendor will only allow source addresses from 10.0.0.0/28 then METHOD 4 (proxy server) is probably the only solution.
Now for the various methods. Not all are acceptable based upon your requirements. I am listing all of them just in case you can modify your environment.
METHOD 1:
The simplest solution is to have your vendor allow a VPN from VPC 1 to their data center and allow 172.200.0.0/24. You could shrink this to /28 by creating a subnet 172.200.X.0/28 (which only allows for 11 hosts)
METHOD 2:
Move your resources from VPC 1 to VPC 2. Same subnet limitations apply.
METHOD 3:
In VPC 2 you need to configure an instance running routing software (R1). This instance needs addresses within the /28 subnet. Then from VPC 1 you create an entry in the route table for traffic going to 200.0.0/24 send it to R1. A similar entry needs to go in the vendors route table to send traffic for 172.20.0.0/16 to R1. Both networks (VPC 1 and vendor) will need routes for 10.0.0.0/28. You might be able to configure the routing on your IPsec VPN Host (is this an instance running VPN software or VGW?). Note: Your vendor will have to allow your 172.20.0.0/16 addresses (or a subnet) into their network as this will be the source IP address and not the 10.x.x.x.
METHOD 4:
Setup a Proxy Server in VPC 2 and route traffic to the proxy server. This means the traffic originates in one direction VPC 1 -> Vendor (or the reverse setup). The vendor will not be able to originate traffic to VPC 1. You could do port mapping on the proxy server to support Vendor -> VPC 1. However, with port mapping you will not be able to map all ports for all addresses (just the ones that that you configure).
[EDIT with METHOD 5]
If the VPN Host in VPC2 is a AWS virtual gateway (VGW), then you can setup a route to VPC 1 (more than one VPC can use the same VGW). This may be the simplest solution.
Best Answer
After much digging it appears there is no way to do this at present. As mentioned, VPC peering does not work. As well, App Engine environments cannot used Shared VPC at this time, though apparently that feature is coming which should allow shared VPNs. In the meantime, it looks like every individual project must have its own VPN.