From d95ceb70de0a102983877eccd90777b015777ee2 Mon Sep 17 00:00:00 2001 From: Dante Catalfamo Date: Tue, 14 Jul 2020 00:34:47 -0400 Subject: Move openvpn-issues-openbsd-6.7 to remove numbers at end They were causing issues with hugo's ref system --- content/posts/openbsd-vpn-gateway/index.org | 15 +++++ content/posts/openvpn-issues-openbsd-6.7/cover.png | Bin 89359 -> 0 bytes content/posts/openvpn-issues-openbsd-6.7/index.org | 72 --------------------- content/posts/openvpn-issues-openbsd/cover.png | Bin 0 -> 89359 bytes content/posts/openvpn-issues-openbsd/index.org | 72 +++++++++++++++++++++ 5 files changed, 87 insertions(+), 72 deletions(-) delete mode 100644 content/posts/openvpn-issues-openbsd-6.7/cover.png delete mode 100644 content/posts/openvpn-issues-openbsd-6.7/index.org create mode 100644 content/posts/openvpn-issues-openbsd/cover.png create mode 100644 content/posts/openvpn-issues-openbsd/index.org (limited to 'content/posts') diff --git a/content/posts/openbsd-vpn-gateway/index.org b/content/posts/openbsd-vpn-gateway/index.org index 7add08d..2f6e784 100644 --- a/content/posts/openbsd-vpn-gateway/index.org +++ b/content/posts/openbsd-vpn-gateway/index.org @@ -93,3 +93,18 @@ Now if you check =ifconfig=, you should see the interface has the correct IP. + +* Configuring OpenVPN + + First we have to install [[https://openvpn.net/][OpenVPN]], which is provided by the OpenBSD + package manager. Normally we would install the =openvpn= package, + but due to an [[{{< ref "openvpn-issues-openbsd" >}}][issue with libressl]], we'll be installing the =mbedtls= + version. This problem should hopefully be resolved soon, so we'll + likely be able to use regular =openvpn= in the future. + + #+BEGIN_SRC shell + doas pkg_add openvpn--mbedtls + #+END_SRC + + Note: The =--mbedtls= is required to get the =mbedtls= flavour of + the =openvpn= package. diff --git a/content/posts/openvpn-issues-openbsd-6.7/cover.png b/content/posts/openvpn-issues-openbsd-6.7/cover.png deleted file mode 100644 index 0dad1fe..0000000 Binary files a/content/posts/openvpn-issues-openbsd-6.7/cover.png and /dev/null differ diff --git a/content/posts/openvpn-issues-openbsd-6.7/index.org b/content/posts/openvpn-issues-openbsd-6.7/index.org deleted file mode 100644 index acb7793..0000000 --- a/content/posts/openvpn-issues-openbsd-6.7/index.org +++ /dev/null @@ -1,72 +0,0 @@ -#+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. diff --git a/content/posts/openvpn-issues-openbsd/cover.png b/content/posts/openvpn-issues-openbsd/cover.png new file mode 100644 index 0000000..0dad1fe Binary files /dev/null and b/content/posts/openvpn-issues-openbsd/cover.png differ 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. -- cgit v1.2.3