[Solved] Locks up when loading webpages (Low bandwidth ?)

Ryeuu

Hey OpenVPN Forums!

Background:
I have been trying to configure an OpenVPN Open Source Server on a VPS to route my game traffic through Singapore. I am able to get it up and running, connect to it and ping the game server to see my latency. The game is Blade and Soul and the servers are located in Taiwan. I am routing the traffic from Perth (Client Location) > Singapore (VPS + VPN Server Location) > Taipei/New Taipei (Game Server Location). I will be having multiple users connecting through the VPN.

Issue:
The issue is that whenever I try to load a webpage, or even send any data through the VPN, the connection 'locks up' or almost 'cuts out'. For example: I'll be pinging the game server and everything will be fine until I try to open my web browser, where I will get "connection timed out" until the webpage loads - which takes anywhere from 1-3 minutes.

Goal:
To be able to use chat programs, load webpages and even stream music without it effecting the connection latency. And, if possible, to find a way to only route my game traffic through the VPN.

Attempted Fixes:
After searching google for a solid two days, I haven't been able to find a solution. I've tried setting sndbuf and rcvbuf to 0 and 393216, changing tun-mtu, setting fragment and mssfix to 0 and 1300, disabling cipher and authentication with 'auth none' and 'cipher none', but nothing seems to fix the issue.

Server Config:

port 11911

proto udp

dev tun

ca ca.crt
cert server.crt
key server.key  

dh dh1024.pem

server 10.0.0.0 255.255.255.0

ifconfig-pool-persist ipp.txt

push "redirect-gateway def1 bypass-dhcp"

push "dhcp-option DNS 208.67.222.222"
push "dhcp-option DNS 208.67.220.220"

keepalive 10 120

max-clients 10

user nobody
group nogroup

persist-key
persist-tun

status openvpn-status.log

verb 3

sndbuf 393216
rcvbuf 393216
push "sndbuf 393216"
push "rcvbuf 393216"

Client Config:

client

dev tun

proto udp

remote (IP here) 11911

resolv-retry infinite

nobind

user nobody
group nogroup

persist-key
persist-tun

ns-cert-type server

verb 3

Extra Information:
I have 100/5 internet and the MTU for my internet is 1492 (PPPOE),
The game I play uses TCP,
The OS for the Server is Ubuntu 14.04.3 x86 (Can be changed),
The OS for the Client(s) is Windows 7-10,
The Server specs are: 512MB RAM, 2.4GHz Core (x1),
If I am able to load speedtest.net, I can get a solid 55ms with around 60Mbps down and 5Mbps up,
I have setup a PPTPD server on this VPS before with no issues at all,
I have attempted to set it up on a 2GB, 2.4GHz Core (x2) with the same config with no success (issue still occurs).

Any help would be greatly appreciated! I'm sorry if I did the formatting wrong - this is my first time posting so please correct me. ^^

Thanks,
Ryan.

Traffic

Ryeuu wroteI have 100/5 internet

If this is your VPN server then 5 is the max you will get. Which is probably not enough ..

Ryeuu

Traffic wrote
Ryeuu wroteI have 100/5 internet
If this is your VPN server then 5 is the max you will get. Which is probably not enough ..

That's my home internet 😛

If I run a speedtest through their server (without VPN) I can get 90/5. That definitely isn't an issue. Even then, I believe 5 would be enough to not have it lock up every time I try to load google or log into steam :/

Traffic

I cannot help with steam but google.com web page ought to load in a second or two max ..

Ryeuu wroteI am routing the traffic from Perth (Client Location) > Singapore (VPS + VPN Server Location) > Taipei/New Taipei (Game Server Location). I will be having multiple users connecting through the VPN.

This is troubling ..

As the server is a VPS you need to use the right iptables rule (Use the correct VPN subnet 10.*):

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -j SNAT --to-source 12.34.56.78   # <-- Use your OpenVPN server's real external IP here

Or maybe:

iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to-source 12.34.56.78   # <-- Use your OpenVPN server's real external IP here .. and choose the correct name for the output interface

Ryeuu

Traffic wroteI cannot help with steam but google.com web page ought to load in a second or two max ..

Ryeuu wroteI am routing the traffic from Perth (Client Location) > Singapore (VPS + VPN Server Location) > Taipei/New Taipei (Game Server Location). I will be having multiple users connecting through the VPN.
This is troubling ..

As the server is a VPS you need to use the right iptables rule (Use the correct VPN subnet 10.*):
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -j SNAT --to-source 12.34.56.78   # <-- Use your OpenVPN server's real external IP here
Or maybe:
iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to-source 12.34.56.78   # <-- Use your OpenVPN server's real external IP here .. and choose the correct name for the output interface

Thanks for replying Traffic! Unfortunately I didn't get an email that you responded.. otherwise I would've been head over heels on it. I'll try that now - although the guide I used to setup OpenVPN is this one (from Digital Ocean, also my VPS provider): https://www.digitalocean.com/community/tutorials/how-to-set-up-an-openvpn-server-on-ubuntu-14-04

It tells me to use UFW, but I can disable it and attempt to put those settings in. It is frustrating as I am able to route internet just fine, but it just takes millions of years to load. Adding that sndbuf and rcvbuf did decrease loading times a fair amount (it would take a whole shower to load a page, but now only takes 1-3 minutes).

I'll try it now and get back to you ASAP! Sorry again for the late response >~<

Ryeuu

Also, I noticed some extra commands in my /etc/sysctl.conf:

# Digital Ocean Recommended Settings
net.core.wmem_max = 12582912
net.core.rmem_max = 12582912
net.ipv4.tcp_rmem = 10240 87380 12582912
net.ipv4.tcp_wmem = 10240 87380 12582912

I believe these are all to do with TCP buffer sizes, from some quick google search. Will these affect my current UDP set up at all?

Ryeuu

Alright, finally managed to finish testing it. I disabled UFW and added these iptable rules in followed by iptables-save. It seems to have made it a lot faster! I can now load pages like google in 15-30 seconds and many other pages under 30 seconds. However it is still cutting out my connection whenever I try to load a webpage. Here is a ping test from CMD (pinging an approximate location of my game server) whilst loading speedtest.net and whilst running it:

C:\Users\Ryan>ping 139.175.50.166 -t

Pinging 139.175.50.166 with 32 bytes of data:
Reply from 139.175.50.166: bytes=32 time=2639ms TTL=55 <Opening Chrome
Request timed out.
Request timed out. < Loading Speedtest.net
Reply from 139.175.50.166: bytes=32 time=2076ms TTL=55
Reply from 139.175.50.166: bytes=32 time=987ms TTL=55
Reply from 139.175.50.166: bytes=32 time=117ms TTL=55
Reply from 139.175.50.166: bytes=32 time=113ms TTL=55
Reply from 139.175.50.166: bytes=32 time=114ms TTL=55
Reply from 139.175.50.166: bytes=32 time=114ms TTL=55
Reply from 139.175.50.166: bytes=32 time=122ms TTL=55
Reply from 139.175.50.166: bytes=32 time=1990ms TTL=55
Reply from 139.175.50.166: bytes=32 time=122ms TTL=55
Reply from 139.175.50.166: bytes=32 time=113ms TTL=55
Request timed out. < Pinging Servers
Reply from 139.175.50.166: bytes=32 time=113ms TTL=55
Reply from 139.175.50.166: bytes=32 time=114ms TTL=55
Reply from 139.175.50.166: bytes=32 time=114ms TTL=55
Reply from 139.175.50.166: bytes=32 time=113ms TTL=55
Reply from 139.175.50.166: bytes=32 time=114ms TTL=55
Reply from 139.175.50.166: bytes=32 time=115ms TTL=55
Reply from 139.175.50.166: bytes=32 time=115ms TTL=55
Reply from 139.175.50.166: bytes=32 time=114ms TTL=55
Reply from 139.175.50.166: bytes=32 time=113ms TTL=55
Reply from 139.175.50.166: bytes=32 time=113ms TTL=55
Reply from 139.175.50.166: bytes=32 time=114ms TTL=55
Reply from 139.175.50.166: bytes=32 time=113ms TTL=55
Reply from 139.175.50.166: bytes=32 time=117ms TTL=55
Reply from 139.175.50.166: bytes=32 time=128ms TTL=55 < Begin Download
Reply from 139.175.50.166: bytes=32 time=114ms TTL=55
Reply from 139.175.50.166: bytes=32 time=112ms TTL=55
Reply from 139.175.50.166: bytes=32 time=130ms TTL=55
Reply from 139.175.50.166: bytes=32 time=138ms TTL=55
Reply from 139.175.50.166: bytes=32 time=129ms TTL=55
Reply from 139.175.50.166: bytes=32 time=118ms TTL=55
Reply from 139.175.50.166: bytes=32 time=122ms TTL=55
Reply from 139.175.50.166: bytes=32 time=123ms TTL=55
Reply from 139.175.50.166: bytes=32 time=120ms TTL=55
Reply from 139.175.50.166: bytes=32 time=122ms TTL=55
Reply from 139.175.50.166: bytes=32 time=116ms TTL=55
Reply from 139.175.50.166: bytes=32 time=123ms TTL=55
Reply from 139.175.50.166: bytes=32 time=131ms TTL=55
Reply from 139.175.50.166: bytes=32 time=113ms TTL=55
Reply from 139.175.50.166: bytes=32 time=116ms TTL=55
Reply from 139.175.50.166: bytes=32 time=114ms TTL=55
Reply from 139.175.50.166: bytes=32 time=114ms TTL=55
Reply from 139.175.50.166: bytes=32 time=114ms TTL=55
Reply from 139.175.50.166: bytes=32 time=113ms TTL=55
Reply from 139.175.50.166: bytes=32 time=113ms TTL=55
Reply from 139.175.50.166: bytes=32 time=113ms TTL=55
Reply from 139.175.50.166: bytes=32 time=114ms TTL=55
Reply from 139.175.50.166: bytes=32 time=255ms TTL=55 < Begin Upload
Reply from 139.175.50.166: bytes=32 time=276ms TTL=55
Reply from 139.175.50.166: bytes=32 time=285ms TTL=55
Reply from 139.175.50.166: bytes=32 time=312ms TTL=55
Reply from 139.175.50.166: bytes=32 time=323ms TTL=55
Reply from 139.175.50.166: bytes=32 time=292ms TTL=55
Reply from 139.175.50.166: bytes=32 time=319ms TTL=55
Reply from 139.175.50.166: bytes=32 time=352ms TTL=55
Reply from 139.175.50.166: bytes=32 time=325ms TTL=55
Reply from 139.175.50.166: bytes=32 time=181ms TTL=55
Reply from 139.175.50.166: bytes=32 time=265ms TTL=55
Reply from 139.175.50.166: bytes=32 time=297ms TTL=55
Reply from 139.175.50.166: bytes=32 time=325ms TTL=55
Reply from 139.175.50.166: bytes=32 time=353ms TTL=55
Reply from 139.175.50.166: bytes=32 time=375ms TTL=55
Reply from 139.175.50.166: bytes=32 time=115ms TTL=55
Reply from 139.175.50.166: bytes=32 time=113ms TTL=55
Reply from 139.175.50.166: bytes=32 time=114ms TTL=55 < End Test

Ping statistics for 139.175.50.166:
    Packets: Sent = 68, Received = 65, Lost = 3 (4% loss),
Approximate round trip times in milli-seconds:
    Minimum = 112ms, Maximum = 2639ms, Average = 271ms

And here is the speedtest result:

I added "cipher none" and "auth none" to the configs on both side. The speeds don't seem to be an issue, just the cutting out when I load things. Hopefully this is linked to MTU and there is a way to fix it >~<

EDIT: If it matters, the openvpn version I have downloaded from the repositories is 2.3.2 (That's the number I see when it's downloading).

EDIT2: I setup a PPTPD server again to see if it's the provider or my connection to the provider being an issue. I am having no issues with it at all, stable and constant speeds with no 'cutting out' or 'locking up'. Only happens to OpenVPN :c

Ryeuu

Thank you for all the help! I've finally found the issue. It was an issue with Windows 7 Home Premium 64-bit and the 9.21.1 TAP Adapter that came with OpenVPN. I tried upgrading to 9.9.2 and the issue almost completely subsided. I recently built a Windows 10 PC for a mate so I tested it on his and it worked flawlessly. Seems like it was only an issue with Windows 7 HP x64 + 9.21.1 adapter.

Thank you again for all the help! You can close this thread now ^^

Traffic

Thanks for letting us know your solution 8-)