0

We are trying to set up an OpenVPN remote access server within a Kubernetes cluster, to replace a service previously hosted on an on-prem firewall.

Our wider network is partly on GCP/GCE, with dynamic BGP routing to our on-prem sites over IPsec.

Currently on the existing OpenVPN server on-prem, the IP addresses allocated to connected clients are routable from the rest of the network, so we can communicate inbound & outbound to them without NAT.

We'd like to move the service to Kubernetes Engine, as that is were all our other Linux workloads are migrating to and we prefer the DevOps style workflow, with it managing availability and recovery.

So, say our OpenVPN container has clients connected on range 10.30.50.0/24, with a Pod IP dynamically allocated in 10.50.30.0/20, how would we tell GCP to route that 10.30.50.0/24 range towards to OpenVPN service in the Pod? And is it even possible?

One thought was to call the GCE APIs on Pod startup to add in a static route directed towards the Pod IP, but I'm unsure if the traffic will transit the cluster and reach OpenVPN in the Pod.

iamacarpet
  • 310
  • 2
  • 12

1 Answers1

1

There is not possible to create a route in GCP to route the subnet 10.30.50.0/24 from the secondary IP range 10.30.0.0/20 to use the OpenVPN. So there are 2 possible solutions to achieve what you want:

1.- You can create a VM instance in GCP to setup your OpenVPN tunnel. Then you can add an static route in GCP with nexthop this VM instance. The GKE cluster within the same VPC network as OpenVPN instance will use it as nexthop so all the traffic from Nodes will use the OpenVPN tunnel. If you don't want to redirect all the traffic from all the node in the cluster through the VPN instance, you can specify a tag and attach that during cluster or node-pool creation.

  1. You can create a VM instace as the previous example and instead of configuring a default route with next-hop "Open VPN" instance, you will need to configure iptables within the nodes of the GKE cluster. For example configuring an iptable that all the traffic to destination IP address and source IP address 10.30.50.0/24 use the next-hop "IP address of OpenVPN instance".

Remember that with both solution, you must enable Alias IP in each GKE cluster to allow communication from your on-prem to the pods.

  • In the end, we went with the same container we were working on, but using a managed instance group, plus the managed container runtime on GCE where you just specify a Docker image. We did use Alias IPs and you can specify a range you'd like, e.g. "/24", which it'll assign dynamically, which you can then access in startup scripts via the metadata server. – iamacarpet Aug 20 '20 at 12:35