EDIT: (August 22, 2020) Theo Buehler has kindly reached out to me and informed me that this issue has just been fixed in a syspatch, and that OpenVPN now works correctly.

Hi.

Regarding https://blog.lambda.cx/posts/openvpn-issues-openbsd/, the issue you describe in this post should be fixed in 6.7-stable.

It boils down to this:

1. ProtonVPN appears to require clients to use P-521 for the TLSv1.3 key exchange.
2. Released versions of OpenVPN do not permit customizing the curve to use for the key exchange (they added a –tls-groups option in their dev branch).
3. LibreSSL defaulted to enabling X25519, P-256, P-384, but not P-521, (same defaults as BoringSSL) while OpenSSL additionally enables P-521.
4. Another issue people ran into is that we did not support EC client certificates in the released version.

In the latest syspatches 019 and 020, we enabled P-521 by default client side and also added support for EC client certificates.

Long story short: after running syspatch, your OpenVPN setup should work with LibreSSL.

This fix is also discussed on the associated libressl-portable github issue here.

I'd been using ProtonVPN as my provider for months prior to this without any issues, so it was very confusing when it stopped working.

No matter which VPN profile I used from ProtonVPN, it always gets stuck after the step TLS: Initial packet from [AF_INET]XXX.XXX.XXX.XXX:YY. Regardless of whether I tried the individual server profiles, country profiles, free, or plus profiles.

I tried starting openvpn with maximum verbosity. Everything launched exactly as it should, until it gets to the TLS handshake, where it failed to get a response.

Sun Jun 14 15:37:22 2020 us=577519 UDP link local: (not bound)
Sun Jun 14 15:37:22 2020 us=577532 UDP link remote: [AF_INET]XXX.XXX.XXX.XXX:YYYY
Sun Jun 14 15:37:22 2020 us=577650 UDP WRITE [86] to [AF_INET]XXX.XXX.XXX.XXX:YYYY: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 pid=[ #1 ] [ ] pid=0 DATA len=0
Sun Jun 14 15:37:22 2020 us=739355 UDP READ [98] from [AF_INET]XXX.XXX.XXX.XXX:YYYY: P_CONTROL_HARD_RESET_SERVER_V2 kid=0 pid=[ #1 ] [ 0 ] pid=0 DATA len=0
Sun Jun 14 15:37:22 2020 us=739517 TLS: Initial packet from [AF_INET]XXX.XXX.XXX.XXX:YYYY, sid=19fe5aac 2d00f4aa
Sun Jun 14 15:37:22 2020 us=739658 UDP WRITE [94] to [AF_INET]XXX.XXX.XXX.XXX:YYYY: P_ACK_V1 kid=0 pid=[ #2 ] [ 0 ]
Sun Jun 14 15:37:22 2020 us=739798 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Sun Jun 14 15:37:22 2020 us=739900 UDP WRITE [331] to [AF_INET]XXX.XXX.XXX.XXX:YYYY: P_CONTROL_V1 kid=0 pid=[ #3 ] [ ] pid=1 DATA len=245
Sun Jun 14 15:37:24 2020 us=832019 UDP WRITE [331] to [AF_INET]XXX.XXX.XXX.XXX:YYYY: P_CONTROL_V1 kid=0 pid=[ #4 ] [ ] pid=1 DATA len=245
Sun Jun 14 15:37:29 2020 us=32189 UDP WRITE [331] to [AF_INET]XXX.XXX.XXX.XXX:YYYY: P_CONTROL_V1 kid=0 pid=[ #5 ] [ ] pid=1 DATA len=245

It just kept repeating the write until it timed out after 60 seconds. It was like this for every country, on every port. Even using the TCP profiles, but instead there the connection would get reset almost immediately instead of timing out.

I tried several free VPNs I found online just to compare, and all of them worked without issue. This problem has only happened for me with ProtonVPN servers.

I tried connecting using both my desktop machine, and an Ubuntu VM, both of which were able to connect without issue. The problem wasn't with the account itself.

I tried using another OpenBSD VM on my network, and the result was the same as the VPN gateway, a timeout. I even spun up a fresh OpenBSD VM in Vultr to see if the issue persisted on a new install in a different network. The issue was still there.

I was sure to check that the system clocks were correct on each machine, and also tried commenting out all lines in the VPN profile that weren't strictly required to make the connection, like mtu and compression settings.

As a final attempt, I tried installing OpenVPN with mbedtls. For all my previous experiments, I had been using the default openvpn package, which uses OpenBSD's LibreSSL. That time it worked perfectly.

It occurred to me that this had been the first time I'd checked up on the VPN gateway since updating to OpenBSD 6.7. I guess something about a recent LibreSSL update has broken a feature OpenVPN relies on in certain situations.