openvpn_inc wrote: ↑Wed Aug 04, 2021 8:49 am
I am sorry, we have not observed this problem in any of our tests. There may be something unique to your setup that is causing this error.
It turns out, you are right! It appears OpenVPN Access Server in HA fail-over mode is only tested to work after an upgraded if this hidden gem is followed:
https://openvpn.net/vpn-server-resource ... r-updated/
That isn't the order I followed and isn't the order than can be guarantee to be followed if the update is applied via a cronjob either.
Part of the problem is following the initial install instructions provided here:
https://openvpn.net/vpn-software-packages/
When installing via a repository which is option 1, the packages such as-repo-centos7.rpm, as-repo-centos8.rpm, as-repo-redhat7.rpm, etc. install the repo file with "enabled=1" which means the updates will be applied in whatever order the cron runs in if yum-cron is installed.
Now consider what happens when a novice (or even experienced) user follows these instructions:
https://openvpn.net/access-server-manua ... -failover/
By following the instructions, the "enabled=1" is never changed. There is nothing that automatically disables it and the instructions do not indicate the manually disable it. In fact, the "Configuration: Failover" document does not even reference the knowledgebase article on "proper" upgrade order or procedure.
But that /should/ still be ok, the openvpn-as RPMs themselves have a pre-install script.
You can see it by doing this:
Code: Select all
rpm --scripts -qp openvpn-as-2.9.3_ed03d859-CentOS7.x86_64.rpm
If there is a specific upgrade order, it can be enforced by the pre-install script ... right??
Well, it appears the answer is *NO*. Both nodes have configuration information to SSH into their partner could confirm the partner's version status or checking if the partner status is up or down. Yet, there is no attempt at all in the pre-install script to enforce an upgrade order/procedure or to even warn the user of the fail-over configuration that one exists!
As a "fun" side note, the hidden gem KB document I link to above also says this:
"This is done with a method called UCARP using VRRP heartbeat network packets."
This is technically incorrect. If you want to use VRRP on Linux, the most common way is to use keepalived. uCARP implements CARP instead which is by design *NOT* VRRP. If you spend some time with wireshark, you can see that CARP is not the same as VRRP.
The OpenBSD group that authored CARP even wrote a song poking fun at Cisco and the IETF which explains why they do not use VRRP. The song is available here:
https://www.openbsd.org/lyrics.html#35
The fact it is technically incorrect is not just a fun little factoid either. Older router firmwares may crash when VRRP is enabled on the same VLAN that also contains CARP packets.
Anyways, I would love to try to help get the product improved by working with OpenVPN AS support, but after these last 6 months I am just completely burned out. OpenVPN AS support has not exactly been honest with me. My expectation is they are going to completely miss my point about the RPM pre-install script and chalk this up to either being a "corner case" or "user error" since I didn't follow the hidden gem.
And to be frank, if it is critical users follow a hidden gem manual procedure the software can neither automatically enforce or issue warnings for, why even have a product with a web interface? The existence of this unenforced hidden gem seem to indicate the target audience for the product can not be a novice user. If OpenVPN AS users have to be advanced enough to hunt down a KB article that is never reference in the install procedure, shouldn't they also be advanced enough to use EasyRSA and configure OpenVPN themselves?
At this point, I will contact OpenVPN AS support when my frustration level dropped enough for me to deal with them.