Cannot connect to 2.3.4 server using client version >= 2.3.9 (TLS Error - handshake failed)

[peter.meier]

Using a 2.3.8 client on Fedora 23 with the following config works fine to connect to a Debian based 2.3.4 server:

client
remote openvpn.example.com
ca /home/peter/.pki/nssdb/server.ca
cert /home/peter/.pki/nssdb/client.crt
key /home/peter/.pki/nssdb/client.key
dev tun
proto udp
nobind
auth-nocache
script-security 2
persist-key
persist-tun
user openvpn
group openvpn

(Config exported through NetworkManager?).

However, after upgrading to 2.3.9 or even 2.3.10 on the client (std. fedora updates) connecting to the Debian based 2.3.4 Server (std. config) does not work anymore. Opening the connection simply times out on the client side, however on the server I can see the following logs:

Jan 11 23:24:17 server systemd[1]: Started OpenVPN connection to server.
Jan 11 23:24:50 server ovpn-server[24767]: X:X:X:X:36210 TLS_ERROR: BIO read tls_read_plaintext error: error:0D07207B:asn1 encoding routines:ASN1_get_object:header too long: error:0D068066:asn1 encoding routines:ASN1_CHECK_TLEN:bad object header: error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error: error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error: error:0D08403A:asn1 encoding routines:ASN1_TEMPLATE_EX_D2I:nested asn1 error: error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error: error:1408900D:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:ASN1 lib
Jan 11 23:24:50 server ovpn-server[24767]: X.X.X.X:36210 TLS Error: TLS object -> incoming plaintext read error
Jan 11 23:24:50 server ovpn-server[24767]: X.X.X.X:36210 TLS Error: TLS handshake failed

Downgrading only the openvpn package on the client makes things working again.

There doesn't really seem to be a difference in the 2 openvpn versions on the client:

$ openvpn --show-ciphers --show-digests --show-engines; openvpn --version >> 2.3.8
$ sudo dnf update openvpn
$ openvpn --show-ciphers --show-digests --show-engines; openvpn --version >> 2.3.10
$ diff -Naur 2.3.8 2.3.10 
--- 2.3.8	2016-01-11 23:11:01.773698483 +0100
+++ 2.3.10	2016-01-11 23:11:11.605720665 +0100
@@ -105,7 +105,7 @@
 Intel RDRAND engine [rdrand]
 Dynamic engine loading support [dynamic]
 
-OpenVPN 2.3.8 x86_64-redhat-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Aug  4 2015
+OpenVPN 2.3.10 x86_64-redhat-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Jan  4 2016
 library versions: OpenSSL 1.0.2e-fips 3 Dec 2015, LZO 2.08
 Originally developed by James Yonan
 Copyright (C) 2002-2010 OpenVPN Technologies, Inc. <sales@openvpn.net>

The error is 100% reproducible for 2 different Fedora Users, as well as for an Arch Manjaro user. Downgrading below 2.3.9 always solves the issue.

Server Config

$ grep '^[a-z]' /etc/openvpn/server.conf 
port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key  # This file should be kept secret
dh dh.pem
keepalive 10 120
max-clients 100
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
verb 1
client-config-dir clients
tun-mtu 1100

[Steffan Karger]

Thank you for a decent bug report.

This probably has something to do with this commit:
​https://github.com/OpenVPN/openvpn/commit/29b65ffd

Could you try and see if the problem goes away if you remove the tun-mtu line from the server config?

(That's not a real solution of course, we'll have to dive in further later on. But first some sleep ;-) )

[Gert Döring]

Thinking about it, it's quite likely asymetric --tun-mtu - if the server has tun-mtu 1100, the client should have that as well. It will then derive link-mtu from it, and use the minimum of (link-mtu,1250) for the control channel packets.

If the client-sent control channel packets are too big, the rcvmsg() on the server will only read a partial packet, and that would match the OpenSSL error message.

Or just make --tun-mtu reasonably big, like 1300 or so.

[peter.meier]

You were right. Removing the tun-mtu setting fixed the problem. Thank you! We likely had the mtu setting due to some legacy reasons of nodes behind dsl lines and some other weird problems.

The error you get atm is quite opaque, but I have no idea whether you are able to detect that or could just give a bigger warning on mtu's smaller than the 1250+x

And if there are people really needing a smaller mtu you probably want to make the size of the control channel packet size configurable, which would then also require adjustment.

[Gert Döring]

Replying to peter.meier:

And if there are people really needing a smaller mtu you probably want to make the size of the control channel packet size configurable, which would then also require adjustment.

It already *is* - but the size of the control-channel packets depends on the tun-mtu / link-mtu settings on the sending side, so if you do not configure it on the client(!), the packets arriving at the server will be "big"... if both sides have a symmetric --tun-mtu 1100, it "should" work right (--tun-mtu affects --link-mtu, control-channel packet size is calculated based on --link-mtu, capped at 1250).

The warning is a good idea, but wouldn't have helped you here - if we add a warning to 2.3.11, your server would still run on 2.3.4 and not see this warning :-) - but anyway, I think we can make this more robust and at least provide a more clear error message for "new" servers.

[Gert Döring]

Any (easy) idea how to tackle this...?

[Steffan Karger]

I sent a patch a while ago to make OpenVPN accept some 'oversized' control channel packets even when misconfigured, which is awaiting review:
​http://thread.gmane.org/gmane.network.openvpn.devel/11274

There will still be situations where OpenVPN drop too-big packets after this patch, but it is less likely to happen.

I'm not so sure on what a warning should say, and in which situation. Gert, that seems more like your expertise. Can you tackle that part?

[Steffan Karger]

The patch I mentioned above has been applied:
​https://github.com/OpenVPN/openvpn/commit/29b65ffd

Transferring this ticket to the networking department...

[Gert Döring]

If we have a warning at all (which I'm not fully decided yet), it would be something alonge the lines of "*-mtu has been configured lower than <threshold>, which affects control packet size - make sure *-mtu is symmetric otherwise TLS negotiation fails".

... and for bonus points, only print this warning *iff* TLS negotiation actually fails...

[Gert Döring]

So. The original cause was fixed, the issue all but forgotten, and it very much will not hit release 2.3.15 anymore (or any 2.3.x).

Opening this up for "maybe we want to revisit general MTU topics in the 2.6 time frame"