On 2018-11-04 11:39:59 [-0800], James Bottomley wrote: > > > OK, so I'm weary of trying to construct a theory of what the bug > > > actually is, why don't you try to come up with one. The symptoms > > > are > > > that openvpn in openwrt works with server 1.1.0 and fails with > > > server > > > 1.1.1 if you don't specify tls-version-min 1.0 on the command line. > > > > On which side do you use tls-version-min? > > client > > > Can you please give the version of both openvpn and openssl on both > > sides. > > Client is openwrt, server is debian testing. The package of the server > was already provided in the bug report, but again it's > > openssl 1.1.1-2 > openvpn 2.4.6-1 > > Packages on the openwrt client are > > libopenssl 1.0.2g-1 > openvpn-openssl 2.3.6-5
That matches what I see. The Jessie version (which matches your openwrt client) does TLSv1.0 only by default. If you specify tls-version-min (even 1.0) then it tries 1.0+ and does the best possible protocol which is TLS1.2 in my case. Stretch seems to do the best possible version by default. Buster/Testing has TLS1.0 disabled by default. So in your environment the client tries TLS1.0 only and server does TLS1.2 only. Adding tls-version-min on the client side enables TLS1.0+ and handshakes with TLS1.2. This behaviour has been reported as #912650 on the Debian side. > James Sebastian
