Opened 5 years ago

Closed 5 years ago

#545 closed Bug / Defect (fixed)

CONTROL messages are highly fragmented

Reported by: ValdikSS Owned by: Gert Döring
Priority: minor Milestone: release 2.3.9
Component: Generic / unclassified Version: OpenVPN 2.3.6 (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords: CONTROL
Cc: Steffan Karger

Description

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.

Change History (11)

comment:1 Changed 5 years ago by Gert Döring

Owner: set to Gert Döring
Status: newaccepted

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...)

comment:2 Changed 5 years ago by 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.

comment:3 Changed 5 years ago by Gert Döring

Cc: Steffan Karger added
Milestone: alpha 2.4

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... :)

comment:4 Changed 5 years ago by 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?

comment:5 Changed 5 years ago by 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)...

comment:6 Changed 5 years ago by 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.

comment:7 Changed 5 years ago by ValdikSS

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

comment:8 Changed 5 years ago by 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.

comment:9 Changed 5 years ago by Gert Döring

Milestone: alpha 2.4release 2.3.9

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.

comment:10 Changed 5 years ago by ValdikSS

comment:11 Changed 5 years ago by Gert Döring

Resolution: fixed
Status: acceptedclosed

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!

Note: See TracTickets for help on using tickets.