2
While using OpenVPN, measurements on server-side upstream (tun0 and eth0) and client-side downstream (Networx) agree that my connection is at 16 Mbit/s.
But, all of my PC applications are seeing exactly half of that speed.
[Server] <--16 Mbit/s--> [Client PC] <--8 Mbit/s--> [PC apps (e.g. Steam)]
What's up?
The Linux VPN server is using the default example configuration, except I'm using TCP, using a different port, changed cipher to AES-128, and I'm using fast-io and tcp-nodelay.
I also ran echo 1 > /proc/sys/net/ipv4/tcp_low_latency server-side.
For the Windows client, I disabled Nagle's algorithm. The rest follows the server settings (TCP, different ports, etc.)
All of those settings are in an effort to reduce latency which seems to work (200ms vs 35ms).
Server config:
# Base stuff
port XXXXX
dev tun
proto tcp
# Security stuff
ca ca.crt
cert server.crt
key server.key
dh dh2048.pem
tls-auth ta.key 0
key-direction 0
cipher AES-128-CBC
auth SHA256
user nobody
group nogroup
persist-key
persist-tun
verb 3
status openvpn-status.log
# Client rules
client-to-client # Allows clients to see each other
duplicate-cn # One config file for all clients
# Networking stuff
keepalive 5 120
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 208.67.222.222"
# Optimization stuff
sndbuf 0
rcvbuf 0
comp-lzo
tcp-nodelay
fast-io
Client OVPN file:
client
dev tun
proto tcp
tcp-nodelay
fast-io
remote X.X.X.X XXXXX
remote X.X.X.X XXXXX
resolv-retry infinite
nobind
persist-key
persist-tun
user nobody
group nogroup
remote-cert-tls server
cipher AES-128-CBC
auth SHA256
key-direction 1
comp-lzo
verb 3
sndbuf 0
rcvbuf 0
<ca>
XXXXXXXXXXXXXXXXXx
</ca>
<cert>
XXXXXXXXXXXXXXXXXx
</cert>
<key>
XXXXXXXXXXXXXXXXXx
</key>
<tls-auth>
XXXXXXXXXXXXXXXXXx
</tls-auth>
PNDA
Posted 2017-05-06T08:19:51.450
Reputation: 139
Is your server perhaps on an asymmetric connection? VPN over TCP is also terrible. All your latency tweaks will actually sacrifice throughput. – Daniel B – 2017-05-06T09:51:58.737
Your example Steam doesn't use Mbit but rather MB/s if I'm not mistaken. – Seth – 2017-05-06T10:47:55.723
@Seth I'm aware of this, and I've already converted it in the question. Inside Steam, it shows up as 1MB/s when I use the VPN. When I'm not using the VPN, it shows up as 2MB/s, which is my full bandwidth. – PNDA – 2017-05-06T11:36:38.193
@DanielB My university's firewall blocks all UDP traffic. And yes, I'm aware that I'm sacrificing throughput, but I'm not sure if those tweaks are supposed to exactly halve my bandwidth. Maybe it's a TCP thing (because of SYNs/ACKs)? I'm unable to test because... I can't UDP. – PNDA – 2017-05-06T11:41:28.430
1You can just remove all your latency tweaks and try again. Without buffering, every single packet probably needs to be ACK’d. (Compression causes latency by the way.) – Daniel B – 2017-05-06T17:33:32.350
@DanielB Thanks for the tip regarding the compression. I'll try it out later. Unfortunately, removing the latency tweaks didn't do anything, and added an average of 20ms delay between the client and server. – PNDA – 2017-05-06T19:29:44.553