diff options
Diffstat (limited to 'content/posts/openvpn-issues-openbsd/index.org')
| -rw-r--r-- | content/posts/openvpn-issues-openbsd/index.org | 72 |
1 files changed, 72 insertions, 0 deletions
diff --git a/content/posts/openvpn-issues-openbsd/index.org b/content/posts/openvpn-issues-openbsd/index.org new file mode 100644 index 0000000..acb7793 --- /dev/null +++ b/content/posts/openvpn-issues-openbsd/index.org @@ -0,0 +1,72 @@ +#+TITLE: Issues with OpenVPN on OpenBSD 6.7 +#+DATE: 2020-06-14T14:08:06-04:00 +#+DRAFT: false +#+DESCRIPTION: Getting to the bottom of VPN connectivity issues on OpenBSD 6.7 +#+TAGS[]: openvpn openbsd libressl +#+KEYWORDS[]: +#+SLUG: +#+SUMMARY: + +#+ATTR_HTML: :alt No connection to ProtonVPN from OpenBSD +#+ATTR_HTML: :title No connection to ProtonVPN from OpenBSD +[[file:cover.png]] + +I have an OpenBSD VPN gateway I use to send all traffic it receives +over a VPN connection, and I noticed that no traffic was going through. + +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. + +#+BEGIN_SRC +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 +#+END_SRC + +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. |