Not the person you replied to, but I’m in agreement with them. I did tech hiring for some years for junior roles, and it was quite common to see applicants with a complete alphabet soup of certifications. More often than not, these cert-heavy applicants would show a complete lack of ability to apply that knowledge. For example they might have a network cert of some kind, yet were unable to competently answer a basic hypothetical like “what steps would you take to diagnose a network connection issue?” I suspect a lot of these applicants crammed for their many certifications, memorized known answers to typical questions, but never actually made any effort to put the knowledge to work. There’s nothing inherently wrong with certifications, but from past experience I’m always wary when I see a CV that’s heavy on certs but light on experience (which could be work experience or school or personal projects).

However, it’s worth mentioning that WireGuard is UDP only.

That’s a very good point, which I completely overlooked.

If you want something that “just works” under all conditions, then you’re looking at OpenVPN. Bonus, if you want to marginally improve the chance that everything just works, even in the most restrictive places (like hotel wifi), have your VPN used port 443 for TCP and 53 for UDP. These are the most heavily used ports for web and DNS. Meaning you VPN traffic will just “blend in” with normal internet noise (disclaimer: yes, deep packet inspection exists, but rustic hotel wifi’s aren’t going to be using it ;)

Also good advice. In my case the VPN runs on my home server, there are no UDP restrictions of any kind on my home network and WireGuard is great in that scenario. For a mobile VPN solution where the network is not under your control and could be locked down in any number of ways, you’re definitely right that OpenVPN will be much more reliable when configured as you suggest.

I use WireGuard personally. OpenVPN has been around a long time, and is very configurable. That can be a benefit if you need some specific configuration, but it can also mean more opportunities to configure your connection in a less-secure way (e.g. selecting on older, less strong encryption algorithm). WireGuard is much newer and supports fewer options. For example it only does one encryption algorithm, but it’s one of the latest and most secure. WireGuard also tends to have faster transfer speeds, I believe because many of OpenVPN’s design choices were made long ago. Those design choices made sense for the processors available at the time, but simply aren’t as performant on modern multi core CPUs. WireGuard’s more recent design does a better job of taking advantage of modern processors so it tends to win speed benchmarks by a significant margin. That’s the primary reason I went with WireGuard.

In terms of vulnerabilities, it’s tough to say which is better. OpenVPN has the longer track record of course, but its code base is an order of magnitude larger than WireGuard’s. More eyes have been looking at OpenVPN’s code for more time, but there’s more than 10x more OpenVPN code to look at. My personal feeling is that a leaner codebase is generally better for security, simply because there’s fewer lines of code in which vulnerabilities can lurk.

If you do opt for OpenVPN, I believe UDP is generally better for performance. TCP support is mainly there for scenarios where UDP is blocked, or on dodgy connections where TCP’s more proactive handling of dropped packets can reduce the time before a lost packet gets retransmitted.

It’s likely CentOS 7.9, which was released in Nov. 2020 and shipped with kernel version 3.10.0-1160. It’s not completely ridiculous for a one year old POS systems to have a four year old OS. Design for those systems probably started a few years ago, when CentOS 7.9 was relatively recent. For an embedded system the bias would have been toward an established and mature OS, and CentOS 8.x was likely considered “too new” at the time they were speccing these systems. Remotely upgrading between major releases would not be advisable in an embedded system. The RHEL/CentOS in-place upgrade story is… not great. There was zero support for in-place upgrade until RHEL/CentOS 7, and it’s still considered “at your own risk” (source).