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)

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.

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

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 (UNFINISHED MARKER) since the troubleshooting steps below won't be able to fix your issue.

Now if your Access Server does have Internet access, and you're sure your key has not already been activated before (you can check this on our website in your licensing overview) 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 (UNFINISHED MARKER) 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 fails, contact us on our support ticket system and explain your situation, or consider doing an offline activation. (UNFINISHED MARKER)

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 will only be 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 awspc1 first, and if that fails, move on to awspc2, and so on until all 4 addresses have been tried. As a result, if you only unblock awspc4 then it may be a few minutes 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.