Access Server system requirements

Software requirements

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

We make getting started with Access Server as easy as possible. Create an account, then download the software for the platform of your choice from the Access Server portal.

One of the requirements for running Access Server is that you do not use a static-compiled kernel or a VPS as host with an older kernel. Static-compiled or older kernels on VPS host may not be able to 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. 

Given the heavy use of CPU for encryption/decryption purposes, it is not recommended to run Access Server on a shared purpose platform, like for example running it on a cPanel or configServer type of 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.

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.

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.

Hardware requirements

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

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 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 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 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 can manage. 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, we base these estimates on experience with standard encryption settings on somewhat recent systems.

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

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 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 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 will have to make that estimation.

Hard Disk

Hard disk requirements are minimal. 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 should be rotated or cleaned using the instructions on our logging and debugging options page. 16GB of disk space should be more than enough.

Note: Remember that you need system disk space for storing old and unused packages, system logs, cache, and so on.

Infrastructure recommendations

When you set up an on-premise Access Server with your hardware, you can estimate of how much bandwidth you can transfer through the VPN tunnels and how many users can be connected simultaneously. 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 the speed is throttled down after a time. 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 ten 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 ten 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.
• 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 either Ubuntu 20 or Ubuntu 22, which we support.

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.

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 do not 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 establish their own VPN connections simultaneously.

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.

Examples

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, resulting in lower bandwidth requirements. 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 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.

Scenarios

Developer access to AWS internal resources only

An organization has a number of web services and other software services, which include 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 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.

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 could easily burst up to 200Mbps or more, 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 connect securely when accessing any resources on the internet so that their data can't be intercepted when they're on a public Wi-Fi network.

• 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 insufficient, 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 ten nodes.

Limitations

When routing all VPN client internet traffic through an 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. 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. It’s possible to increase that number 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 and are also used for our clustering functionality.

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 run into some limitations. We generally find that exceeding 20,000 unique rules may cause issues.