I've been trying to improve my OpenVPN performance and this is my current setup:

 cat /etc/openvpn/server.conf
port 443 #- port
proto tcp #- protocol
dev tun
#tun-mtu 1500
tun-mtu-extra 32 
#mssfix 1450
tun-mtu 64800
mssfix 1440
reneg-sec 0
ca /etc/openvpn/easy-rsa/2.0/keys/ca.crt
cert /etc/openvpn/easy-rsa/2.0/keys/server.crt
key /etc/openvpn/easy-rsa/2.0/keys/server.key
dh /etc/openvpn/easy-rsa/2.0/keys/dh1024.pem
plugin /etc/openvpn/openvpn-auth-pam.so /etc/pam.d/login
#plugin /usr/share/openvpn/plugin/lib/openvpn-auth-pam.so /etc/pam.d/login #- Comment this line if you are using FreeRADIUS
#plugin /etc/openvpn/radiusplugin.so /etc/openvpn/radiusplugin.cnf #- Uncomment this line if you are using FreeRADIUS
push "redirect-gateway def1"
push "dhcp-option DNS"
push "dhcp-option DNS"
keepalive 5 30
status 1194.log
verb 3


dev tun
proto tcp
remote 443
resolv-retry infinite
tun-mtu 64800
tun-mtu-extra 32
mssfix 1440
verb 3

I made some changes to MTU and MSSFIX from what I found on the web.

Are there any kernel changes I could make? This is a CentOS 6.x box. I found some stuff for BSD based but nothing that worked for Linux.

I know TCP is slower then UDP but I need to be able to look like SSL traffic to get thru a firewall on the network.

Other ideas?

PING to another client on the network which I RDP into.

Pinging with 32 bytes of data:
Reply from bytes=32 time=152ms TTL=128
Reply from bytes=32 time=565ms TTL=128
Reply from bytes=32 time=152ms TTL=128
Reply from bytes=32 time=782ms TTL=128

Ping statistics for
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 152ms, Maximum = 782ms, Average = 412ms

Are there any ways to improve performance or drop the ping some?

EDIT: Would setting the fragmentation setting help some?

  • I know TCP is slower then UDP but I need to be able to look like SSL traffic to get thru a firewall on the network. Why not ask your network administrator to open the openvpn port at work? On a related note, this question as is may violate the terms of the FAQ Licensing, legal advice, and *circumvention of security or policy* I would clarify. – prateek61 Oct 11 '13 at 10:11
  • 1
    Theres nothing illegal about it. It's just the only way to access my own systems remotely. :) – user192680 Oct 12 '13 at 14:33
  • 2
    I was talking more about bypassing the firewall policy at wherever you are. Why can't you ask the network administrator to open the port? I was not really talking about the legality, more about circumventing security policy. – prateek61 Oct 13 '13 at 2:14
  • Maybe sshuttle would work better for you for tcp-over-tcp vpn – ptman Jan 24 '16 at 13:41

Short answer: disable comp-lzo.

I realize this is an old post, but I was also suffering from poor OpenVPN performance. I had tried everything, adjusting the MTU, changing the snd and rcv buffers, mss clamping, you name it. CPU load was negligible.

On a whim, I disabled compression (removed comp-lzo from the client and the server) and performance increased 2-4x.

So, with comp-lzo enabled my max performance was around 25-30 Mbit/s, and without it I hit 120 Mbit/s (my internet connection speed).

Server is a Xeon E5-2650, client is Core i5-3320M. Both running OpenVPN 2.3.10, AES-256-CBC, SHA512. My Intel Chromebook also maxed out my internet speed. Performance doubled on my Android clients (14 Mbit/s -> 30 Mbit/s), matching IKEv2 tunnel speed.


TCP is going to be /much/ slower than UDP, caused by the TCP-over-TCP problem. Basically, TCP relies on packet drops/congestion to identify connection parameters, and your TCP-over-OpenVPN connections do not experience either of those. But you've said that's not an option.

You could also try the mtu-disc option to automatically discover the optimal MTU settings for your connection. There are slight mismatches in different places, such as OpenVPN's MTU setting including the size of the Ethernet header. [1]

Your tun-mtu setting is massive, as a 65KB packet is going to have a lot of latency issues going through the internet (IPv4 jumbo packets are around 9000 bytes in size, and mostly work on local networks). Try something under 1460 instead, like 1300, to see if MTU is your issue.

  • 2
    Thanks, that solved my problem with getting a postgresql-query to work over OpenVPN. It worked when querying over a single column, but not for the whole column. Apparently that was caused by the default MTU-Size of 1500. Setting it to 1300 helped! – Christian Benke Aug 8 '16 at 13:43

Even though this might be a bit late, you may try what I did:

remove all mss, mtu, etc related options

do a port scan at your institution and selected a UDP port, generally 53 GRE /123 NDP ports should be open:

Add these lines to your server config (ref here)

#possible bandwidth increase
sndbuf 393216
rcvbuf 393216
push "sndbuf 393216"
push "rcvbuf 393216"

I do not fully understand these settings but they surely did help, some say it helps alot, in my experience, it increased my throughput by +/- 30%

Start the server on one of those ports and you should be good to go :P

Hope this helps!

  • 8
    -1 for too much vodoo and not understanding what things actually do. I find it irresponsible to recommend something then, honestly. – Preexo Apr 5 '16 at 6:49

sndbuf and rcvbuf correct an ANCIENT setting in linux/unix/openvpn from dialup days to optmimize for slower settings even though the OS is optimized for faster ones

sndbuf/rcvbuf set to 0 will simply use the OS's settings

push is used to make sure the client is set properly but there you need a value.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy