Home / server / Questions / 850822
In Process
Eric J.
Asked: 2017-05-18 19:21:45 +0800 CST

Timeout with OpenVPN

  • 772

I set up OpenVPN using these instructions with the goal of connecting to the outside world using an AWS IP address rather than my ISP assigned IP.

The connection succeeds. When I ping (from the client) for example google.com while connected to the VPN I get

Pinging google.com [172.217.9.174] with 32 bytes of data:
Reply from 172.217.9.174: bytes=32 time=122ms TTL=45
Reply from 172.217.9.174: bytes=32 time=262ms TTL=45
Reply from 172.217.9.174: bytes=32 time=119ms TTL=45
Reply from 172.217.9.174: bytes=32 time=121ms TTL=45

compared to the somewhat faster pings when not using the VPN connection

Pinging google.com [172.217.6.174] with 32 bytes of data:
Reply from 172.217.6.174: bytes=32 time=84ms TTL=52
Reply from 172.217.6.174: bytes=32 time=85ms TTL=52
Reply from 172.217.6.174: bytes=32 time=89ms TTL=52
Reply from 172.217.6.174: bytes=32 time=82ms TTL=52

However, when I attempt to load a website (e.g. cnn.com) in a browser on the client, the load almost always times out.

I tried adding

sndbuf 0
rcvbuf 0

to the OpenVPN configuration on both client and server, same result.

The client is Windows 10 and the server Ubuntu 16.04 running on an AWS Nano instance. top does not show any significant load on the server during a connection attempt.

The client's connection is 300 Mbps down / 30 Mbps up.

What else can I try to achieve usable speeds over OpenVPN?

openvpn

1 Answers

  1. I cannot comment due to my current lack of reputation.

    First, what availability zone did you setup your EC2 instance on in AWS? I'm assuming one closest to you? Are you running a VPC in AWS? Both of these introduce many other variables that could contribute to poor network performance.

    My suspicion would be that the t2.nano is not beefy enough for an OpenVPN setup. The instructions you followed specifically say use a t2.micro. It has been my experience that t2.nano has ridiculously poor network performance, though t2.micro isn't that much better.

    Thus, my suggested resolution would be to up the instance to a t2.micro, or even a t2.medium (temporarily) to rule out network performance in AWS land.

    Here is further reading about EC2 network performance

    Here is further reading about EC2 vCPU/memory performance

    Given that the above does not resolve the issue, my next suspicion would be a possible issue with split tunneling. Is your client forcing all traffic out through your tunnel? You can check this either by issuing either route PRINT or tracert google.com. If using the route option then you should see all traffic being directed to the tunnel. If using tracert option then you should see your second or third hop running through your VPN.

    Given that one of the two options above show traffic routing through the VPN then you know split tunneling is disabled. That does not, however, mean DNS is going to work as expected. Try executing nslookup google.com 8.8.8.8. This forces Google's public DNS servers (8.8.8.8) do do the domain name resolution instead of your local network, or DNS inside AWS. Now issue nslookup google.com 192.168.1.1, replacing 192.168.1.1 with the IP address of your local gateway (usually your router). If this works then the last option is to SSH into the EC2 instance and issue just nslookup google.com.

    If, after performing all of the above, you still experience this issue, please respond back with any further findings you have made while performing the above steps.

    • 1