Troubleshooting problems with software licensing

Troubleshoot Access Server license keys (BYOL)

All license keys sold for OpenVPN Access Server using the BYOL licensing system are single-activation and lock to the hardware and software properties that you installed the license key on. One of the more common reasons why a license key suddenly disappears is when the license key has simply expired. License keys you purchase from us have an expiration date. After that date, the license key will disappear and no longer unlock any additional allowed connections on your Access Server.

If you are using an Amazon AMI with a prelicensed amount of connections skip this section and check the Amazon AMI licensing troubleshooting instead.

Another common reason is that recent maintenance on your server has caused the hardware/software combination to change significantly enough for the licensing system to believe it is now running on a different server than the one the license key was originally activated on. This is our copy-protection system that prevents a license key from being used more than once. Even if you are using the OpenVPN Access Server on a virtual platform, moving the virtual machine from one hypervisor platform to another can cause the licensing system to see this hardware change and invalidate the license key. If you for example replace the network interface card on your server or perform a clean reinstall of your server operating system this can cause the license key to become invalid.

One other known cause of problems is if the operating system has run out of all available memory. This can happen on systems with very little memory or with a fairly large user base. One of the first things to go then is the licensing system. It's easy to rule this out as a cause; reboot the server. If the issue persists then try the next step.

You can use the command line licensing manager program to view the current state of the licensing system. On the command line as the root user you can use the commands below to see which license keys are on your system and which of them are having problems, and why, and how many connections your server is currently licensed for.

View which license key files are present on your server's file system:

ls -la /usr/local/openvpn_as/etc/licenses/

Check the license manager tool to see any problems and how many connections your server is licensed for now:

/usr/local/openvpn_as/scripts/liman info

A sample output could look like this:

Manager: exception with license file /usr/local/openvpn_as/etc/licenses/ABCD-1234-EFGH-5678.lic:
 machine properties validation failed: verify fail: ABCD-1234-EFGH-5678 
 [3:0:8]/mac=110/hd=000/cpu=110/pci=110/ino=110/iid=000 (LIC_VPROP)

Manager: exception with license file /usr/local/openvpn_as/etc/licenses/IJKL-0912-MNOP-3456.lic:
 license key ID is expired (LIC_KEY_EXP)

Manager: exception with license file /usr/local/openvpn_as/etc/licenses/QRST-7890-UVWX-1234.lic:
 signature verification failed (LIC_VERIFY)

INFO {'apc': False, 'concurrent_connections': 20}

As can be seen in the output above the license key ABCD-1234-EFGH-5678 fails the machine properties validation. This means that the hardware specifics of the system that this license key was activated on are no longer the same as the system it is currently trying to run on. The system then considers this license key invalid and skips it. Also visible in the output above is the license key IJKL-0912-MNOP-3456 which shows that it is expired. This means that this license key's expiration date has been reached and it is no longer valid for use. If you haven't renewed this key, you can do so on our website, or just buy a new license key. You'll then get a new license key that you can activate on your OpenVPN Access Server and it will then be licensed again. The last line in the output above shows that right now this server is registered for 20 simultaneous connections.

If your license key is not expired and shows the machine properties validation failed message while you believe this key should be valid for this system, and this key isn't in use on another system, contact us on our support ticket system and explain the problem you are seeing and mention the license key that you are having a problem with. We can then revoke the current key and issue a new replacement key.

If your license key shows the signature verification failed message, it means that the file itself is corrupt somehow. We rarely encounter this since the activation system is normally automatic and manages itself, and as such corruption to these files is not going to happen by Access Server itself. But if the file system is damaged or if these files are manually transferred from somewhere to this server, and something has gone wrong in this process, then it could explain why the file is corrupted. If you for example did an offline activation procedure and copied this file onto this server, try obtaining a new copy of the file and trying again. Avoid copying and pasting the contents of the file and instead use a tool like SCP or WinSCP. If you received the file as an email attachment try obtaining it via another method, for example if you requested us to do an offline activation, try logging in to the support ticket system website directly and downloading the file there, and even try another browser in case that still fails.

License key activation troubleshooting

It is reasonably rare but license key activation errors can occur, and this is usually a problem with the environment the Access Server is running on. When you activate a license key via the Admin UI, or activate a license key via the command line, it is sent to our license activation system on the Internet. If that connection is not possible for whatever reason, then activation will fail. Also, if the license key has already been used before for activation, then it will also fail. If you want to move a license key from one server to another, contact us and request a license key reissue.

Activation occurs online. License keys are activated by communicating with our licensing server at licensing.openvpn.net or licserv.openvpn.net on port TCP 443. It is not possible to do activation through a proxy server. It must be done directly. If you have a firewall that blocks traffic, kindly make an exception for this server and port. The IP is reasonably static, we haven't changed it in years. But it could theoretically change in the future, although we do not expect this to happen anytime soon. The IP address is 54.183.149.72.

If you activate a license key and you see the message Fault 9000: "twisted.internet.error.DNSLookupError: DNS lookup failed: address 'licensing.openvpn.net' not found: [Errno -2] Name or service not known." then you're definitely dealing with a DNS issue. This can for example be caused by not having DNS servers configured, or the ones that are configured, are internal DNS servers that only handle an internal DNS zone and don't have a clue about outside zones on the Internet. It could even be a temporary problem with the DNS server.

If you activate a license key and you see the message SESSION ERROR: SESSION: Your session has expired, please reauthenticate (9007) or then one of the most likely explanations is that either the DNS settings are still somehow wrong in the operating system that the Access Server is installed on, or that Internet access to the licensing server was not possible for some reason or another. Now if you know for a fact that your Access Server does not have Internet access, and will not get any Internet access either, because that's how you set things up and that's your intention, then you can skip ahead and look at the offline activation steps since the troubleshooting steps below won't be able to fix your issue.

If you activate a license key and you see the message <Fault 9000: "OpenSSL.SSL.Error: [('SSL routines', 'ssl3_get_server_certificate', 'certificate verify failed')]"> then for some reason the secure connection between your Access Server and our licensing server is failing. A possible explanation could be a firewall or proxy system that intercepts the traffic and presents its own SSL certificate. This won't match with the certificate that the Access Server is expecting to see and so the verification of the certificate fails. Another possibility is that your server's time and date are off quite badly. The certificate we use on our licensing server is valid within specific dates, and if your server has a date set that is wildly off, then the verification fails. To correct such a problem set the date correctly and consider installing an NTP client. The commands below assume you are root on a Debian/Ubuntu type server:

Check the current date setting:

timedatectl

If the timezone is wrong, correct it:

dpkg-reconfigure tzdata

If the date or time are wrong, correct it:

date --set="25 DEC 2018 20:10:00"

If you don't have a network time protocol client, install one:

apt-get update
apt-get install ntp

Now if your Access Server does have Internet access, and the date and time are correct, and you're sure your key has not already been activated before (you can check this on our website in your licensing overview) but you still can't activate your license key then continue with the troubleshooting steps. One of the first things to check is if you can ping a public address like google.com from the Access Server's operating system. So log on to the console or an SSH session to the Access Server and obtain root privileges.

Ping google.com:

ping -w 1 google.com

You should be seeing a result like this:

PING www.google.com (216.58.211.100) 56(84) bytes of data.
64 bytes from ams15s32-in-f4.1e100.net (216.58.211.100): icmp_seq=1 ttl=56 time=7.37 ms

--- www.google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 7.376/7.376/7.376/0.000 ms

If you're not seeing it resolve the address to an IP address, then your DNS server settings need work. If you are seeing it resolve but you get 100% packet loss and no ping reply then the issue could be related to Internet connectivity. Like for example a bad gateway setting or a firewall blocking Internet access. To solve a problem with the DNS servers you could edit the /etc/resolv.conf file and put a DNS server address in there manually. But doing that when your server is set for a dynamically obtained IP address (DHCP) will mean that it gets reset every time your DHCP client program in your operating system retrieves new DNS server information. So if you use DHCP you may want to switch to setting a static IP address on your Access Server and then editing the file /etc/resolv.conf to set a proper DNS address.

If you don't know a DNS server to use, you can use Google's public DNS servers like 8.8.8.8 and 8.8.4.4. To configure this in the resolv.conf file open the file in a text editor and make changes to it.

Edit /etc/resolv.conf in nano text editor:

nano /etc/resolv.conf

Find any lines that start with "nameserver" and change them to look like this (if none exist, add them):

nameserver 8.8.8.8
nameserver 8.8.4.4

Press ctrl+x, then press y, and then press enter, to save and exit the file.

The changes should take effect immediately. Test again if you can now ping www.google.com. If you now can and previously you couldn't then it seems your DNS problem is now resolved. You can now attempt activation of the license key. If it still not resolved there is one final thing you can try. Some providers, especially in a country like China, do DNS poisoning, which results in false IP address results for a DNS query, thus blocking the activation process. By editing the local hosts file, which is a file with host names and IP addresses that will be referenced before asking a DNS server, it is possible to manually specify which IP address to use when contacting our licensing server. To do so follow the commands below.

Edit /etc/hosts in nano text editor:

nano /etc/hosts

Go to the bottom of the file and add this line:

54.183.149.72        licserv.openvpn.net licensing.openvpn.net

Press ctrl+x, then press y, and then press enter, to save and exit the file.

You can now attempt activation of the license key again.

As one of the final steps to try, you should try to activate the license key via the command line:

/usr/local/openvpn_as/scripts/liman activate "LICE-NSEK-EYIN-HERE"

If you activate a license key via the command line method, and you see the message unable to get local issuer certificate followed by a subject name of the certificate that is different from the expected name OpenVPN Licensing CA then you have some sort of a firewall or proxy server between your Access Server and our licensing system that is intercepting or blocking the traffic, and may be trying to show an error message relating to this blockade. Try the following command to determine if your Access Server can reach the licensing system:

wget -O- -q --no-check-certificate https://licensing.openvpn.net/ | grep "XML_PARSE"

You should be seeing this expected output:

<value><string>XML_PARSE: error parsing XML</string></value>

If you didn't see this, try this instead:

wget -O- --no-check-certificate https://licensing.openvpn.net/

If you now see HTML code that starts with <HTML> <HEAD> and so on, you are looking at a webpage that is not generated by our licensing system, but by some system standing in the way between your Access Server and our licensing system, most likely a local firewall system that blocks proxies/anonymizers. Since OpenVPN Access Server could be considered to fall in such a category, you may need to go into the settings of your local firewall system and lift that restriction so Access Server can function normally. If you receive some error message, for some other unknown reason, the licensing system is not reachable from your Access Server.

Cisco's Umbrella solution has the categories Proxy/Anonymizer and Software/Technology that the entire openvpn.net domains falls under. If you have that solution set to block those categories, then please unblock them or manually add the hosts entries to your hosts file to bypass the restriction, since this is most commonly only a DNS-based poisoning/redirection and not a DPI-based blockade.

If you have not been able to activate your license key with the steps above, consider doing an offline activation. The offline activation procedure is explained below. You can also contact us and explain your situation by contacting us on our support ticket system.

Offline BYOL license activation procedure

In the event that an offline activation is impossible, either due to very strict firewalls that you have no control over, or because of the fact that the Access Server installation is located in a purely local network without any Internet access, then an offline activation may be done instead. There are two possibilities. You can either do the offline activation yourself using a second (temporary) Access Server installation that does have a connection to the Internet, or you can relay the required hardware information file to us through our support ticket system, together with the license key you want to activate, and let us do the offline activation for you. After the offline activation procedure you will end up with an activated xxxx-xxxx-xxxx-xxxx.lic file which must be placed back on your server for the license key activation procedure to be completed.

Option 1: using a (temporary) Access Server installation with normal Internet access
The activation process reads a number of unique machine facts from the system that your Access Server is installed on, and uses it together with your license key to activate and lock the license key to your system. It unlocks the amount of connections that your license key is good for, and locks it to the system you activated the license key on. With an offline activation procedure, we take the machine facts from one offline (no Internet access) Access Server, export it to a text file, and copy that text file to another online (with Internet access) Access Server, and then use that Access Server to do to the activation process. The resulting license file can then be copied back to the original machine and will work there. The procedure below describes how to do this:

  • Log on to the Access Server that you wish to activate, let's call this the production server. We'll need the hardware specifics from this server.
  • Run this command on the production server as root user:
    /usr/local/openvpn_as/scripts/liman id-marker >licinfo.txt
  • licinfo.txt is a text file that now contains the hardware specifics for that production server that needs to be activated.
  • Copy this file to an Access Server that has access to our licensing server, let's call this the activation server.
    Please make sure you do not copy/paste the contents of the file, but use a tool like SCP or WinSCP to actually transfer the file itself.
  • Run this command on the activation server as root user:
    /usr/local/openvpn_as/scripts/liman -i licinfo.txt Activate "LICE-NSEK-EYIN-HERE"
  • Go to the /usr/local/openvpn_as/etc/licenses/ folder and copy the file LICE-NSEK-EYIN-HERE.lic file from the activation server to the production server.
    Again, please make sure you do not copy/paste the contents of the file, but use a tool like SCP or WinSCP to actually transfer the file itself.
  • The production server should now see the activated key and update the concurrent connection count.
    In rare cases you may need to use service openvpnas restart to restart the Access Server service to read the new license key.

Option 2: request us to do the offline activation for you with your licinfo.txt file
If you do not have the opportunity to set up a second Access Server purely for the activation steps, then you may also contact us on our support ticket system and explain that you need an offline activation. Please be sure that you provide us with the file licinfo.txt as an attachment to the support ticket, along with the license key that you wish to activate on your server. We can then take care of your request. You will need to follow the steps below to obtain the licinfo.txt file that we will need:

  • Log on to the Access Server that you wish to activate, let's call this the production server. We'll need the hardware specifics from this server.
  • Run this command on the production server as root user:
    /usr/local/openvpn_as/scripts/liman id-marker >licinfo.txt
  • licinfo.txt is a text file that now contains the hardware specifics for that production server that needs to be activated.
  • Copy this file to your computer that you are using to submit a support ticket request, and attach the file to the ticket.
    Please make sure you do not copy/paste the contents of the file, but use a tool like SCP or WinSCP to actually transfer the file itself.

Licensing problems with Amazon AWS tiered instances

If you encounter the problem where an OpenVPN Access Server with x amount of connected devices using the Amazon AWS tiered instance licensing model is showing you that your server is only licensed for 2 connections, while you launched an instance for "xx connected devices", then the most likely explanation here is that you are using a security group on this instance that is blocking access to the licensing servers. If that happens the OpenVPN Access Server cannot check to see if you are licensed and will fall back to its automatic built-in demonstration mode which allows all functionality without time limit, but allows only 2 simultaneous VPN connections.

Please note that this is not the same licensing system as the BYOL licensing model that uses separate license keys for activation. For that we have a separate troubleshooting section for BYOL licensing above on this page. If you have launched an Amazon AMI that has in its title "xx connected devices" then you are indeed using the Amazon AWS tiered instance licensing model and you should investigate why your system is not getting access to the licensing systems. These are the addresses that the licensing system will need contact to for the tiered instances to verify the licensed state and unlock the amount of connections stated on the OpenVPN Access Server AWS tiered instance type:

IP address 169.254.169.254, port 80:
http://169.254.169.254/latest/meta-data/

These DNS names with wide dynamic IP ranges, on port TCP 443:
awspc1.openvpn.net
awspc2.openvpn.net

And these DNS names with static IP addresses, on port TCP 443:
awspc3.openvpn.net, IP address: 107.191.99.82
awspc4.openvpn.net, IP address: 107.161.19.201

Important note: awspc3.openvpn.net and awspc4.openvpn.net are only supported as of Access Server 2.5. Previous versions only use awspc1 and awspc2.

If you are strict on your security permissions, then you need to release access to the meta data system mentioned above, and at least one of the two static IP addresses of awspc3 or awspc4 mentioned above. The licensing system in the Access Server is designed to try a specific licensing server first, and if that fails, move on to the next, and so on, until all 4 addresses have been tried. As a result, if you only unblock for example awspc4 then it may be a minute or two before it picks up the license after the server has just started up, so please be patient.

For those curious, awspc3 will be tried first, then 2, then 4, then 1.

If you have unblocked these addresses, and are still experiencing problems, we recommend first temporarily unblocking everything on this particular system. To put it simply; to disable anything that can possibly block any type of connections. Be sure to check both iptables firewalls and security groups in Amazon, both of these can block traffic. The first thing to ensure is that neither of these are possibly blocking the traffic. And of course do a reboot of the system to be sure any transient issues are taken care of. Once this has been done, and there are still issues, then contact us please with any details you can provide so we can investigate the problem.

If it is absolutely required by company policy that no external contact of any kind to the addresses mentioned above must be possible for your AWS instance, then the tiered instances are not suitable as they do need access to at least the meta data server and a licensing server. The BYOL licensing type may be suitable instead in this case if an offline activation is performed and no auto-scaling or instance type alterations are used that alter the virtual hardware and possibly break the locked license of the BYOL license model.

To further investigate the problems with the AWS tiered instances licensing system it can help to activate a special debug flag in as.conf and restarting the Access Server service. The /var/log/openvpnas.log file will then log information specific to the AWS licensing system, and any errors mentioned in there may aid in understanding and fixing what is wrong. Providing such information when you are contacting us for support would be of tremendous help to us in resolving the problem quickly. To enable debugging follow the steps below.

Open as.conf in nano text editor:

nano /usr/local/openvpn_as/etc/as.conf

Go to the bottom of the file and add this line:

DEBUG_AWSINFO=1

Now restart the Access Server service so that the changes can take effect:

service openvpnas restart

After reboot run this command to filter for the words "AWS INFO" in the log file:

cat /var/log/openvpnas.log | grep -i "AWS INFO"

If you see lines like these in /var/log/openvpnas.log, the meta data server was unreachable:

2017-10-04 19:32:30+0200 [Uninitialized] AWS INFO: error getting instance info 'doc': : An error occurred while connecting: 113: No route to host. (twisted.internet.error.ConnectError)
2017-10-04 19:32:30+0200 [Uninitialized] AWS INFO: error getting instance info 'sig': : An error occurred while connecting: 113: No route to host. (twisted.internet.error.ConnectError)
2017-10-04 19:32:30+0200 [Uninitialized] AWS INFO: error getting instance info 'pc': : An error occurred while connecting: 113: No route to host. (twisted.internet.error.ConnectError)
2017-10-04 19:32:30+0200 [Uninitialized] AWS not detected
2017-10-04 19:32:33+0200 [-] AWS INFO: error getting instance ID: 'NoneType' object has no attribute '__getitem__': aws/info:271 (exceptions.TypeError)
2017-10-04 19:32:33+0200 [-] AWS INFO: error getting instance ID: 'NoneType' object has no attribute '__getitem__': aws/info:271 (exceptions.TypeError)

You should be seeing a fair amount of debug information. You can attempt to make sense of this yourself or send it to us on the support ticket system so we can analyze it for you.