openvpn: Actually apply configured parameters

openvpn: Actually apply configured parameters

OpenVPN is an absolute mess. The behaviour of configuration
parameters has been changed over the time; default values have been
changed over time; and it looks like nobody is actually testing
anything any more.

I have been spending hours today on figuring out why OpenVPN
is so damn slow. On a Lightning Wire Labs IPFire Mini Appliance
it achieves about 100 MBit/s in the default configuration when
"openssl speed -evp aes-256-gcm" achieves over 3.5 GBit/s.

Changing any of the cryptography parameters does not change
anything. Throughput remains around 100 MBit/s.

I finally set "cipher none" and "auth none" which disables
encryption and authentication altogether but does not increase
throughput. From here on it was absolutely clear that it was
not a crypto issue.

OpenVPN tries to be smart here and does its own fragmentation.
This is the worst idea I have heard of all day, because that job
is normally done best by the OS.

Various settings which allow the user to "tune" this are grossly
ineffective - let alone it isn't even clear what I am supposed
to configure anywhere. Setting "fragment 1500" weirdly still
does not convince openvpn to generate a packet that is longer
than 1400 bytes. Who'd a thunk?

There is a number of other parameters to set the MTU or which
are related to it (tun-mtu, link-mtu, fragment, mssfix).

On top of all of this we have two "bugs" in ovpnmain.cgi which
are being fixed in this patch:

1) mssfix can be configured by the user. However, we always
   enable it in openvpn. The default is on, we only add "mssfix"
   which simply turns it on.
   It is now being disabled when the user has chosen so in the
   web UI. I do not know if this is backwards-compatible.

2) We cap the MTU (tun-mtu) at 1500 bytes when fragment is being
   used. So it becomes pointless that the user can this and the
   user is not being made aware of this when they hit the save
   button.
   This was added when we added path MTU discovery. Since that
   did not work and was removed, we can remove this now, too.

I archived a solid 500-600 MBit/s of goodput with these settings:

* Disable mssfix
* Set "fragment" to 0
* Set MTU to 9000

I am sure the MTU could be further increased to have bigger packets,
but I did not test how badly this will affect latency of the tunnel.

OpenVPN seems to only be able to handle a certain amount of packets
a second - no matter what. With larger packets, the throughput of
the tunnel increases, but latency might as well.

Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Cc: Erik Kapfer <erik.kapfer@ipfire.org>
Cc: Stefan Schantl <stefan.schantl@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>