Opened 8 years ago
Last modified 3 years ago
#647 assigned Bug / Defect
Cannot connect to 2.3.4 server using client version >= 2.3.9 (TLS Error - handshake failed)
Reported by: | peter.meier | Owned by: | Gert Döring |
---|---|---|---|
Priority: | minor | Milestone: | release 2.6 |
Component: | Generic / unclassified | Version: | OpenVPN 2.3.9 (Community Ed) |
Severity: | Not set (select this one, unless your'e a OpenVPN developer) | Keywords: | |
Cc: | Gert Döring, tct |
Description
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
Change History (14)
comment:1 Changed 8 years ago by
Version: | 2.3.10 → 2.3.9 |
---|
comment:2 Changed 8 years ago by
Cc: | Gert Döring added |
---|
comment:3 Changed 8 years ago by
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.
comment:4 follow-up: 5 Changed 8 years ago by
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.
comment:5 Changed 8 years ago by
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.
comment:6 Changed 8 years ago by
Milestone: | → release 2.3.11 |
---|---|
Owner: | set to Steffan Karger |
Status: | new → assigned |
Any (easy) idea how to tackle this...?
comment:7 Changed 8 years ago by
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?
comment:8 Changed 8 years ago by
Milestone: | release 2.3.11 → release 2.3.12 |
---|
comment:9 Changed 7 years ago by
Owner: | changed from Steffan Karger to Gert Döring |
---|
The patch I mentioned above has been applied:
https://github.com/OpenVPN/openvpn/commit/29b65ffd
Transferring this ticket to the networking department...
comment:10 Changed 7 years ago by
Milestone: | release 2.3.12 → release 2.3.14 |
---|
comment:11 Changed 7 years ago by
Milestone: | release 2.3.14 → release 2.3.15 |
---|
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...
comment:12 Changed 7 years ago by
Priority: | critical → minor |
---|
comment:13 Changed 4 years ago by
Cc: | tct added |
---|
comment:14 Changed 3 years ago by
Milestone: | release 2.3.15 → release 2.6 |
---|
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"
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 ;-) )