Page 1 of 1

achieving maximum efficiency

Posted: Sat May 24, 2014 12:24 am
by avihsnis
Couple questions regarding mssfix and fragment

I've read the following;
Subject: Re: [Openvpn-users] Overhead added to each packet by OpenVPN?
From: James Yonan <jim@xxxxxxxxx>
Date: Tue, 30 Nov 2004 06:59:12 -0700 (MST)



On Mon, 29 Nov 2004, Rutger T. wrote:

> Dear group,
>
> I have a few questions regarding OpenVPN that I hope that you may help
> answer: 1) Is OpenVPN a transport layer protocol? (At least that's what
> I gathered from reading the FAQ....)

Yes.

> 2) OpenVPN supports VoIP (UDP)
> traffic right?

Yes.

> 3) Finally, and most importantly, how much overhead is
> added to each encrypted packet by OpenVPN? (i.e. How much additional per
> packet overhead is there for using OpenVPN?)

It varies depending on options. With a TUN-style tunnel over UDP using
the default TLS options, the per-packet overhead is:

41 bytes security layer overhead (includes packet tag (1), HMAC-SHA1
signature (20), initialization vector (16), sequence number (4))

28 bytes tunneling overhead (includes IP + UDP header)

Total: 69 bytes per packet

If your data stream is compressible, you can potentially gain back all of
this overhead.

James
which i take to mean that a tcp server with sha256 would have 93 bytes of overhead. or a udp server with sha256 would have 81 bytes of overhead. therefore, assuming i have a 1492 WAN MTU, my TUN-MTU for a UDP server becomes 1492-81 for a 1411. (or 1399 for a tcp server)

with that same UDP server and a tun-mtu of 1411, where does the 'fragment' overhead take place? is it part of the tunneled UDP datagram and thus fragment should be tun-mtu -32 (IP + UDP + fragment overhead) or is the fragment overhead apart of the openvpn 'security layer', thereby reducing tun-mtu another 4 bytes?

next question involves testing with a TCP server with tun-mtu=1399 and regarding mssfix vs tcpmss. I assumed mssfix is tun-mtu -40 (to account for IP+TCP), so i set mssfix and tcpmss for the same value of 1359, but in the case of iptables TCPMSS, to only apply when MSS is 1400:1546 for -o tun22. This iptables rule is still being hit; why?

Thanks in advance!

Re: achieving maximum efficiency

Posted: Sat May 24, 2014 1:17 am
by avihsnis
sorry, couldn't find where to edit the post.

the iptables TCPMSS rule was being hit during a latency test and during the upload portion of a bandwidth test.

is the 'fragment' overhead perhaps only applied to tunneled udp datagrams, but in the openvpn layer? therefore fragment should always be tun-mtu -4, and this would make 'fragment' useful for tcp servers as well?

Re: achieving maximum efficiency

Posted: Sat May 24, 2014 1:44 am
by avihsnis
disregard this post

Re: achieving maximum efficiency

Posted: Sat May 24, 2014 3:24 am
by avihsnis
alright, so i seem to have a best performance on a UDP OpenVPN server with SHA256 auth and a 1492 WAN MTU (PPPoE) with the following;

previous calculated tun-mtu of 1411 -4 because the fragment options appears to add overhead for everything, results in the following;

tun-mtu 1407
fragment 1407
mssfix 1367

and for a TCP OpenVPN server, also with SHA256 and a 1492 WAN MTU;

tun-mtu 1399
mssfix 1359