2

I have Ubuntu 18.04 running on a Compute Engine on the Google Cloud Platform. I setup a VPN on 1194/UDP using Nyr's awesome script (I also tried on 443/TCP). The VPN connects however I am unable to access the internet when connected.

greg@vpn:~$ sudo iptables -L -t nat
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
SNAT       all  --  10.8.0.0/24         !10.8.0.0/24          to:104.154.-.- #removed

traceroute on the VPN

greg@vpn:~$ traceroute 1.1.1.1
traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets
 1  209.85.241.122 (209.85.241.122)  10.729 ms 216.239.63.174 (216.239.63.174)  9.965 ms 209.85.241.122 (209.85.241.122)  10.771 ms
 2  108.170.243.187 (108.170.243.187)  10.086 ms 108.170.243.196 (108.170.243.196)  10.330 ms  10.285 ms
 3  141.101.73.2 (141.101.73.2)  10.867 ms  10.860 ms  11.104 ms
 4  one.one.one.one (1.1.1.1)  10.753 ms  9.886 ms  9.930 ms

local traceroute when connected to VPN

 greg ~ $traceroute 1.1.1.1
traceroute to 1.1.1.1 (1.1.1.1), 64 hops max, 52 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
...

There is an issue on Nyr's repo which suggests it's a networking config problem. My question is, how do I trouble shoot this? And can this be a firewall / GCP config problem if the VPN server has access to the Internet?

/etc/openvpn/server.conf

port 1194
proto udp
dev tun
sndbuf 0
rcvbuf 0
ca ca.crt
cert server.crt
key server.key
dh dh.pem
auth SHA512
tls-auth ta.key 0
topology subnet
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 1.1.1.1"
keepalive 10 120
cipher AES-256-CBC
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
verb 3
crl-verify crl.pem

I've ensured the iptables are correct

greg@vpn:~$ iptables -t nat -A POSTROUTING -s 10.8.0.0/16 -o ens4 -j SNAT --to 104.154.x.x

Here is my ip route show

greg@vpn:~$ ip route show
default via 10.128.0.1 dev ens4 proto dhcp metric 100 
10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.1 
10.128.0.1 dev ens4 proto dhcp scope link metric 100

Subnets

greg@vpn:~$ netstat -r
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
default         _gateway        0.0.0.0         UG        0 0          0 ens4
10.8.0.0        0.0.0.0         255.255.255.0   U         0 0          0 tun0
_gateway        0.0.0.0         255.255.255.255 UH        0 0          0 ens4

I've also enabled net.ipv4.tcp_syncookies=1 in /etc/sysctl.conf

Firewall rules 3

Firewall rules 6

Routes

Network interface details

My traceroute from local when connected to VPN

greg ~ $sudo mtr 1.1.1.1
                                                 My traceroute  [vUNKNOWN]
Gregs-MacBook-Pro.local (10.8.0.2)                                                                2019-03-14T13:57:40-0400
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                                                                  Packets               Pings
 Host                                                                           Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 10.8.0.1                                                                     0.0%    24   35.3  36.5  34.3  48.2   3.8
 2. ???

My traceroute directly from VPN server

greg@vpn:~$ mtr 1.1.1.1
                                                     My traceroute  [v0.92]
vpn (10.128.0.28)                                                                                  2019-03-14T18:11:28+0000
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                  Packets               Pings
Host                                                                            Loss%   Snt   Last   Avg  Best  Wrst StDev
1. 216.239.40.188                                                                0.0%   177   10.1  11.3  10.0  33.7   3.8
2. 108.170.243.196                                                               0.0%   177   10.5  10.6  10.4  13.9   0.5
3. 141.101.73.2                                                                  0.0%   177   10.8  14.2  10.7  52.4   7.1
4. one.one.one.one                                                               0.0%   176   11.1  11.1  10.9  12.6   0.2
7
  • You are not allowing http traffic...maybe web sites will not work even if you allow https.
    – Overmind
    Mar 12, 2019 at 7:25
  • @Overmind, enabling http traffic didn't help. The only reason I'm enabling https traffic is because that's 443/TCP and I was testing other protocols and ports to see if that would fix it. Thanks for the suggestion though
    – Gregology
    Mar 12, 2019 at 21:02
  • In that case you should alter the metrics a little. Set different metrics for all routes to see if it makes a difference. For 10.8.0.0/24 put a different metric like 99 or 101 and see what is the difference in both cases.
    – Overmind
    Mar 13, 2019 at 6:20
  • Thanks again @Overmind, I tried setting and adjusting the metric for 10.8.0.0/24 but the issue persisted. Any other thoughts or ideas? I've added some more firewall details in the question
    – Gregology
    Mar 14, 2019 at 17:27
  • suggestions: add local/remote ips (obfuscate if you want, but do it everywhere then), add openvpn configuration (client/server) looks like a routing issue, so troubleshooting could be like this: tracepath/mtr/ping, disable firewall, adapt routes, work until you reach your last hop. you can set manual routes, and i would suggest reading the openvpn howto instead of trusting some semi-random file on the internet to not break your server. wget ..|bash is imho bad design unless you control both and make it via secure line. Mar 14, 2019 at 17:41

2 Answers 2

2
+50

Have you enabled IP Forwarding ?

You can do it either on the instance details page in GCP or directly in sysctl.conf : net.ipv4.ip_forward=1

Also I used this great tutorial once to setup OpenVPN on Ubuntu 16 and it worked flawlessly, I'm sure it will be of great help.

For the internet access troubleshooting, it would be good to post your GCP routing table and firewall rules

3
  • 1
    Thanks for your help @Notauser . That tutorial is great. I have used it in the past with no problems on both Linode & Digital Oceans. Which makes me think it's either an issue with the GCP Ubuntu image or some GCP routing issue. I have included all the firewall rules (I also added an egress rule which I don't think makes sense but I'm trying everything now 😃) and included the subnet details from the server. Any more troubleshooting ideas would be greatly appreciated
    – Gregology
    Mar 14, 2019 at 17:26
  • Couple observations - Your Iptables postrouting statement uses 10.8.0.0/16 while OpenVPN defines it as /24. Additionally, I believe you need to map it to 10.128.0.1 instead of 104.154.x.x - I believe that you also need a firewall rule and route in gcp allowing 10.8.0.0/24 to talk to 10.128.0.0/20. Let me know if it helps.
    – Notauser
    Mar 14, 2019 at 17:58
  • 1
    You got it! I was using the external IP address but routing for the external IP address happens outside of the server. Basically I needed to use the private IP address. I was confused because the VPN was connecting, it was then routing traffic to an ip address it didn't have access to. Thanks for your help!
    – Gregology
    Mar 14, 2019 at 19:08
1

I would suggest trying followings:

1) Using TCP protocol instead of UDP; this can be done by changing 'proto udp' to 'proto tcp' in both client and server conf files.

port 443

proto tcp

;proto udp

2) Using tap device instead of the tun, by changing 'dev tun' to 'dev tap' in both client and server conf files. A TAP device is a virtual ethernet adapter, while a TUN device is a virtual point-to-point IP link. You would have to use one or the other cannot be mixed.

1
  • thanks for the suggestions. I had already tried TCP/443 instead of UDP/1194. The VPN connected and I had access to the VPS but no internet access. I tried your suggestion of using tap instead of tun but it raised more issues because I'll need to setup a DHCP server on GCP. Ideally we'd use tun
    – Gregology
    Mar 13, 2019 at 18:37

You must log in to answer this question.

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