OpenVPN on Google Compute Engine – what route am I missing

google-cloud-platform

I have installed OpenVPN on other VPS providers, and wanted to try out Google's. I like Googles price/performance, and especially because I can spin up the machines from my phone without logging in every time.

I've got it to the point where the client connects but can't get out to the internet.

I have opened up the firewall to the OpenVPN port.
I have enable IP forwarding on the virtual machine.
The client gets an IP, Gateway, DNS – all the right stuff – when connected.

I suspect I have to build a router and/or a route in order for the packets to get from the OpenVPN instance to the world. I have read the documentation very well, but I'm stuck – I'm not a network guru yet, still learning as I go.
Through reading it looks like I can transform the network into what they call the "legacy" structure, but I'd like to be able to overcome this challenge and understand what's going on. I think it's because the network is broken into many different subnets; compared to just 1 network behind the firewall (ie Legacy).

Looking at a map in my mind, my OpenVPN is sending the data to it's subnet's Gateway, but from there I think the packets get dropped. I must need a route from the subnet gateway to the internet? Or even a full router between subnet and internet?

Like I said, I've used OpenVPN Virtual machines before, no problem. So I'm very confident that the issue lies within configuring the Google Cloud network.

Thanks for any tips.

Best Answer

This fixed it:

iptables -t nat -I POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

Still not sure why I had to do it, maybe Google's Debian image is more locked-down than the standard Diebian instance.

No other Google Cloud network changes were needed.

Related Solutions

OpenVPN – Setup VPN Server on Google Compute Engine

You can solve the issue of not being able to browse the web through the VPN despite being able to ping, traceroute... by one of the two following ways:

First, you can use TCP protocol instead of UDP, by changing 'proto udp' to 'proto tcp' in both client and server conf files.

Second, you can use tap device instead of tun, by changing 'dev tun' to 'dev tap' in both client and server conf files.

Not sure what the issue is though, it seems it's a problem from Google's end.

Route Google Cloud VPN traffic in a VPC to public internet or internal IPs

After some contact with Google support, they provided me with a working solution. It is in fact not possible using only Google Cloud native tools, but one can make it work.

So the first part is the connection to the internet through the VPN-tunnel:

One needs to set up a custom NAT-Gateway in the project responsible for internet traffic. Instructions on this are provided by Google here, it can even be HA and there is a terraform module and lots of examples provided.

After doing that you need to add some routes:

Add a routes that send all traffic designated at 0.0.0.0/0 to the NAT-gateway VM(s)
Add a LOWER priority route that applies only to the NAT-gateway VM (use instance tags) and make the next hop the default Internet gateway.

If you are advertising 0.0.0.0/0 to the on-premise network, it will now send all traffic through your cloud network to the internet. I want to mention here, that it is not possible anymore to connect to the on-premise network directly, as it uses the NAT-gateway for all traffic (can be bypassed by adding a route to the on-premise network that targets the originating IP).

The second part of this is redirecting traffic that is designated for an external ip to an internal IP (e.g. the kubernetes cluster in my question above):

First of all you need to add an internal load balancer to your cluster.

As all traffic is routed through the NAT-gateway VMs, you can add PREROUTING rule to the iptable manually on the VMs:

sudo iptables -t nat -A PREROUTING -d $EXTERNAL_LOAD_BALANCER_IP -j DNAT --to-destination $INTERNAL_LOAD_BALANCER_IP

If you set $ORIGINAL_DESTINATION to your clusters external load balancer IP and $INTERNAL_LOAD_BALANCER_IP to your internal load balancer ip, all traffic that should target the external load balancer will now land at your internal load balancer. This also means there is no need to add a custom DNS.

Related Topic