Some time ago, I red about optimizing OpenVPN over Gbit networks. That post covers optimizations related to CPU bottleneck (hardware SSL support, different ciphers, etc). This was certainly not the case for me, since boxes linked via OpenVPN were mostly idle. However, that post has a very brief and accurate explanation and statement about how OpenVPN works, i.e. the data flow between source and destination.
So based on that post, I decided to try mssfix 0 (ie. disable OpenVPN packet fragmenting and leave the kernel/driver do that) and to increase tun-mtu parameter to help test speed improvements. I increased it to 32000 and I got about 150KB/s speed, then to 48000 and I got about 250KB/s, then to 60000 and I got 300KB/s. I thought "what if ...?" and I raised it to 65500. Amazingly, I got average speeds of 1.25MB/s with top speeds above 2.5MB/s.
That was cool, but had one downside: the VPN connection become unstable, with the tun0 device disappearing from the server (probably because the process that managed it crashed).
Reading further in OpenVPN man page and other posts, I decided that I should try to use OpenVPN's mssfix feature. Default value is 1500, but OpenVPN automatically reduces that in order to allow for the SSL data overhead. I decided to be on the safe size and use mssfix 1440. Heuristically, I thought I should use a tun-mtu that is a multiple of that (to help split the data in even fully-filled packets). So I used tun-mtu 64800. With these two settings on, the server proved stable and average transfer speeds went to about 850KB/s (good enough for my needs).
I should not that these transfer speeds were obtained by applying the same settings:
tun-mtu 64800in the client config. If no changes are applied to the client configs, the transfer speed will be still unacceptable low, but still higher than before (about 5KB/s).
mssfix 1440
