Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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/ /etc/pam.d/login
#plugin /usr/share/openvpn/plugin/lib/ /etc/pam.d/login #- Comment this line if you are using FreeRADIUS
#plugin /etc/openvpn/ /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?

share|improve this question
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
Theres nothing illegal about it. It's just the only way to access my own systems remotely. :) – user192680 Oct 12 '13 at 14:33
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 at 13:41

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!

share|improve this answer

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.