Software requirements

OpenVPN Access Server is compatible with these 64-bit Linux operating systems:

Ubuntu*20.04 LTS
18.04 LTS
16.04 LTS
Red Hat Enterprise Linux8
Amazon Linux 2Amazon Linux 2
*Note: For Ubuntu, only long term support (LTS) releases are supported.

You can find instructions for each of these operating systems on the software packages download page.

One of the requirements for running Access Server is that you do not use a static-compiled kernel. Static-compiled kernels can’t load certain modules for network traffic management (mangling, iptables, NAT), which are necessary for Access Server to function. For example, OVH/Kimsufi servers can be provided with a static-compiled kernel on their Linux OS offerings, which prevents the Access Server web interface from functioning. Similarly, some VPS systems such as older OpenVZ implementations can deny access to certain kernel modules. 

Otherwise, there are no particular software requirements. You need a server (virtual or on premise) with a supported Linux operating system. The server can be a minimal install, a server install, or a full desktop installation.

Hardware requirements

Access Server hardware requirements are largely specific to your bandwidth utilization. For example, if you run a VPN server for the purpose of connecting to a single web server through the VPN tunnel, then the requirements are much less when compared to running a server that redirects all Internet traffic. Traffic passing through a VPN connection utilizes processing capacity for encrypting and decrypting on both the client and the server side. To correctly estimate the sizing of your Access Server, you must estimate how much sustained bandwidth you need to route through the VPN server, and estimate the CPU size accordingly. Memory size and disk space are more predictable.


Almost all modern CPUs support AES-NI to speed up AES processing. Access Server automatically uses AES-NI for the default AES-256 encryption. A  non-AES-NI CPU severely lowers the speed of the encryption/decryption process. As a very rough estimate, you should quadruple your estimates for CPU sizing if AES-NI is not supported on your intended deployment platform.

These estimates are only a rough guide, because they don’t account for variations in capabilities between different CPUs. Nor do they account for throttling as a result of physical limitations such as overheating, or virtual limitations such as running on a shared platform (like AWS with burstable instances).

As a rule of thumb, you should assume that on a modern CPU with an AES-NI chipset you need approximately 12MHz for each megabit per second (Mbps) transferred in one direction. Access Server can use all available CPU cores on a system, so for example a modern 4-core system at 3GHz would count as 12,000MHz, which equates to approximately 1,000Mbps maximum throughput.

It is possible to use the OpenSSL program to run encryption tests to see what level of data encryption processing speed your CPU is capable of. However, this does not tell the full story because bottlenecks can exist elsewhere, for example in network connectivity, packet signing, packet loss, and others. Depending on what your OpenVPN client is capable of, AES-256-CBC and AES-256-GCM may be used. Note that GCM is easier on a CPU than CBC. To keep things simple, the estimates provided here are based on experience with standard encryption settings on somewhat recent systems.


Memory requirements are dependent on the number of connected devices and the level of NAT traffic your VPN server needs to process. At a minimum, you must start with 1GB of memory, and add approximately 1GB for each 150 connected devices. Again, note that this is a rough estimate but should serve as a basis for estimating memory size.


Bandwidth requirements are completely dependent on how much total data you want to route through your VPN tunnels. If you have a server with a 1Gbps network connection, and you have 100 connections, that means 10Mbps per user if they all use the full potential bandwidth at the same time. Usually, however, not everyone requires that level of simultaneous bandwidth.  For example, if only half of the users are connected and the other half are idling, then that means the usage is 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.

Hard Disk

Hard disk requirements are minimal. The only data that are necessary to store on disk are connection and program logs, and user certificates and settings. The logs may accumulate over time and should be rotated or cleaned using the instructions on our logging and debugging options page. 16GB of disk space should be more than enough.

Infrastructure recommendations

When you set up an on-premise Access Server with your hardware, you can make a fairly good estimation of how much bandwidth you can transfer through the VPN tunnels, and how many users can be connected at the same time. But with virtual systems, such as virtual machines and virtual private clouds (Google Cloud, Amazon AWS, Microsoft Azure, Oracle, DigitalOcean, and so on), it may be much more difficult to accurately determine how much processing power is available to you. Most cloud systems share their hardware in such a way that you may not have full access to the CPU. Your access speeds may be throttled and you may not realize it at first. Often, peak utilization is allowed for a short while and then after a time the speed is throttled down. For details on whether this is true for your chosen virtual solution, you will need to contact your provider for specifics.

Amazon AWS EC2

In our tests on Amazon AWS with different EC2 instance types we concluded the following:

  • For a simple setup with 10 users, CPU and RAM are typically not a problem. If you have at least 1GB of RAM and 1 or 2 vCPUs you should be fine for this use case.
  • Bandwidth is arbitrarily limited on cheaper instances of a T2 or T3 type. When you hit that limit, the connection slows down. We’ve seen T-series instances max out at around 200-400Mbps total. 
  • T-series instances may incur additional charges if the CPU is heavily used, which can happen with a VPN system. Refer to Amazon AWS documentation on Unlimited versus Standard mode to learn about vCPU processing costs.
  • If your users have high bandwidth requirements such as copying large video or image files over the VPN or streaming video content, you will need a more expensive instance such as the C-series.
  • For more than 10 users, calculate your maximum expected bandwidth in Mbps and choose an instance type accordingly: T-series is usually fine if less than 200Mbps total, and C-series is better if you need more.
  • The mention of 5Gbps network performance on AWS instances refers to internal network traffic. For external (Internet) traffic, we’ve seen problems above a 1Gbps sustained transfer, where we triggered protective measures in the AWS systems.
  • In regards to the above points, going beyond the C-series 2xlarge type seems pointless because you would hit the bandwidth limit before you hit the CPU limit.
  • If you need more than 1Gbps bandwidth, we recommend deploying multiple Access Servers in a cluster so that they can share the load.
  • A-series instances are not supported at this time. Access Server is currently not yet available for A-series instances, which run on the ARM64 platform.

Software licensing: devices, users, and accounts

OpenVPN uses the following terms when talking about connections and users in terms of purchasing your software license key.

Connected DevicesActive VPN tunnel connections from devices to an Access Server.
Data may be actively transferring or the connection may be sitting idle.
UsersPeople connected to the VPN and actively doing tasks.
Your users may be employees, vendors, contractors, or others.
AccountsUsernames and passwords on your Access Server.
These are set up and managed locally through LDAP or RADIUS integrations.

The OpenVPN Access Server software licensing system monitors the number of active VPN tunnel connections. Typically, a single device can only establish one VPN connection to the same server. For example, you could have a user who has three devices such as a phone, tablet, and laptop. If all three of these devices are connected to your Access Server at the same time, they count as three connections against your Access Server software license.

We do not count the number of accounts. For example, you can have 50,000 user accounts and a subscription for only 100 connections. As long as only 100 VPN connections or fewer are active at any given time, your server is okay. This typically equates to having 100 devices that each establish their own individual VPN connections at the same time.

If you use a site-to-site VPN, where a whole office network gets connected to a VPN server, a single device establishes the VPN connection. This device serves as a VPN client gateway for the network. The office network can use standard network routing to access resources on the VPN server through this VPN client gateway. This example of a site-to-site VPN connection only uses one connection on the software license.


The following examples assume that there is both a fairly high demand on bandwidth and level of user activity. In reality, you’ll often find that users are idling a lot more and as a result the bandwidth requirements are lower. You can use these examples to make an educated guess about what kind of system you need to reach a specific goal. OpenVPN has customers that successfully run 2,000 VPN connections on a single Access Server on a quad-core CPU system, because their requirements for data throughput are fairly low and restricted to specific services. Likewise, we have customers that run 50 users on a single Access Server and are maxing out their octa-core CPU system because they push so much traffic through it.

We can’t provide precise examples because of the myriad variables such as bandwidth utilization and external factors, but here are some example scenarios that you can use for comparison.


Developer access to AWS internal resources only

An organization has a number of web services and other software services, which includes a primary build system such as Jenkins and secondary build systems running on Amazon AWS. These resources are only accessible from within the private IP space of the VPC on AWS. You need to grant secure access.

  • Only about 10 people need access to resources on AWS.
  • The resources are only accessible by private IP address in the VPC.
  • One OpenVPN Access Server services all access requests.
  • Internet traffic won’t be redirected through the VPN server.
  • Only access to AWS resources is sent through the VPN tunnel.

In this example, a simple T3 (small or medium) would suffice. The bandwidth utilization will be limited to simple web services, SSH access, and some pushing of code. A T3 instance would be able to burst up to 200Mbps or more fairly easily, which would be more than sufficient. Most of the time the VPN connection would be idle.

User access to online resources

An organization uses an online software solution for managing invoices and customer relationship management (CRM). They need to whitelist a single IP that is allowed to access this solution. They also want to ensure that their users are using a secure connection when accessing any resources on the Internet, so that when the users are on a public wifi network, their data cannot be intercepted.

  • Approximately 100 users need access to Internet resources.
  • A static public IP address is necessary for whitelisting.
  • One Access Server services all access requests.
  • The Access Server can be deployed on AWS, GCP, Azure, DigitalOcean, and so on.
  • All Internet access and access to the CRM system is through this VPN server.

In this situation you want to ensure that you have a server that can make good use of the CPU, because the bandwidth requirements are moderately high. On AWS this means you would need a C-series instance such as the C5.large. A public IP that doesn’t change is common on most cloud provider platforms, and on AWS you can use an Elastic IP.

Large user base needs highly reliable access

An organization needs secure access to various public or private resources with a high-availability solution for 5,000 users. A single Access Server is not sufficient, because bandwidth demands and other system limitations require multiple servers.

  • Approximately 5,000 users need access to various resources.
  • Access Server is deployed with a 10-node cluster.
  • If a single node dies, the solution is still up and working.
  • Access to the various resources is possible through any one of the nodes.
  • A high-availability database service like Amazon RDS is used.

In this example, you want to deploy a high-availability database solution like Amazon RDS or any other high-availability MySQL-type database backend for the Access Server cluster functionality. Multiple Access Server nodes are deployed with the ability to make good use of the CPU, because the bandwidth requirements are reasonably high and sustained. On AWS this means a C-series type instance (such as the C5.xlarge) for each of the 10 nodes.


When routing all VPN client Internet traffic through an OpenVPN Access Server, we recommend that you do not exceed 1,000 VPN connections per Access Server installation. This limitation is a practical limit on how many NAT connections a single operating system can handle efficiently. In terms of available bandwidth for your users, you may want to service fewer than 1,000 connections per server anyway. If your server hardware is more powerful and you feel this limit would be wasting your server’s hardware potential or network capabilities, you can virtualize the system and run multiple Access Server installations side-by-side on the same hardware. For example, ESXi, HyperV, and Proxmox are solutions that can run multiple virtual machines on the same hardware.

If you intend to route only very limited traffic through the OpenVPN Access Server, you may be able to run in excess of 3,000 VPN connections through a single VPN server. However, bandwidth utilization is of course very relevant. By default, OpenVPN Access Server limits the number of connections to 2,048. You can raise that limit with the configuration setting described here. Note that the VPN subnet for the VPN clients may become a limitation as well, because it needs to be large enough to accommodate all VPN clients.

By default, OpenVPN Access Server uses SQLite3 databases, which is usually sufficient. However, if you have tens of thousands of user accounts and a lot of log activity, you may end up running into limitations with SQLite3. As an alternative you can migrate the SQLite3 databases to MySQL or Amazon RDS. Those systems are meant to handle very large datasets quickly, and are also used for our clustering functionality.

OpenVPN Access Server uses iptables to manage access control rules. It sends instructions to OpenVPN clients to send specific traffic through the VPN server, and also functions as a firewall that prevents OpenVPN clients from trying to access more than what is allowed. If tens of thousands of unique access rules are added, the iptables system may run into some limitations. We generally find that exceeding 20,000 unique rules may cause issues.