openvpn build with libressl-3.1.3 does not connect

[jkoderu-git]

System

• xuname:
  Void 5.4.46_1 x86_64 AuthenticAMD uptodate hold rDF
• package:
  openvpn-2.4.9_2

Expected behavior

Connect successfully to openvpn server

Actual behavior

Error is

TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
TLS Error: TLS handshake failed

Full log

OpenVPN 2.4.9 x86_64-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Jul  4 2020
library versions: LibreSSL 3.1.3, LZO 2.10
Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
TCP/UDP: Preserving recently used remote address: [AF_INET]{IP1}:1194
Socket Buffers: R=[212992->212992] S=[212992->212992]
UDP link local: (not bound)
UDP link remote: [AF_INET]{IP1}:1194
TLS: Initial packet from [AF_INET]{IP1}:1194, sid=38277fca 0cce7134
WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
TLS Error: TLS handshake failed
SIGUSR1[soft,tls-error] received, process restarting
Restart pause, 5 second(s)
TCP/UDP: Preserving recently used remote address: [AF_INET]{IP2}:1194
Socket Buffers: R=[212992->212992] S=[212992->212992]
UDP link local: (not bound)
UDP link remote: [AF_INET]{IP2}:1194

Steps to reproduce the behavior

Connect to protonvpn with protonvpn-cli.

Downgrading to openvpn-2.4.9_1 works and it connects. Upgrading to openvpn-2.4.9_2 is above issue.

Where is the problem? Libressl,void packaging?

[Johnnynator]

Can you check if this only affects UDP connection, and not TCP?

[TinCanTech]

Also, see your server log.

[jkoderu-git]

Can you check if this only affects UDP connection, and not TCP?

NOTE: --fast-io is disabled since we are not using UDP
TCP/UDP: Preserving recently used remote address: [AF_INET]{IP}:443
Socket Buffers: R=[131072->131072] S=[16384->16384]
Attempting to establish TCP connection with [AF_INET]{IP}:443 [nonblock]
TCP connection established with [AF_INET]{IP}:443
TCP_CLIENT link local: (not bound)
TCP_CLIENT link remote: [AF_INET]{IP}:443
TLS: Initial packet from [AF_INET]{IP}:443, sid=d28975c1 7e6b3c32
Connection reset, restarting [0]
SIGUSR1[soft,connection-reset] received, process restarting
Restart pause, 5 second(s)

It is a loop.

Also, see your server log.

It is not my server. I have protonvpn.

[TinCanTech]

Note:

1. OpenVPN does not officially support LibreSSL. (It may or may not work)
2. If LibreSSL 3.x is equivalent to OpenSSL 3.x then it is, at best, currently experimental.
3. ProtonVPN obviously do not provide support for this.

A much more suitable test would be for you to setup your own server.

[ericonr]

We might need some patches from https://openports.se/net/openvpn

[Johnnynator]

Can you run openvpn with more verbose output --verb 6 (or even higher) and check which cipher it tries to use?

[TinCanTech]

--verb 4 is more suitable, any higher is mainly for debugging openvpn code.

[jkoderu-git]

tcp6.txt
udp6.txt
tcp11.txt

[HadetTheUndying]

This is effecting protonvpn-cli as well since openvpn is a requirement

[TinCanTech]

Why do you expect Protonvpn to support a version 3.x (development) SSL library ?

Especially one which OpenVPN themselves do not support ...

[Johnnynator]

LibreSSL 3.1.3 is NOT a development library. The versioning does not match with the OpenSSL one. Furthermore the Server does not have to care about the version of a client lib, as long as both ends work correctly (and either one of them doesn't)

[TinCanTech]

Sure but

1. OpenVPN clearly state that they do not support LibreSSL
2. You do not have access to ProtonVPN servers therefore have no idea why the connection fails.

[HadetTheUndying]

@TinCanTech it was working fine until this update, hence why I was reporting. Also as stated it is not a development release. For me this is just more indication that it's time the switch back to openssl. Between these kind of issues in the ABI issues, the choice to use libressl now that the issues surrounding heartbleed have long since been remedied, is mostly an exercise in frustration.