CONTROL messages are highly fragmented

[ValdikSS]

All CONTROL messages are highly fragmented (maximum payload size is 100 bytes) and seems to require P_ACK_V1 on every message. This introduces huge connection delay on high latency or lossy links.

Due to my specific configuration, I push 3000+ routes from OpenVPN server, and connection takes no less than 2 minutes.

[Gert Döring]

Yeah, we've recently discussed this on openvpn-devel, see here:

​http://article.gmane.org/gmane.network.openvpn.devel/9571

in off-list discussions we agreed that this was(!) intentional, but the original reasoning ("big packets might not get through") has never been really true, and OpenVPN 3 changed to use 1250 bytes. So, we'll do that for 2.x as well, but nobody has investigated yet which bits of the code need to be touched without causing side effects elsewhere.

I take the ticket, because I have an interest in getting this fixed - we push way less routes, but still, reducing the handshake time on higher latency links from 10 seconds to "under 1 second" would be a good thing.

(If you push 3000 routes, you do something wrong, though :-) - aggregate, and push exceptions for "holes in the aggregate" - you can push a route "10.0.0.0 255.255.255.0 net_gateway" with the magic keyword "net_gateway" to effectively leave 10.0.0.0/24 alone...)

[ValdikSS]

but the original reasoning ("big packets might not get through") has never been really true

Well, it depends on what to consider a big packet. I'd say 1250 bytes is a safe value, but I suppose it's better to decrease it down to 1200. For example, one of the biggest cell carrier in Russia has 1300 MTU and broken fragmentation support, so you can't even send fragmented 1400 bytes long ICMP requests. I know, this kind of broken network is rarely seen in the real life, but still.

I have a free VPN service which pushes only IP addresses which are banned in Russia, so there is no way to decrease the number of pushed routes.

I'd like to see this fixed in 2.3.7 if possible.

[Gert Döring]

Didn't make it to 2.3.7, but is a MUST HAVE for 2.4 release - so, ALPHA_2.4 milestone. Then, review, and lots of testing, and if considered "safe", 2.3.x

I think I heard a volunteer... :)

[ValdikSS]

I think I heard a volunteer... :)

Sure! I still have that strange link that discards huge fragmented packets I mentioned in comment 2. Is it in git master yet, or in any other branch?

[Gert Döring]

ValdikSS: wasn't thinking of you as a volunteer, but you'd make a good tester :-) - syzzer was already thinking loudly on IRC.

But if we aim for 1250 including overhead, we should be well below 1300 (IP-Header: 20 byte, UDP header: 8 byte)...

[Gert Döring]

So, here we go. Patch is in :-) - in *master* only, until we have more experience.

commit fc91d4b0071178e298052078431fb86f03be84fc (master)

Author: Steffan Karger
Date: Tue Jun 30 21:44:56 2015 +0200

Increase control channel packet size for faster handshakes

Signed-off-by: Steffan Karger <steffan@…>
Acked-by: Gert Doering <gert@…>
Message-Id: <1435693496-10931-1-git-send-email-steffan@…>
URL: ​http://article.gmane.org/gmane.network.openvpn.devel/9841

ValdikSS: for your use case (very large PUSH_REPLY from server to client), it will be sufficient to just add this to the server side. It talks to unmodified clients just fine (tested!), but should give you an 10x speed increase on lines with "high" latency.

Right now, packets will not exceed about 1200-1210 bytes, as we're very conservative here calculating the overhead. Improvements will come later.

[ValdikSS]

Applied this patch for OpenVPN 2.3.4 on server. The connection indeed is much faster now.

[Gert Döring]

Cool, thanks for testing and reporting back.

As a side note, running git master on the server side is usally fairly safe, and has one big benefit for your clients - the "tls float" (peer-id) patch really helps clients that sit behind stupid NAT boxes, read: when their public IP address changes, the server will just take note of this, and the client does not have to do a full reconnect.

[Gert Döring]

putting this on milestone 2.3.9 - when this comes up for release, we should have enough experience with the patch on git master servers and the android client to see whether it is safe enough for 2.3.x - I think it should be.

[ValdikSS]

commit 29b65ffdb2e7ed3d3b7bcac4048f6cd919ed13b3 for release/2.3.

[Gert Döring]

Thanks for reminding us - it's in 2.3, will be in 2.3.9, and all that was to do in *this* ticket has been done -> close!