System Requirements
The information in these subsections outlines system requirements for Access Server.
Access Server's only software requirements are choosing a compatible operating system (OS), avoiding static-compiled kernels, and running on a server without other applications, as noted below.
You can install Access Server on a server with a minimal install, a server install, or a full desktop installation.
Access Server is compatible with these 64-bit Linux operating systems:
Ubuntu* | 24.04 LTS (x86_64 and ARM64) 22.04 LTS (x86_64 and ARM64) 20.04 LTS (x86_64 and ARM64) |
Debian | 12 11 |
Red Hat Enterprise Linux | 9 8 |
Note
*For Ubuntu, we only support long-term support (LTS) releases.
Static-compiled kernels
Important
Access Server is not compatible with static-compiled kernels.
Static-compiled kernels can’t load specific modules for network traffic management (mangling, iptables, NAT), which are necessary for Access Server to function. For example, OVH/Kimsufi servers can have a static-compiled kernel on their Linux OS offerings, preventing the Access Server web interface from functioning. Similarly, some VPS systems, such as older OpenVZ implementations, can deny access to specific kernel modules.
CPU needs
Given the heavy use of CPU for encryption/decryption purposes, we don't recommend running Access Server on a shared-purpose platform, such as a cPanel or configServer hosting server. Access Server is not intended to coexist with other applications on the same server in that way. Also, other programs that manage firewall rules will likely interfere with Access Server's firewall functionalities. Technically it may be possible for multiple such programs to coexist, but we do not advise it.
Red Hat Enterprise Linux and firewalld
On Red Hat Enterprise Linux 8 and 9, we advise you to remove the firewalld daemon:
sudo su systemctl stop firewalld systemctl disable firewalld yum erase firewalld
The RHEL default-installed firewalld is incompatible with Access Server. Access Server implements its own firewall rules for VPN traffic.
Access Server hardware requirements are primarily specific to your bandwidth utilization. For example, if you run a VPN server to connect to a single web server through the VPN tunnel, 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.
Processor
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 rough estimate, you should quadruple your calculations for CPU sizing if your intended deployment platform doesn't support AES-NI.
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 due to 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. For example, a modern 4-core system at 3GHz would count as 12,000MHz, equating to approximately 1,000Mbps maximum throughput.
It's possible to use the OpenSSL program to run encryption tests to see what level of data encryption processing speed your CPU can manage. However, this only tells part of the story because bottlenecks such as network connectivity, packet signing, packet loss, and others can exist elsewhere. 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. We base these estimates on experience with standard encryption settings on somewhat recent systems to keep things simple.
Memory
Memory requirements depend on the number of connected devices and the level of NAT traffic your VPN server needs to process. At a minimum, start with 1GB of memory and add approximately 1GB for every 150 connected devices. Again, note that this is a rough estimate but should serve as a basis for estimating memory size.
Bandwidth
Bandwidth requirements depend entirely on how much total data you want to route through your VPN tunnels. If you have a server with a 1Gbps network connection and 100 connections, that means 10Mbps per user if they all use the total potential bandwidth simultaneously. Usually, however, only some require that level of simultaneous bandwidth. For example, if half of your users connect, but the other half are idling, the usage might average about 20Mbps per user. Unfortunately, we can't estimate how your users will use the connection; you must make that estimation.
Hard disk
Hard disk requirements are minimal — 16GB of disk space should be more than enough. The only data necessary to store on disk are connection and program logs and user certificates and settings. The logs may accumulate over time, and you should rotate or clear them per the instructions on our logging and debugging options page.
Tip
Remember that you need system disk space to store old and unused packages, system logs, cache, and other data.
When you set up an on-premise Access Server with your hardware, you can estimate how much bandwidth you can transfer through the VPN tunnels and the number of simultaneously connected users. But with virtual systems, such as virtual machines and virtual private clouds (Google Cloud, Amazon AWS, Microsoft Azure, Oracle, DigitalOcean, etc.), determining the available processing power may be much more challenging. How most cloud systems share their hardware may mean you don't 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 the speed is throttled down after a time. You will need to contact your provider for details on whether this is true for your chosen virtual solution.
Amazon AWS EC2
In our tests on Amazon AWS with different EC2 instance types, we concluded the following:
CPU and RAM are typically acceptable for a simple setup with ten users. You should be fine for this use case if you have at least 1GB of RAM and 1 or 2 vCPUs.
AWS arbitrarily limits bandwidth 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 they experience heavy CPU use, which can happen with a VPN system. For information about vCPU processing costs, refer to Amazon AWS documentation on Unlimited versus Standard mode.
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 ten users, calculate your maximum expected bandwidth in Mbps and choose an instance type accordingly: T-series is usually fine if the total is less than 200Mbps, 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.
Regarding 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.
You can install Access Server on A-series instances through a manual process. We don't provide a pre-built instance. However, you can launch an A-series instance and follow the steps to install Access Server on an ARM64 platform for Ubuntu 20 or Ubuntu 22.
OpenVPN uses the following terms when talking about connections and users in terms of purchasing your software license key.
Connected devices: Active VPN tunnel connections from devices to an Access Server.Data may be actively transferring, or the connection may be sitting idle.
Users: People connected to the VPN and actively doing tasks. Your users may be employees, vendors, contractors, or others.
Accounts: Usernames and passwords on your Access Server. These are set up and managed locally, or through LDAP, RADIUS, or SAML integrations.
The 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 with three devices: a phone, tablet, and laptop. If they connect to your Access Server with all three devices simultaneously, they count as three connections against your Access Server software license.
We don't count the number of accounts. For example, you can have 50,000 user accounts and a subscription for only 100 connections. Your server is okay with only 100 or fewer active VPN connections at any given time, which typically equates to having 100 devices that each simultaneously establish their own VPN connections.
If you use a site-to-site VPN, where a whole office network connects 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 a relatively high bandwidth demand and user activity level. You’ll often find users idling a lot more, resulting in lower bandwidth requirements. You can use these examples to guess 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 reasonably low and restricted to specific services. Likewise, we have customers that run 50 users on a single Access Server and max 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.
An organization has several web and other software services, including a primary build system like 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 ten people need access to resources on AWS.
The resources are only accessible by a private IP address in the VPC.
One 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.
A simple T3 (small or medium) would suffice in this example. The bandwidth utilization will be limited to simple web services, SSH access, and some pushing of code. A T3 instance could easily burst up to 200Mbps or more, which would be more than sufficient. Most of the time, the VPN connection would be idle.
An organization uses an online software solution for managing invoices and customer relationship management (CRM). They need to allow a single IP that is allowed to access this solution. They also want to ensure that their users securely connect when accessing any resources on the internet to protect their data communication from interception while on a public Wi-Fi network.
Approximately 100 users need access to internet resources.
A static public IP address is necessary for allowlisting.
One Access Server services all access requests.
You can deploy Access Server on AWS, GCP, Azure, DigitalOcean, etc.
All internet access and access to the CRM system is through this VPN server.
In this situation, you want to ensure you have a server that can use the CPU well because the bandwidth requirements are moderately high. This means you would need a C-series instance, such as the C5.large on AWS. A public IP that doesn’t change is common on most cloud provider platforms, and on AWS, you can use an Elastic IP.
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 insufficient because bandwidth demands and other system limitations require multiple servers.
Approximately 5,000 users need access to various resources.
You deploy Access Server 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.
You use a high-availability database service like Amazon RDS.
In this example, for the Access Server cluster functionality, you want to deploy a high-availability database solution like Amazon RDS or any other high-availability MySQL-type database backend. 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 ten nodes.
When routing all VPN client internet traffic through Access Server, we recommend not exceeding 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.
Regarding available bandwidth for your users, we recommend you service fewer than 1,000 connections per server. Suppose your server hardware is more powerful, and you feel this limit would be wasting your server's hardware potential or network capabilities. In that case, 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.
Access Server's default number of connections for a single server is set to 2,048. Increasing that number is possible if you route only minimal traffic through your server. Be aware that it could impact performance. However, if you'd like to raise the limit, we provide steps on changing the configuration here: Limit total maximum amount of VPN tunnels.
Note that the VPN subnet for the VPN clients may also become a limitation because it needs to be large enough to accommodate all VPN clients.
By default, 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 run into limitations with SQLite3. Alternatively, you can migrate the SQLite3 databases to MySQL or Amazon RDS. Those systems handle extensive datasets quickly. When you use Access Server's cluster functionality, you use these systems.
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 you add tens of thousands of unique access rules, the iptables system may be limited. Exceeding 20,000 unique rules may cause issues.