How to make a Google Cloud VM forward Minecraft traffic to an OpenVPN client?

I have an OpenVPN network currently set up in "tap" mode, with the Google VM as the server and a Raspberry Pi 3 client running a Minecraft server.

Users are currently able to connect to the Minecraft server by running an OpenVPN client on their machines and typing the Pi's OpenVPN IP into the Minecraft client (say, 10.8.0.2).

However, I want to be able to let users access the Minecraft server using the Google VM's external IP (without the need to install OpenVPN). Users can't use the Pi's address directly because of ISP double-layer NAT.

I've tried following this answer. Specifically I executed:

iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 25565 -j DNAT --to-destination 10.8.0.2:25565
iptables -A FORWARD -p tcp -d 10.8.0.2 --dport 25565 -j ACCEPT
iptables -A POSTROUTING -t nat -s 10.8.0.2 -o eth0 -j MASQUERADE

VM's interfaces are eth0 and tap0. IP forwarding is enabled in the console.

The server firewall is set to allow traffic from 0.0.0.0/0 TCP:25565 and UDP:25565

However, when trying to connect using the Google VM's external IP, I get "connection timed out". NMAP tells me that port 25565 is "filtered"

Additional info, iptables-save:

# Generated by iptables-save v1.6.0 on Thu Sep 26 11:42:02 2019
*nat
:PREROUTING ACCEPT [106:35257]
:INPUT ACCEPT [75:15902]
:OUTPUT ACCEPT [111:6692]
:POSTROUTING ACCEPT [6:328]
-A PREROUTING -i eth0 -p tcp -m tcp --dport 25565 -j DNAT --to-destination 10.8.0.3:25565
-A PREROUTING -i eth0 -p udp -m udp --dport 25565 -j DNAT --to-destination 10.8.0.3:25565
-A PREROUTING -i eth0 -p tcp -m tcp --dport 25565 -j DNAT --to-destination 10.8.0.3:25565
-A PREROUTING -i eth0 -p udp -m udp --dport 25565 -j DNAT --to-destination 10.8.0.3:25565
-A PREROUTING -d 35.197.47.71/32 -p tcp -m tcp --dport 25565 -j DNAT --to-destination 10.8.0.3:25565
-A PREROUTING -d 35.197.47.71/32 -p udp -m udp --dport 25565 -j DNAT --to-destination 10.8.0.3:25565
-A PREROUTING -i eth0 -p tcp -m tcp --dport 25565 -j DNAT --to-destination 10.8.0.3:25565
-A PREROUTING -i eth0 -p tcp -m tcp --dport 25565 -j DNAT --to-destination 10.8.0.3:25565
-A POSTROUTING -s 10.0.0.0/8 -o eth0 -j MASQUERADE
-A POSTROUTING -s 10.0.0.0/8 -o eth0 -j MASQUERADE
-A POSTROUTING -s 10.8.0.3/32 -o eth0 -j MASQUERADE
-A POSTROUTING -s 10.8.0.2/32 -o eth0 -j MASQUERADE
COMMIT
# Completed on Thu Sep 26 11:42:02 2019
# Generated by iptables-save v1.6.0 on Thu Sep 26 11:42:02 2019
*filter
:INPUT ACCEPT [1822:367429]
:FORWARD ACCEPT [13:700]
:OUTPUT ACCEPT [1610:231716]
-A FORWARD -d 10.8.0.2/32 -p tcp -m tcp --dport 25565 -j ACCEPT
COMMIT
# Completed on Thu Sep 26 11:42:02 2019

--list-rules:

-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-A FORWARD -d 10.8.0.3/32 -p tcp -m tcp --dport 25565 -j ACCEPT

Calvin Ng

Posted 2019-09-26T10:42:24.353

Reputation: 25

I wonder if you need to masquerade for -d 10.8.0.2 -o tap0 as well, depending on the routes and firewall on pi. – Tom Yan – 2019-09-26T11:27:06.127

Btw, why even tap? – Tom Yan – 2019-09-26T11:27:21.077

@TomYan I'm also using the OpenVPN network to play old LAN games with a group of friends which needed a tap interface to properly detect – Calvin Ng – 2019-09-26T11:48:20.697

Answers

I think the problem might be, you are not masquerading the packets that are routed to the pi and not all traffics from the pi are made to be routed into the tunnel.

This means while packets from the outside world can reach the pi but when the pi replies to them, the response packets are not routed to the Google VM first (but are probably directly sent to the clients (as in, via its Internet gateway), which hence won't be recognized by the clients).

Also if the pi has firewall filtering incoming packets from the tunnel (such that only packets from other VPN hosts are accepted), packets that are not masqueraded as from the VM will be filtered.

Therefore, you might need:

iptables -t nat -A POSTROUTING -d 10.8.0.x -o tap0 -j MASQUERADE

Tom Yan

Posted 2019-09-26T10:42:24.353

Reputation: 4 744

this should be executed on the pi, correct? – Calvin Ng – 2019-09-26T11:59:12.543

@Calvin Ng nope, on the Google VM. – Tom Yan – 2019-09-26T11:59:36.630

# iptables -A POSTROUTING -d 10.8.0.3 -o tap0 -j MASQUERADE

iptables: No chain/target/match by that name. – Calvin Ng – 2019-09-26T12:00:12.200

@Calvin Ng oops sorry, I forgot -t nat – Tom Yan – 2019-09-26T12:05:03.657

Very nice! It's working properly. thanks so much. Too bad my reputation is too low for me to give you an upvote. – Calvin Ng – 2019-09-26T12:14:24.400

@Calvin Ng that's okay, glad to have helped :D – Tom Yan – 2019-09-26T12:16:48.500

@Calvin Ng btw, you can limit the masquerading of this rule to only packets going to the tcp port of the minecraft server as well (for the other rule you might be able to limit the source port (not the destination port) to that as well; not entirely sure about it) – Tom Yan – 2019-09-26T12:24:32.073

You can open the port on the google's firewall cloud menú. And, after testing, if it doesn't work I'll say you another option.

Regards

user1094595

Posted 2019-09-26T10:42:24.353

Reputation: 1

Sorry, I forgot to add this info to the question. I already set the firewall to allow traffic. Main question has been updated – Calvin Ng – 2019-09-26T10:53:35.617

@Calvin Ng is that the same firewall that you've been manipulating with iptables though? – Tom Yan – 2019-09-26T11:19:28.887

I did it on the google cloud web interface for firewall. I'm not aware of any other firewall. I don't have ufw, for instance – Calvin Ng – 2019-09-26T11:22:00.277

If the port is open on the firewall and the IP is public you can make a ping onto ip and, if the answer is "echo ok" make after a scanning to the port with a port scanner. If the IP is up and the port open.... well, is problem of the service running on background. A configuration issue. Hope it helps – user1094595 – 2019-09-26T11:26:03.037

Yes, I can ping but port scan says port 25565 is filtered. I was hoping to see what specific configuration is the issue. – Calvin Ng – 2019-09-26T11:30:15.167

Sorry, I readed it but did not remembered in my answer... – user1094595 – 2019-09-26T11:31:38.943

@Calvin Ng you are using iptables, no? Although maybe you are simply copying and pasting the rules while your INPUT and FORWARD chains are ACCEPT by default. – Tom Yan – 2019-09-26T11:32:10.187

@Calvin Ng if you don't mind, perhaps you should provide the output of iptables-save – Tom Yan – 2019-09-26T11:33:06.637

Alright, main post updated. Please forgive the 10.8.0.2 / 10.8.0.3 discrepancy in the post, the body text was supposed to be just an example. Actual IP is 10.8.0.3 – Calvin Ng – 2019-09-26T11:44:34.693

I just noticed that there is a bunch of lines in iptables-save leftover from earlier failed attempts. Would this cause a problem? Would it help to somehow "clean slate"? – Calvin Ng – 2019-09-26T11:47:05.433

1@Calvin Ng well, you can always run iptables-flush anyway... – Tom Yan – 2019-09-26T12:02:22.137

@TomYan Ah, good to know! – Calvin Ng – 2019-09-26T12:03:30.763