OpenVPN Support Forum

We have a CARP pair set up in the event of a failover. When trying to activate the license key on the backup access server I got the following error:

ERROR: --sock parameter (u'/usr/local/openvpn_as/etc/sock/sagent.localroot', u'/usr/local/openvpn_as/etc/sock/sagent') doesn't point to active socket: util/options:79,sagent/sacli:537,sagent/sacli:310,<string>:1,sagent/sagent_entry:49,sagent/sacli:1274,util/options:79,sagent/sacli:537,sagent/sacli:310,util/error:74,util/error:55

Any ideas why I am unable to activate the key on this server via command line?

When using fixed licensing, you must open a support request to be assigned another unique fail-over license that is paired with the primary license.

Once you get the secondary server's unique license, you must use "liman" instead of "sacli" to apply the secondary server's license.

The reason for this is that "sacli" only works by connecting to the OpenVPN Access Server's API socket of which there is none on the secondary server. In the case of fail-over (unlike cluster mode), the AS service only runs on one server at a time. It is up to the uCARP daemon to bring the service AS service on failure of the primary node. Otherwise the secondary server is only running uCARPd without the rest of the services.

Unlike sacli, the liman script works on performing licensing management directly instead of indirectly through the service API. Hence, liman has no dependencies on the AS services running to work.

More information on liman is available here:
https://openvpn.net/vpn-server-resource ... ss-server/

Hello ctrl1122 and chilinux,

Yes, the above is true if you're still using fixed license keys. But now we offer the subscription licensing model. With that you activate the primary node. During normal operations this information gets copied to the secondary node, so that when the secondary node goes online during a failover event, it will use that same subscription. In effect both nodes are licensed the same way automatically - no additional actions needs.

We're moving away from providing failover keys for failover setups since the subscription model already covers this use-case.

Kind regards,
Johan

Thank you both for your replies. I was trying to activate a subscription license on our secondary node which was likely failing due to already being included in the failover. I wasn't sure if the secondary node auto activated as it doesn't show up on our account when it's "inactive". Issue resolved.

openvpn_inc wrote: ↑

Tue Jul 13, 2021 8:20 am

Hello ctrl1122 and chilinux,

Yes, the above is true if you're still using fixed license keys. But now we offer the subscription licensing model. With that you activate the primary node. During normal operations this information gets copied to the secondary node, so that when the secondary node goes online during a failover event, it will use that same subscription. In effect both nodes are licensed the same way automatically - no additional actions needs.

We're moving away from providing failover keys for failover setups since the subscription model already covers this use-case.

Kind regards,
Johan

Hopefully the bugs with the subscription model related to failover setups can be addressed first. It has been 5 months and OpenVPN AS support still has no solid update on when it should be fixed. It also still isn't even acknowledged in the release notes or knowledge base yet.

The fixed license key system has a proven track record and has worked well in comparison for a long time.

Hello chilinux,

When a subscription is activated on a primary node, and the configuration is allowed some time to copy to the failover node, the failover node will use the subscription when a failover event occurs. This is part of our QA process and is known to be working correctly. It is in fact the recommended way and a perfect use case for subscriptions.

Maybe there are corner cases or situations in which it might not work. If you have encountered such a case, I would appreciate you letting me know the ticket ID so that I can actually look into this case.

Kind regards,
Johan

openvpn_inc wrote: ↑

Tue Jul 13, 2021 6:31 pm

Hello chilinux,

When a subscription is activated on a primary node, and the configuration is allowed some time to copy to the failover node, the failover node will use the subscription when a failover event occurs. This is part of our QA process and is known to be working correctly. It is in fact the recommended way and a perfect use case for subscriptions.

Maybe there are corner cases or situations in which it might not work. If you have encountered such a case, I would appreciate you letting me know the ticket ID so that I can actually look into this case.

Kind regards,
Johan

The subscription license bug is explained in more detail in ticket #371953.

Again, the issue has been left unresolved for 5 months. Also the problem can be recreated with OpenVPN AS version 2.9.2.

If this continued on to 6 months without a solution, I was going to request our account manager switch us back to fixed licenses. Now that I know plans are moving forward with removing that option despite not having fixed the subscription license bug, I will start looking at alternative products.

This news of killing fixed license option is both alarming and extremely disappointing.

Hello chilinux,

You may switch back to fixed license key at any time. I never said we're getting rid of fixed license keys. However, the free failover keys for a failover setup is something that we are moving away from. We have subscriptions now and that fits the use case perfectly.

The case you have reported is a corner case. We don't report corner cases on the known issues overview.

However, we are still going to fix it. We recently released 2.9 which is a huge release that converts the whole program from Python2 to Python3. We have finished this and are now in a fast release cycle with releases coming about every 2 weeks or so to address any reported issues, including this one. We have it in our scope for a minor release of 2.9 to address the issue you reported.

Kind regards,
Johan

openvpn_inc wrote: ↑

Wed Jul 14, 2021 5:26 am

Hello chilinux,

You may switch back to fixed license key at any time. I never said we're getting rid of fixed license keys. However, the free failover keys for a failover setup is something that we are moving away from. We have subscriptions now and that fits the use case perfectly.

It seem like more of an imperfect fit when a known bug causes part of the documented subscription support to fail to work as document.

I guess we may need to agree to disagree on what perfectly means.

openvpn_inc wrote: ↑

Wed Jul 14, 2021 5:26 am

The case you have reported is a corner case. We don't report corner cases on the known issues overview.

I think you are missing how this sounds from a customer perspective.

When we ask an account manager if subscription mode functions a specific way, we were asking because it is a main use case for us.

There is nothing publicly available to indicate what we ask for is a "corner case." We had every reason to believe the information given to us by the account manager was to apply to the version currently shipping 5 months ago. Or that if there was a bug that it would be a full case entitled to full support instead of a "corner case" entitled to 5+ month support. It seems somewhat arbitrary to designate things a "corner case" after the fact and that falls short from being transparent.

openvpn_inc wrote: ↑

Wed Jul 14, 2021 5:26 am

However, we are still going to fix it.

Yes, I know. That part has been reiterated for the last 5 months. The if part was never in question, the when or amount of progress has been.

openvpn_inc wrote: ↑

Wed Jul 14, 2021 5:26 am

We recently released 2.9 which is a huge release that converts the whole program from Python2 to Python3. We have finished this and are now in a fast release cycle with releases coming about every 2 weeks or so to address any reported issues, including this one. We have it in our scope for a minor release of 2.9 to address the issue you reported.

The fact a huge release coming up requiring the bug to remain unresolved for an extended period was never communicated by OpenVPN AS support. If they had communicated this, it would have better set expectations. Instead what seem to be communicated is we have always been one more release away from a fix (until it is actually been released without the fix). There is only so long support can say to expect a fix soon before it just comes across as dishonest.

Bottom line for me is subscription mode seems to have been rushed out without being fully tested and the entire documented feature set of it does not seem to be fully supported yet. I have a hard time recommending others use it yet. It is my expectation this will improve by the end of the year but it is not at that point today.

Hello chilinux,

We just released Access Server 2.9.3 and I believe this item might address the issue you were experiencing with setting local connection limit on a failover setup:

> Fixed an issue where local_cc_limit setting wouldn't work upon a failover event.
From: https://openvpn.net/vpn-server-resources/release-notes/

Kind regards,
Johan

It killed my secondary node with the following output during upgrade:
Before the upgrade, systemctl showed the Main PID as ucarpd. Now the status on the secondary is:
If the service on the primary node is stopped or the server shutdown, nothing performs a take over of the high-availability IP at this point.

The status on the secondary node remains the same regardless of if the primary is available or not.

The ps listing now always shows a single instance of python3, there is never any ucarp process and never any openvpn-openssl processes. Checking with netstat, the python process is not listening on any ports including port 943.

Is there something more I need to run on the secondary node to restore HA functionality after the upgrade?

HA functionality was working fine before upgrading to 2.9.3.

Hello chilinux,

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 might be possible to solve this if we take a closer look at your configuration. Please contact us at https://openvpn.net/support and send details like ./sacli configquery and /var/log/openvpnas.node.log so we can try to reproduce this problem on our end.

Kind regards,
Johan

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: 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.

I understand your frustration ..