summaryrefslogtreecommitdiffstats
path: root/content/posts/openvpn-issues-openbsd/index.org
blob: acb77931ce4956497b12ea7c9ae1f10eb56e0ea2 (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
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.