System Requirements for Access Server
The information in these subsections outlines system requirements for Access Server.
Software requirements
Access Server requires a compatible operating system (OS) and a non-static-compiled kernel to function correctly. It should be installed on a dedicated server without other applications running.
You can install Access Server on a server with a minimal install, a server install, or a full desktop installation.
Supported Linux operating systems (64-bit)
Access Server is officially supported on the operating systems listed above. We recommend using one of these for production or other critical deployments.
Windows platforms (via virtualization or Docker)
Access Server can also run on Windows systems using virtualization or containers:
Windows 11 Pro / Enterprise — with Hyper-V, running a supported Linux virtual machine.
Windows Server (2019/2022 and newer) — with Hyper-V, running a supported Linux virtual machine.
Windows (Pro, Enterprise, or Server editions) — using Docker Desktop with a supported Linux container.
Important
Access Server doesn't install natively on Windows. A supported Linux OS must run inside Hyper-V or Docker.
Other options
You can also install Access Server directly in a Docker container on Linux. For more information, see Docker.
Community-based distributions
Access Server may also work on other Linux distributions based on Ubuntu LTS or RHEL, such as:
Ubuntu-based: Pop!_OS, Tuxedo OS, Zorin OS, Linux Mint
RHEL-based: Rocky Linux, AlmaLinux, Oracle Linux
While these systems often work well, they aren't officially supported and aren't recommended for use in mission-critical environments.
Static-compiled kernels
Important
Access Server isn't compatible with static-compiled kernels.
Static-compiled kernels are unable to load certain modules required for network traffic management (e.g., mangling, iptables, NAT), which are essential for Access Server's operation. For example, OVH/Kimsufi servers may use static-compiled kernels that prevent the Access Server web interface from working. Similarly, older OpenVZ implementations on some VPS systems may restrict access to necessary kernel modules.
CPU requirements
Access Server performs intensive CPU operations for encryption and decryption tasks. Therefore, we don't recommend running Access Server on a shared-purpose platform, such as a cPanel or configServer hosting server. Access Server shouldn't coexist with other applications on the same server in that way. Additionally, other programs that manage firewall rules may interfere with Access Server's firewall functionalities. While technically possible, running multiple programs of this nature together isn't advised.
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 default firewalld on RHEL conflicts with Access Server, which implements its own firewall rules for VPN traffic.
Access Server hardware requirements depend primarily on the volume of traffic routed through the VPN. For example, a server providing encrypted connections to a single web server will have different requirements than one routing all internet traffic. The most important factor is the processing power required for encryption and decryption, which affects both the client and server sides.
To estimate the system requirements:
Bandwidth: Estimate the sustained bandwidth that will pass through the VPN server.
CPU: Adjust the CPU size based on this estimate.
Memory & Disk Space: These are easier to estimate and generally more predictable.
Processor
Modern CPUs with AES-NI support hardware-accelerated AES encryption, significantly improving encryption and decryption speed. Access Server uses AES-NI by default for AES-256 encryption.
Non-AES-NI CPUs: If the CPU doesn't support AES-NI, encryption will be slower. As a rough estimate, you should quadruple your calculations for CPU sizing if your deployment platform doesn't support AES-NI.
General Estimate: You need about 12MHz of CPU per 1Mbps of traffic. For example, a 4-core 3GHz CPU has 12,000MHz, which can handle approximately 1,000Mbps of throughput.
Testing CPU capacity with OpenSSL
You can use OpenSSL to check your CPU's encryption capacity. It's important to note that 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. To keep things simple, we base these estimates on experience with standard encryption settings on somewhat recent systems.
If you want to test the ultimate capacity of the system to encrypt/decrypt via OpenSSL, here are some example commands:
To test encrypt/decrypt using AES-256-GCM with 1420 bytes for 10 seconds:
openssl speed -evp aes-256-gcm -seconds 10 -bytes 1420
To test with multiple CPU cores (e.g., 2 cores):
openssl speed -evp aes-256-gcm -seconds 10 -bytes 1420 -multi 2
Memory
Memory requirements depend on:
The number of connected devices.
The volume of NAT traffic the VPN server processes.
Estimate:
Start with at least 1GB of RAM.
Add 1GB for every 150 connected devices.
Important
This is a rough estimate and can vary depending on usage.
Bandwidth
Your bandwidth needs depend on how much data you plan to route through the VPN.
For example:
If your server has a 1Gbps connection and you support 100 connections, that would be 10Mbps per user if all users fully utilize the bandwidth simultaneously.
Typically, only a subset of users will be active simultaneously, so expect lower average usage (e.g., 20Mbps per user if only half the users are active).
Hard disk
Access Server's disk space requirements are minimal. Typically, 16GB of disk space is sufficient, as it only needs to store:
Connection logs.
Program logs.
User certificates and settings.
Tip
Don’t forget to account for disk space used by old system packages, logs, cache, and other data that might accumulate over time.
Log management:
Logs can accumulate over time, so rotate or clear them periodically.
You can run Access Server in a Docker container.
Docker is a tool that allows sysadmins to deploy applications in isolated environments, called containers, on a host operating system. Compared to virtual machines, Docker containers have lower overhead, making them more efficient for specific use cases.
Host system requirements
Ensure you have the following on your preferred host system:
Docker Engine installed.
Note
We recommend using Docker CE for headless Linux environments. For desktop (GUI) environments, Docker Desktop is available on Windows, macOS, or Linux.
A public IP address or domain name pointed to the public IP address.
Important
You can run an Access Server on a Docker container with a self-hosted server, but not all cloud providers grant admin privileges to their services. On a self-hosted server, the Docker container requires specific privileges to interact with the network stack. To ensure proper functionality, use the following options:
--cap-add=NET_ADMIN— Grants the container the necessary network administration capabilities.--cap-add=MKNOD— Allows the container to create device nodes.--device /dev/net/tun— Provides access to the TUN device for VPN traffic.
Refer to this section for other limitations and known issues when running Access Server in a Docker container.
Estimating available bandwidth and the number of simultaneous users is relatively straightforward when setting up an on-premise Access Server with your own hardware. However, determining available processing power can be more challenging when using virtual systems—such as virtual machines or virtual private clouds (VPCs)—from providers like Google Cloud, Amazon AWS, Microsoft Azure, Oracle, and DigitalOcean.
Cloud providers often share hardware resources, meaning you may not have full access to the CPU, and your access speeds could be throttled after peak utilization periods. Additionally, some cloud providers allow for temporary peak utilization but may reduce speeds once the limit is reached.
Note
It's important to consult with your cloud provider to confirm whether throttling applies to your chosen virtual solution.
Amazon AWS EC2
Our tests on Amazon AWS EC2 instances yielded the following observations:
CPU and RAM: For simple setups with around 10 users, an EC2 instance with at least 1 GB of RAM and 1 or 2 vCPUs is typically sufficient.
Bandwidth limitations:
T2 and T3 instances: These instances have bandwidth limitations. The connection slows down when the threshold is hit, typically maxing out at 200-400Mbps.
Additional charges: Due to Amazon's billing structure, heavy CPU use on T-series instances may result in additional charges. For details on vCPU costs, refer to Amazon AWS documentation on Unlimited versus Standard mode.
High bandwidth usage: We recommend a C-series instance for better performance if users need to transfer large files or stream video content over the VPN.
For more than ten users: Estimate your maximum expected bandwidth in Mbps:
T-series instances are typically acceptable for bandwidth demands up to 200Mbps.
C-series instances are suitable for higher bandwidth requirements.
AWS network performance:
The 5Gbps network performance mentioned for AWS instances pertains 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.
C-series 2xlarge instances are usually sufficient for most needs, because you'll hit the bandwidth limit before you hit the CPU limit.
Scaling for more than 1Gbps: If you require more than 1Gbps bandwidth, we recommend deploying multiple Access Servers in a cluster to distribute the load.
Using AWS graviton processors:
Graviton-based EC2 instances: You can manually install Access Server on EC2 instances powered by AWS Graviton processors (e.g., A1 or M7g series).
Installation: While we don't offer a pre-built Graviton instance, you can:
Launch an EC2 instance running Ubuntu 20.04 ARM64, 22.04 ARM64, or 24.04 ARM64.
Use our installation script to deploy Access Server on the instance.
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. A device is considered connected whether data is actively transferring or the connection is 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 tracks the number of active VPN tunnel connections, not the number of accounts or users.
Device Connections: Typically, each device can establish only one VPN connection to the Access Server. For example, if a user connects three devices (a phone, tablet, and laptop) to the server simultaneously, this counts as three active connections against your license.
Account Limits: Your license is based on the number of active VPN connections, not the number of accounts. For instance, you can have 50,000 user accounts but only a subscription for 100 connections. The system will allow 100 or fewer simultaneous VPN connections, which may correspond to 100 devices connecting simultaneously.
Site-to-Site VPN: In a site-to-site setup, one device connects the entire office network to the VPN server. This device acts as a VPN gateway, allowing the office network to access the VPN server through it. Despite multiple devices on the office network using the VPN, only one connection is counted toward the license.
VPN connections and NAT handling
Recommendation: Limit VPN client internet traffic routing through Access Server to 1,000 VPN connections per installation. This limitation is a practical limit on how many NAT connections a single operating system can handle efficiently.
Server capacity and virtualization
Bandwidth considerations: For better performance, we recommend servicing fewer than 1,000 connections per server. If you believe your server hardware is underutilized, consider virtualizing the system. Virtualization platforms such as ESXi, HyperV, or Proxmox can run multiple Access Server installations on the same physical hardware.
Maximum connections
Default limit: The default maximum number of connections for a single Access Server is 2,048.
Increasing the limit: You can increase this limit if you're routing minimal traffic, though this may impact performance. Refer to this tutorial: Adjusting the Maximum Number of VPN Tunnels.
VPN subnet limitations
Subnet size: Ensure your VPN subnet is large enough to accommodate all VPN clients. A subnet too small could limit the number of clients able to connect.
Database limitations (SQLite3 vs MySQL/RDS)
SQLite3 Limitations: Access Server uses SQLite3 by default, which is sufficient for most installations. However, you may encounter limitations if you have tens of thousands of users and high log activity.
Alternative: Consider migrating to MySQL or Amazon RDS for better scalability and faster handling of large datasets. When you use Access Server's cluster functionality, you use these systems. Refer to these tutorials:
iptables and Access Control
iptables Limitations: Access Server uses iptables to manage access control rules. If you add tens of thousands of unique access rules, you may hit the system's limit.
Threshold: We recommend no more than 20,000 unique iptables rules. Exceeding this could lead to issues with Access Server's functionality.
Check iptables Entries: To check the number of iptables entries, use this command:
iptables-save | wc -l