A few days ago, I posted a “quick” guide on how to set up an OpenVPN server on a VPS. Despite my efforts to keep it short, it wasn’t that short so I chose to keep my comments to a minimum, and to put the biggest chunk of them in this companion post.
If you don’t want the blah-blah, background story, setup improvement ideas, philosophical considerations, the meaning of life, etc., go straight to the guide there. Otherwise here it goes. Ah, and the bibliography is here too, though. Maybe that’s a reason to scroll all the way to the bottom before leaving 👀

Motivations / background story

And no, this isn’t just for the sake of telling my life. Although coming back here after a couple hours of writing, I guess I did a bit lot. Oops.
TL;DR: this explains, in more details than it should, why the security aspects were (almost) not a concern, and more globally why I wanted to go fast, to the minimum working setup.

A long time ago, this “not-a-blog” was hosted on a 1&1 VPS. Due to some “issues“, I then moved to OVH (10 years ago already, damn…). Funny thing about that, I noticed a few days ago that Ionos (new brand for the 1&1 hosting) finally added the ability to register a secondary e-mail to receive invoices. That change was made almost exactly 10 years after I posted about the “issues”. Happy 10-year anniversary to me, lol.
The not-so-cool thing they did when they implemented that feature, though, is that now I get a duplicate copy of the invoice messages even in my internal Ionos message box… What can I say, when you’re not smart, you’re not smart 🤷

About a year ago, I noticed that Ionos now had some interestingly cheap VPSs, so in January of this year-soon-to-be-last-year, I picked one. To give it a spin, and maybe more later. With just 512 MiB of RAM though, I could only do so much with it, and I basically used it as a proxy (SSH tunnels are so great and underrated, underappreciated, under…thing, etc) and to run some scripts that I wanted to keep running even when my own computer had to be off.
A nice great feature compared to my OVH VPSs was (and still is) that the IP I got was less detected as “EVIL FROM A DATA-CENTER ME BLOCK YOU HAHAHA” by the usual Internet shitheads such as CloudFlare and the like, compared to all the IPs I ever got from OVH. Here I want to point out that I don’t do weird traffic from my VPSs, I only host my own stuff, run very specific scripts such as Steam idling bots, and use them as personal proxies; so when the assholes from CloudFlare, Reddit, and similar services (sorry I forgot their names but I despise them just like CloudFlare – I’ll try to remember to come back and add them to this post as I encounter them) give me a captcha Hell (if they don’t just purely block me) it’s not because of a “bad” activity it’s because they suck and just blanket ban anything with “datacenter” on it. On a side-side-side note: that’s why we can’t have competition against Google, thanks very much!
Another nice feature is that the speed was better: officially 400Mbps, compared to 100Mbps at OVH, and even though I don’t think I ever reached that speed, it was in that ballpark.
So, I was happy to keep it for the duration of my initial contract period (initially 1 year, then it would be monthly) even though it appeared clear that it wouldn’t make sense to use it for hosting.

As the initial contract came close to an end, a few days ago (with a bit more than a month remaining), I browsed their VPS offering again. And I was very pleased to find that they had improved it significantly: twice the RAM (1 GiB) and more than twice the speed (1Gbps), for the same price. Yay.
Unfortunately, it wasn’t possible to migrate my old VPS to the new offer. No big deal, I canceled (it’s still running, until the end of the yearly contract) and picked up a new VPS. I actually did that over the phone (as I wanted to ask them about the migration), and they very kindly zeroed the last bill for my former VPS, considering that I was upgrading and signing again for a year.

So here I am, with my new VPS, reinstalling it already minutes after getting it because Ubuntu 22.04 felt a bit too old after all compared to the 5-months old Debian 12 (keeping up with recent versions isn’t Ionos’s strong suit). Another point in favor of for Debian 12 was that, right after installation, df -h reported 1.5 GiB used space for Ubuntu 22.04 but only 688 MiB for Debian 12 (up to 950 MiB after just running apt-get update && app-get upgrade). Considering the VPS only comes with 10 GiB of disk space, that’s always good to take.

I then proceeded to install Nodejs and my first script, a home-made Steam idler and name changer/randomizer. And boom, the letdown: the script times out when logging in… After trying a few more times, it eventually works, but in the process I realized that the timeouts are due to an excessive CPU usage, or to put it another way: the CPU of the new VPS sucks. Well, I guess Steam’s login process sucks too (on a side note, maybe now I know one of the many reasons why their client is so bloody slow), but I can’t quite change it.
If you are curious, cat /proc/cpuinfo for my “old” VPS gives (I kept just the most relevant parts – hopefully I didn’t cut too much):

cpu family      : 6
model           : 63
model name      : Intel(R) Xeon(R) Gold 6230R CPU @ 2.10GHz
stepping        : 0
microcode       : 0x5003302
cpu MHz         : 2099.999
cache size      : 36608 KB

and the new VPS gives:

cpu family      : 25
model           : 1
model name      : AMD EPYC-Milan Processor
stepping        : 1
microcode       : 0x1000065
cpu MHz         : 1996.250
cache size      : 512 KB

I assume there’s a little difference in the way the cache size is computed between both cases ^^
But besides that, I wasn’t aware that the cores of a AMD’s Epycs were so rubbish. Unless Ionos decided to cut costs and make it so that a “vCPU” for their VPS was less than half a core (I don’t know virtualization enough to know how feasible this is).
Or maybe it’s a result of having less cache, since, as far as I know, this Xeon(R) Gold 6230R has 22 cores (44 threads) so that would be 36608 / 44 = 832 KiB of cache per thread, significantly more than the 512 KiB of that EPYC-Milan 🤔

I then tried running another script, which I was running on one of my OVH VPSs so far. It worked for a while, but crashed at some point. Not sure why because I didn’t monitor it closely, but I assume it’s due to a lack of RAM this time (the server where it ran before had 2 GiB, and that’s quite a wasteful script RAM-wise).

So I was left with the question: what to do with that VPS where I can’t seem to run anything useful? Should I refund it and keep the old one? As I understood, despite the 1-year contract, refunding is possible. But considering I was offered the last month on the other server for giving it up, won’t it create troubles (although now maybe I understand why they were happy about my switch…)?
I can still use it as a proxy with my dear SSH tunnels though. I’ve had a lot of fun with SSH tunnels in the past (tags are great, I should use them more – I edited one of these posts for the first time since June 2010 just to add it the tunnel tag 👀).
I also had a soon-to-be-over-and-definitely-not-renewed NordVPN subscription. With no replacement yet. And, while SSH tunnels are great for Firefox on desktop, they are sadly not that possible for some other software, and, particularly, for the stupid phones.

So, how about… setting up my own OpenVPN server? On that VPS running Debian 12?
I had looked into this (briefly) a few times in the past already, and from what I gathered, setting this up looked like quite a painful process. Particularly if you compare it with my dear SSH tunnels. This would also be 1) just for my own use and 2) most likely temporary, because I don’t really expect to be happy to stick to a single IP rather than happily hop from a server to another at a commercial VPN/proxy. I also had in mind that WireGuard should hopefully replace this horrible OpenVPN one day (I say horrible because, as far as I understood and observed, at least on Windows, it writes all the bloody network data to the disk, wearing out your SSD for no good reason), so I’m not that interested in learning how to set up OpenVPN perfectly.
Which is why I opted to go for the minimum effort installation (where “minimum” still isn’t quite tiny), keeping default settings and taking shortcuts as often as I could.

Comments on my setup

For this section, you may want to have the other post (the one with the guide) open next to this one.

To not root or not to root

(that title doesn’t contain a typo)
I’ll start by the obvious that I did everything as root and that “it’s very bad”. For a clean set up, you’ll want to never use the root account but one with sudo privileges, and you’ll want to create a user (and group) just for openvpn. I wish you a lot of fun with that! (and with the permission hell, hahaha)

EasyRSA

The easy-rsa package is automatically installed when you install the openvpn package. But trying to run “easyrsa” gave nothing. All-in-all, it’s mostly just a single script file so it just works if you get the script as I did. But if you want your certificate to “look good”, you’ll probably want to get the sample configuration file and edit it, and place it wherever it should be (don’t ask me…), so as to put a name, company name, country, city, etc in your signing certificate.

I looked at multiple guides to come up with my “quick and dirty” process, and I’ll put all the links in a separate section at the end of this post, but for creating (and signing) the certificates, I found that the Easy-RSA page on the Archlinux wiki was the most helpful. You may want to use SHA512 instead of the default SHA256, or elliptic curves (or Twisted Edwards curve) instead of RSA, and they tell you how. I haven’t tried though, since as I wrote earlier I had issue with my Easy-RSA setup, including finding/placing its configuration file(s).
If using RSA, you may also want to use a 4096 bits key instead of 2048, and same for the Diffie-Hellman (DH) prime number of your DH parameters file.

Keys and certificates

To save time, and also because I only had one machine to trash anyway, I generated all the keys on the same machine: the Certificate Authority (CA), the OpenVPN server, the OpenVPN client.
In an ideal configuration, you’ll want to keep the CA private key on a separate machine (maybe even offline, why not, you’re the one doing it in hard mode), and keep the OpenVPN server private key on the machine that will run the server, and ditto for the client private key. And to sign, you’ll generate requests (the .req files) on the machines where the private keys are, then transfer these request files to the CA machine, sign them there, then transfer the signed certificates (.crt files) back the the appropriate machine. Not really complicated, but more tedious than doing everything in the same place, isn’t it?

Generating the client profile

Not that much here, ovpngen is a simple tool, for once, where all options are specified with command line arguments. Compared to what I put in the guide, you also have 2 additional, optional arguments : port number and protocol (default is 1194, which matches the default port for the OpenVPN server).
The generated configuration file is just a text file that concatenates certificates and parameters, so you can easily edit it later, either to change something or add more parameters.

Configuring OpenVPN on the server

Some of the things you configure here will have to be reflected in the client configuration, for instance, obviously, the port and protocol (UDP vs TCP).

The sample configuration file is quite well-made, with many comments that should make it rather self-explanatory for most fields. Something you might want to change in particular is the default DNS servers, as OpenDNS is, unlike the name suggests, not quite “open”. They’ve even censored domains they didn’t like in the past, something that is usually done by ISPs and a motivation to switch from your ISP’s DNS to “some other DNS” like OpenDNS, not something you expect from the latter, and yet…

Other possibly interesting things, at first glance: the keepalive settings, the cipher, maybe enable compression too (unless you have more CPU issues than bandwidth issues), the log file verbosity.

Tweaking the server’s networking parameters

I don’t have much do say about this part, except that it’s some wicked mysterious voodoo which should convince any sensible person that the VPN technology was never meant to primarily be a proxy. And yet that’s the mainstream usage these days (NordVPN, Cyberghost VPN, Surfshark VPN, etc, etc). Go figure 🤷

2 tutorials were of great help for this, this one from DigitalOcean, in particular to find the name of my network interface, and this one from an obscure web host I had never heard of before (MonoVM), for the magic iptables command. I’m really not a fan of their verbiage, though (“With this command, you’re staking your claim in the digital realm, preparing to issue certificates like a digital monarch” … are you high or what? :s)

I guess that now is a good place to repeat that a SOCKS proxy with an SSH tunnel is so much easier. You don’t have anything to configure on the server at all, as long as you’re able to connect via SSH (something that you’d better be able to do if you want to do anything at all with your server, meaning that generally it’s just a given).

That’s about it for my constructive comments. I thought I had more, maybe I already forgot them. Onto more rambling, if you wish (and the promised links are, as promised, at the very bottom).

Even more off-topic “bonus”: what happened to that crappy VPS in the end

TL;DR: I got a refund.

While I was still writing this post, I took the time to run a home-made “benchmark”. Simply, in the evening I started a slow AV1 encoding process on several machines (using ffmpeg with libaom-av1), and when I got up I compared progresses. The results were as clear-cut as it gets:
– the old Ionos VPS (1.2€/month, yes it’s cheap): 1179 frames (yup, that lib is slow, at least with its default settings) (a day and a half later: 4875)
– the new Ionos VPS (1.2€/month too): 521 frames, so around 55% slower… proof that new or “progress” doesn’t necessarily mean better (a day and a half later: 1531 so even 68% slower)
– just for fun, some other OVH VPS (3.84€/month) : 1055 frames, so the old and cheap Ionos VPS does provide good value, CPU-wise (it has 4 times less RAM and half the disk space of this one though, so the price difference does have reasons). This particular VPS was also running a web crawler (MJ12node), so obviously this must have affected (note how I don’t say “impacted” because I’m not a retard) performance.
The cpuinfo of that last VPS is below. Fairly close to the old Ionos it seems.

cpu family      : 6
model           : 60
model name      : Intel Core Processor (Haswell, no TSX)
stepping        : 1
microcode       : 0x1
cpu MHz         : 2394.454
cache size      : 16384 KB

I also ran the “benchmark” on my laptop, but forgot to write down the exact number. It was around 4000. Note that all the VPSs are single core while my laptop obviously isn’t, however that encoding is very poorly multi-threaded (at least with the default settings), so I’d say it used barely a core and a half (in all this, I talk about logical cores since everything here uses HT or SMT). I also had quite a bit of stuff running at the same time and configured my CPU with a very low power (15W total), so roughly I could increase that to 60W and have the same power per used core (but a lot more cooling needs).

So the 2 fast VPS run around 60% slower (1100/(4000/1.5)), per core, as my laptop. Which I guess is not too horrible given their price and that my laptop is quite recent (Ryzen 6800H).

The slow new VPS, though, is 80% slower, which is getting quite bad, particularly considering it’s the newest of all (the offer started in summer 2023). That new VPS also had worse network speed than the old one, even though it was supposed to be faster in that respect (1Gbps vs 400Mbps, the reality was more 200Mbps vs 350Mbps…)

So a week after getting it, I eventually used my right of withdrawal to cancel the 1 year contract. Ionos was very fast and processed my request in less than 20 minutes (I sent an e-mail and they called back), so nothing to complain about, they do have a very available customer service and I certainly wish my banks were so easy to reach.
Maybe just a little negative detail, is that they filed it under their 30-days money-back guarantee instead of the right of withdrawal, which could have implications should I need to cancel a similar bad surprise in the future (right of withdrawal applies all the time but for 14 days only, their money-back guarantee applies for 30 days but only once ever per customer, according to their ToS). Not that I plan to use it again, as it’s never pleasant to invest time on a new server only to drop it because it’s too bad… but it’s even worse if you then get stuck paying for that zombie server for a year 🤔

That was definitely too long

I should write a novel
… oh wait, I just did!

Bibliography

As promised, my sources, in no particular order (although I tried to put the most interesting guides at the top):

• Easy-RSA on the Archlinux wiki
• OpenVPN on the Archlinux wiki: ovpngen – the rest of the guide seems nice too, but I didn’t use it
• How To Set Up an OpenVPN Server on Debian 11 – beside the networking part, I found it helpful for the systemctl commands (systemctl start, status, enable)
• How to install OpenVPN on VPS?
• How to Install and Configure OpenVPN Server on Ubuntu 20.04
• How To Install easy-rsa on Debian 12 – frankly this one was only interesting for some explanations on apt-get commands like autoremove, purge, etc. The easy-rsa that I installed and reinstalled and reinstalled again from the horrible package manager has always refused to work, otherwise. What a brilliant system. But eh, people say that’s one of the great strengths of Linux, and Microsoft is trying to copy it a bit. It’s a mad world.
• How to Install OpenVPN on a Cloud VPS
• easy-rsa on Github
• ovpngen on Github
• How to restart openvpn service (or any service) running under “nobody” user?