The OpenVPN Access Server product is meant to be installed on a supported Linux operating system. To learn more about exactly which installation packages are available for supported operating systems check the software packages download page on our main website. On CentOS 7 and Debian 9, the package net-tools is required because Access Server at the moment still relies on ifconfig to do certain tasks.
One of the requirements for running Access Server is that you do not use a static compiled kernel. Such a kernel would not be able to load certain modules for network traffic management (mangling, iptables, nat) necessary for Access Server to function. In a notable example, OVH/Kimsufi servers can be provided with a static compiled kernel on their Linux OS offerings, and this prevents the Access Server’s web interface from functioning. On certain VPS systems, notably older OpenVZ implementations, access to certain kernel modules can be denied, and this results in a similar problem.
There are no particular software requirements otherwise. To put it simply, you need a supported Linux OS installed, virtual or not, and whether that’s a minimal install or a server install or a full desktop installation doesn’t really matter.
CPU requirements are very difficult to specify because of the wildly different requirements and use-cases. For example, if you run a VPN server for 500 people, but all they do is use it to reach one web server through the VPN server, then requirements are a lot lower than running the same server but redirecting all their Internet traffic through the VPN server. Traffic passing through the VPN connection will take up CPU processing power, on both the client and the server side, because information needs to be encrypted and decrypted. If you have a modern CPU that supports AES-NI, then the system may be able to offload some of the load. On older systems, you just need to roughly double your estimates. As a rule of thumb you should assume that on a modern CPU with AES-NI chipset, for every megabit per second of data traffic (in one direction) you need about 20MHz. This is a very rough estimate, but there is some variation in type of CPU, AMD or Intel, AES-NI or not, etcetera, so we’re only able to make a rough estimate. If your CPU is older and does not have AES-NI, assume 40MHz per megabit per second of data traffic.
It is possible to use the OpenSSL program to run encryption tests to see what kind of data encryption processing speed you can expect to get. This would then give you a more accurate estimate of how much data traffic you can transport through an OpenVPN tunnel. The estimates given are based on experience and with the standard encryption settings. If you are looking towards increasing performance, you can consider lowering encryption settings to lighten the load and speed things up.
Memory requirements are highly dependent on the amount of connected devices, and how much NAT traffic you’re doing. At the minimum we advise that you should start out with 1GB of memory. You can go lower, but you may or may not run into memory utilization issues later, so we prefer to keep a safety margin. On top of that, our recommendation is that if your users are only accessing resources on your private network, and do not transfer their entire Internet traffic through the server, that you should add about 500 megabytes of memory per 100 connected devices. So for a 1000 connected devices that would be 6GB of memory. If your users route all their Internet traffic through the VPN server, double that to 1000 megabytes per 100 connected devices. So for a 1000 connected devices that would be 11GB of memory. Again, this may be on the high side but we prefer a safety margin in our estimates, to avoid having you run into memory issues. You may of course experiment at will and see what works for you.
Bandwidth requirements are completely dependent on how much data you wish to push through the VPN tunnels in total. If you have a server with a 1Gbps network connection, and you have a 100 devices connected to it, that leaves 10Mbps per user if they all use the full potential at the same time. Usually however not everyone will be doing that at the same time, and if for example only half of the users are using the connection fully, and the other half is idling, then that leaves about 20Mbps per user. Unfortunately there is no way for us to estimate how your users will use the connection, you will have to make that estimation by yourself.
Disk requirements are fairly low. A minimal Linux installation with Access Server could fit on even 2 gigabytes. Most data is being used by logs over time, so please be aware of this and check our logging and debugging options page for more details on how to setup log rotation, to prevent filling your hard disk space up. We would recommend a comfy 16GB of disk space and possibly more if your user account database is going to be extremely large.
With server systems that are completely dedicated to the purpose of running a VPN solution, and fulfill no other purpose besides that, you can make a fairly good estimation of how much bandwidth you will be able to transfer through the VPN tunnels, and how many users can be connected at the same time. But with virtual systems like virtual machines and cloud based systems like CloudSigma, Amazon AWS, Microsoft Azure, and so on, it may be extremely difficult if not impossible to gauge exactly how much processing power will be available to you. The problem here is that very often cloud systems share the hardware in such a way that you may not have full access to the CPU. You may be throttled. This can result in trying to stress-test the VPN tunnels to their maximum speed, and discovering that the speed is lower than you would want, but the CPU may not show full utilization, which could lead to a false conclusion that the issue is not CPU related, but this behavior can happen if the CPU is being throttled, so please be aware of this. Often peak utilization is allowed for a short while, and then the speed is throttled down. For details on whether this is true for your chosen virtual solution, contact your provider and ask them for details.
Connected devices, users, accounts
When we say connected devices, we mean active VPN tunnel connections from devices to the Access Server. In this we do not make a distinction between whether this VPN tunnel is being used to transfer data at this point, or just idles. This is different from the term users, where we mean actual live people doing certain tasks through the VPN tunnel using their connected devices. Please note that it is possible to have for example a single VPN tunnel that handles traffic for an entire network of computers with users working on them, but that is not the definition we use here on this page. It is also distinctly different from the term accounts, by which we mean user names and passwords on the Access Server. You can have for example 50000 accounts on a server, 200 connected devices, and 100 users actually doing any work at this moment.
The examples given below are assuming fairly high demand on bandwidth and activity of the users. In reality you’ll often find that users are idling a lot more and as a result the bandwidth requirements are a lot lower. But the examples are here to show you how to make an educated guess about what kind of system you need to reach a certain goal. Having said that, we have customers that run near 2000 users on a single Access Server on a quad-core system just fine, because their requirements of the data throughput are fairly low and restricted to specific services. Likewise, we also have customers that run around 50 users on a single Access Server, and are maxing out their octa-core setup because they push so much traffic through it. It just depends on what you need so it’s very hard for us to give you an accurate assessment ourselves.
A reasonably demanding setup – let’s say you have modern dedicated server with AES-NI and you need 500 devices connected to it, and they reroute all their Internet traffic through the VPN tunnel, and about 50% will be actively using the connection, and 50% will be idling, at any given time. This will of course vary as some users will open a web page, and then read it for a while leaving the connection mostly idle, while another user at the same time opens an email program and retrieves email. In other words, a typical office work situation. Let’s say you want to make sure each active user will have 10Mbps available, and let’s assume they actually have that bandwidth on their Internet connection.
250 active users times 10Mbps is 2500Mbps or 2.5Gbps. Servers with 10Gbps lines are readily available so this shouldn’t be a problem to achieve in terms of network bandwidth.
2500Mbps times 20MHz is about 50000MHz or 50GHz. Processors with 3.5GHz for example in dual octa-core setup would get you over those requirements.
With 500 connected devices in this example you would need about 6GB of memory on your system. This is a reasonably low amount for modern systems, so easy to achieve.
A simpler setup – let’s say you have an old dedicated server without AES-NI and you need 200 devices connected to it, but they only route traffic for a web server and a file server on your private network, and about 50% will be actively using the connection, and 50% will be idling, at any given time. As in the previous example this will of course vary somewhat as some users are working on other tasks and alternate this with retrieving files and data through the VPN tunnel. Let’s say you want to make sure each active users will have 10Mbps available, and let’s again assume they actually have that bandwidth on their Internet connection.
100 active users times 10Mbps is 1000Mbps or 1Gbps. Most systems nowadays have this by default, even servers that are several years old.
1000Mbps time 40MHz is about 40000MHz or 40GHz. Older servers with a dual octa-core setup with 2.5GHz will be able to get you to those requirements.
With 200 connected devices in this example you would need about 2GB of memory, a fairly low amount.
If you intend to route Internet traffic through the OpenVPN Access Server, we recommend that you do not exceed 1000 users per Access Server installation. This limitation is a practical limit that has to do with how many connections a single operating system can actually handle, and since everything goes through the Access Server, you may run into some hard limitations of the OS here. If your server hardware is more powerful and you feel like this limit would be wasting your server’s hardware potential, please keep in mind you can virtualize the system and run multiple Access Server installations side-by-side on the same hardware. We prefer ESXi ourselves for this but HyperV, Proxmox, and other solutions, are also acceptable.
If you intend to route only limited traffic through the OpenVPN Access Server you may be able to run in excess of 3000 connected devices through a single installation, but going beyond 2000 our advice is that you should split things up into separate installations, to avoid running into any operating system limitation issues. In short, it entirely depends on what you do with it. For example, one of our customers uses it purely as a means of performing maintenance on systems, and so the bandwidth utilization is extremely low, and the load on the system consequently is as well, which means they can run thousands of connected devices on the same Access Server just fine.
User accounts on the OpenVPN Access Server can be much higher than the amount of actually connected devices. For example you can have 50000 usernames+passwords stored on the Access Server just fine. If only 500 of those are actively connected at any given time, there’s no problem at all.
The OpenVPN Access Server uses SQLite database files by default. At some point, these files can grow to proportions that make it inefficient to use. If you have tens of thousands of user accounts and a lot of connection/disconnection activity, you may end up with files that are gigabytes in size, and SQLite3 isn’t very efficient when it comes to files of that size. If ever you do run into a speed limitation or a size limitation due to the back-end databases, you do have the choice to migrate the SQLite3 databases to MySQL or Amazon RDS. Those systems are meant to handle very large datasets quickly.