Licensing considerations and preparations
There are a couple of notes that you should take a careful look at before proceeding. Many years ago, license keys were sold of the perpetual type. We no longer sell these. However we do still honor the original terms they were sold under. And one of those terms was that no support or upgrades were allowed when such a license key was purchased and allowed to expire. If you currently are using such an old type license key and an Access Server of version 1.8.4 or older, then when you upgrade to a modern version or you migrate to another system, such a license key will be lost. See also our licensing FAQ page for more information.
All other license keys sold in 2013 and later are all of the standard license key type in the BYOL licensing system and you can safely upgrade and migrate to another installation, but your license key will not work on the new system and you need to contact us for a license key reissue. But it is still important to note that we only provide assistance in solving problems with license keys if the license keys are still actually valid. If they are expired, we cannot help you with those licenses. If the licenses are not expired, we will of course help you in whatever way we can to get them operating on your new Access Server installation. If you have this type of license key, and you most likely do, and it is still valid, then contact us for a license key reissue. You can even do this in advance. If you do this in advance, the old license key will still function for up to 2 weeks without a problem, giving you time to migrate your settings to the new server, test things out, and then finally activate the new key on the server, and work on getting your users on the new server. Normally though you would just update the DNS record at this point and have all users migrate to the new server within a matter of minutes or hours.
If you use our Amazon AWS tiered instances that come prelicensed with a stated amount of “xx connected devices" then you need not worry about licenses at all. That is then taken care of internally by Amazon’s systems that take care of licensing and billing. You can then just set up a new instance and migrate your data there. At the moment if you want to switch from for example a 10 connected devices instance to a 25 connected devices instance on Amazon AWS with our tiered instances, currently the only way to do this is to take a backup of your old instance’s Access Server data, and then restoring it on the new instance, updating the DNS record pointing to your Access Server or reattaching the old elastic IP to the new instance, and then taking the old instance down (to avoid incurring extra costs).
IP address change, DNS record update
If your migration to a new Access Server installation also means you get a new IP address on your server, then first check to see if in the Admin UI in the Network Settings page you have the Host name or IP address field set to a proper FQDN DNS name. For example like vpn.yourcompany.com. If you do, then it’s likely that all your currently installed OpenVPN clients also are using a DNS name to find the server on the Internet. If that’s so, then when you update the DNS record to the new IP address of your new server, then your clients can connect again, once you complete all the necessary steps to migrate your data.
However, if you have installed the Access Server and all your clients while using an IP address only, then when your server changes IP address, none of your clients can connect to the new server. They are preprogrammed to look for the old IP address. Changing the value in the Admin UI after the OpenVPN clients have already been installed will not update this on the already existing client installations. In such a case you should be prepared to reinstall your VPN clients when your server changes IP address.
It is worth noting that an FQDN DNS address is required to get a properly validated and signed SSL certificate installed and working on your Access Server, and we do recommend this.
If you’re on Amazon AWS, and your old server has an Elastic IP, you can just deassociate the Elastic IP from the old instance, and associate it with the new instance, and then you don’t need to update any DNS record or IP settings at all.
Making a backup of the old Access Server
The configuration database files contain all the log reports information, user properties, certificates for VPN connections, certificates for the web interface, and so on. If it becomes lost, then all the currently installed OpenVPN clients are unable to connect to the server. Even reinstalling a server with the same user names and passwords will then simply not have any effect. Every installation of OpenVPN Access Server comes with a unique private key and public key, which are used internally in the certificate management system built into the Access Server to generate unique client certificates. The certificates for one installation of OpenVPN Access Server are not compatible with that of another installation. So in the event of a server crash, if you have a backup of all of the configuration files, you can restore this and get your clients connected again without requiring them all to reinstall their clients or connection profiles. Likewise, with a migration, we are going to restore things in such a way that installed OpenVPN clients can just connect again with the same connection profiles they already have. This assumes of course that you have set up the Access Server with an FQDN DNS name and can update the DNS record to point to the new IP address, or that you can keep the old IP address intact.
With the commands below you can make a backup of all the required information while the OpenVPN Access Server is live. That means you do not need to stop the Access Server service to make a backup file; it can continue running while a backup is made. It goes without saying of course that if anyone gets a hold of these backup files, the security of your VPN system is compromised; it contains all the settings and certificates. So please do pay attention to where you store these backups and how you store them.
Use the commands below with root privileges to make a backup:
cd /usr/local/openvpn_as/etc/db [ -e config.db ]&&../../bin/sqlite3 config.db .dump>../../config.db.bak [ -e certs.db ]&&../../bin/sqlite3 certs.db .dump>../../certs.db.bak [ -e userprop.db ]&&../../bin/sqlite3 userprop.db .dump>../../userprop.db.bak [ -e log.db ]&&../../bin/sqlite3 log.db .dump>../../log.db.bak [ -e config_local.db ]&&../../bin/sqlite3 config_local.db .dump>../../config_local.db.bak [ -e cluster.db ]&&../../bin/sqlite3 cluster.db .dump>../../cluster.db.bak [ -e clusterdb.db ]&&../../bin/sqlite3 clusterdb.db .dump>../../clusterdb.db.bak [ -e notification.db ]&&../../bin/sqlite3 notification.db .dump>../../notification.db.bak cp ../as.conf ../../as.conf.bak
The resulting 5 configuration files (config.db.bak, certs.db.bak, userprop.db, log.db.bak, and as.conf.bak) can be found in the /usr/local/openvpn_as/ directory now and contain everything unique about this OpenVPN Access Server installation. It’s worth noting that with PAM authentication system the passwords are stored in the operating system and these are not backed up with these commands, while with local authentication mode they are stored in these backup files. And with LDAP and RADIUS the passwords are stored in those systems and thus are not involved in the migration process of Access Server – as long as the Access Server can still reach those systems on the new installation it’s fine.
License keys cannot be backed up. As explained earlier on on this page, you need to get a license key reissued by us. We do this upon request on the support ticket system.
Restore backup to the new server
First you have to have set up a new Access Server, of course. After this, log on to the operating system of the new installation and stop the Access Server service. Transfer the backup files from the previous steps from the old server to the new server using SCP, or WinSCP for Windows, and place them in the /usr/local/openvpn_as/ folder where you found them on the old server. Then restore the backup and start the OpenVPN Access Server service again.
Use the commands below with root privileges to restore the backup:
service openvpnas stop cd /usr/local/openvpn_as/ rm ./etc/db/config.db ./etc/db/certs.db ./etc/db/userprop.db ./etc/db/log.db rm ./etc/db/config_local.db ./etc/db/cluster.db ./etc/db/clusterdb.db rm ./etc/db/notification.db ./etc/as.conf [ -e config.db.bak ]&&./bin/sqlite3 <./config.db.bak ./etc/db/config.db [ -e certs.db.bak ]&&./bin/sqlite3 <./certs.db.bak ./etc/db/certs.db [ -e userprop.db.bak ]&&./bin/sqlite3 <./userprop.db.bak ./etc/db/userprop.db [ -e log.db.bak ]&&./bin/sqlite3 <./log.db.bak ./etc/db/log.db [ -e config_local.db.bak ]&&./bin/sqlite3 <./config_local.db.bak ./etc/db/config_local.db [ -e cluster.db.bak ]&&./bin/sqlite3 <./cluster.db.bak ./etc/db/cluster.db [ -e clusterdb.db.bak ]&&./bin/sqlite3 <./clusterdb.db.bak ./etc/db/clusterdb.db [ -e notification.db.bak ]&&./bin/sqlite3 <./notification.db.bak ./etc/db/notification.db [ -e as.conf.bak ]&&cp ./as.conf.bak ./etc/as.conf service openvpnas start
This restores the configuration backup. There are a few caveats to note here:
If you restore a configuration backup to another server, it’s possible that you had your system configured a specific way that doesn’t work on the new server installation anymore. Perhaps the IP address was different on your old server, and perhaps you had chosen to set the Access Server to only listen to a very specific IP address. If that address is then not present on your new installation, the web interface won’t respond because it’s set to listen to an address or interface that doesn’t exist. To resolve this check the section on how to reset the interface and port for the web services to listen on to default settings. Once you have access to the Admin UI again you can reconfigure it to whatever settings you wish. Alternatively you can use the command line tools to configure the web server settings manually.
And finally there is on more thing to check. The configuration database also contains the setting on how many TCP daemons and UDP daemons to launch. If this is set higher than the amount of available CPU cores, the Access Server program may become unstable. So if you have restored this configuration on a different server, and the amount of CPU cores is different from the server the configuration backup came from, you should adjust this as described on the Server Network Settings page in the Admin UI, or use our reset commands for the OpenVPN daemons here.
If you were using an Amazon AMI you can either update the DNS record to point to the new public IP, or, you can move the elastic IP (if you have that – it’s not available for every system on Amazon) to the new server instance. Then you can take the old instance down.
Test with local hosts file
Most operating systems have something called a local hosts file. With this you can define FQDN entries or host names and point them to IP addresses. Using this you can have the rest of the world still use the old address for the old server, while you can test the new server locally on your own system. There are usually programs available for your operating system to edit the hosts file and to point a specific host name to a specific IP. Using this method, you could point only the name vpn.yourcompany.com on your computer, or whatever your Access Server has as a DSN FQDN name, to the IP of the new server, and you can test while everybody else is still using the old server.
You can do this by editing the hosts file on your OS. You can usually find tools to do this properly for you, like Hosts File Editor for Windows. If you download and run the installer or portable .exe file for that on Windows you can quickly and easily edit your hosts file to point your Access Server’s domain name to the IP of your new server – but only on your computer. Do your tests and when things look good, you can undo the hosts file entry and do it for real on the real DNS record – point it to your new server.