0

Sorry, the title isn't great...

I have a Google Cloud (GC) VPC subnet 10.1.1.0/24 in region A which has an OpenVPN Access Server at 10.1.1.2. The OpenVpn Access Server provides remote access for clients outside of the cloud. Clients are allocated an IP from the 192.168.3.0/24 subnet, and the routing method can be either NAT or routing (Open VPN Access Server settings).

I have a GC VPN gateway (classic) in region B, and another GC VPN gateway (classic) in region C.

The tunnels from remote sites to the GC VPN gateways are "dictated" by the remote site, i.e., the routing method is policy based, and the remote site decides what the cloud (local) subnet must be. So:

Policy for tunnel from remote site B to GC VPN gateway B is 10.2.2.0/24 (remote) <-> 172.18.22.0/24

Policy for tunnel from remote side C to GC VPN gateway C is 10.3.3.0/24 (remote) <-> 172.18.23.0/24

Hence, for traffic to travel to remote site B / site C, a requirement would be that it has a source inside 172.18.22.0/24 / 172.18.23.0/24 respectively.

So, the question is, what is the best way for a remote client to access remote networks B and C? I've considered introducing instances in subnets B and C which run OpenVPN clients, which could provide access to the remote networks via NAT... but I also need the remote network to be able to reach subnet A. I've considered placing A, B and C in different VPCs, such that the the OpenVPN Access Server could have network interfaces to each VPC, and route traffic by NAT. This has some scale issues... instances are limited to 8 interfaces. Also, I'd have to have 1 GC VPN GW per subnet / tunnel. I'm sure there are other issues that I haven't considered. All a bit of a mess to be honest. Unfortunately, I can not request a different routing method from the remote sites (B and C), and I also cannot request specific subnets for the cloud end of the policy based tunnel.

Any help would be greatly appreciated!

1 Answer 1

0

Issue being described does not give clarity on the type of connections being attempted or the sources, destinations & directions of traffic required, which leads me to assume the below scenarios -

Scenario 1:
(i) Mentioned GCP subnets are in the same VPC and connections attempted from remote clients & remote sites.
(ii) Remote clients connecting to Subnet A via OpenVPN connect.
(iii) Remote sites B and C connecting to Subnets B & C respectively.
(iv) Remote clients attempting to connect to Subnets B & C.

In this case, you have to make sure that a firewall rule to allow traffic within the network is present with following configuration -

Direction - Ingress
Action on match - Allow
IP ranges - [IP range of your GCP VPC]
Protocol and ports - tcp:0-65535 Udp:0-65535 Icmp
Priority - 65534
Enforcement - Enabled

This firewall rule would enable flow of traffic among your subnets within your VPC, irrespective of regions, which would facilitate your set up where your remote clients can reach subnet B or subnet C via subnet A and your remote on-prem site could reach subnet A via subnet B or subnet C.

Scenario 2:
(i) Mentioned GCP subnets are in the same different VPCs and connections attempted from remote clients & remote sites.
(ii) Remote clients connecting to Subnet A via OpenVPN connect.
(iii) Remote sites B and C connecting to Subnets B & C respectively.
(iv) Remote clients attempting to connect to Subnets B & C.

In this case, first you will need to get your VPCs connected using any of the following GCP services -

VPC Peering - VPC Network Peering enables you to connect VPC networks so that workloads in different VPC networks can communicate internally. Refer here for instructions to create VPC peering - https://cloud.google.com/vpc/docs/using-vpc-peering

Cloud VPN - Although primarily used to connect on-premises networks with GCP VPCs, cloud VPN can also be used to connect different GCP VPCs with each other. Refer here for instructions to establish VPN connections between GCP VPCs - https://cloud.google.com/network-connectivity/docs/vpn/how-to/creating-ha-vpn2

With the VPCs connected, your remote clients can reach subnet B or subnet C via subnet A and your remote on-prem site could reach subnet A via subnet B or subnet C.

Please see if either of these scenarios meet the requirement you are working with and if the remediation suits your need. If not provide details on any missing elements.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .