Try rearranging files for ease of use with `easy-hugo`

1 files changed, 0 insertions, 72 deletions

diff --git a/content/post/openvpn-issues-openbsd-6.7/index.org b/content/post/openvpn-issues-openbsd-6.7/index.org
deleted file mode 100644
index a9c34bd..0000000
--- a/content/post/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:
-#+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:openbsd%20protonvpn%20no%20connection.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.