System Requirements
The information in these subsections outlines system requirements for Access Server.
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.
Access Server is compatible with these 64-bit Linux operating systems:
You can also install Access Server in a Docker container. For more info: Docker.
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. Also, other programs that manage firewall rules will likely 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 description, 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.
Check out the log rotation guide and troubleshooting disk space issues for more information.
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.
The following scenarios are based on high-bandwidth demand and active user levels. However, your actual bandwidth usage may vary depending on user activity, such as idle times. These examples provide rough estimates for selecting an appropriate system. 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.
Important
We can’t provide precise examples because of myriad variables, such as bandwidth utilization and external factors, but you can use these example scenarios as comparisons.
Users: 10 people.
Resources: Web services, Jenkins, other build systems on AWS, accessible only via private IP in AWS VPC.
Access needs: Only access to AWS resources; no internet traffic routed through the VPN.
Access Server: One Access Server for all requests.
Recommended setup
Instance: AWS T3 (small or medium).
Bandwidth: Limited to web services, SSH access, code pushes; typically idle.
Bandwidth Utilization: Minimal, burstable up to 200Mbps, more than sufficient for this setup.
Users: 100 users.
Resources: Access to CRM and invoice management software and general internet resources.
Access needs: Ensure secure connections when accessing resources over public Wi-Fi networks. A static public IP is required for allowlisting.
Access Server: One Access Server for all access requests.
Recommended setup
Instance: AWS C5.large (or equivalent on GCP, Azure, DigitalOcean) with a static public IP address (Elastic IP on AWS).
Bandwidth: Moderately high, needs a CPU-optimized instance for steady usage.
Bandwidth utilization: Medium; internet access and the CRM system are routed through the VPN.
Users: 5,000 users.
Resources: Secure access to public or private resources with a highly available solution.
Access Needs: Redundant, high-availability system with multiple Access Server nodes.
Access Server: 10-node cluster for high availability.
Recommended setup
Instance: AWS C5.xlarge or similar high-performance instance for each node.
High availability: Deploy multiple Access Server nodes with Amazon RDS or another high-availability MySQL-type database.
Bandwidth utilization: High, sustained, with redundancy in place for failover.
Users: 1,000 cameras, 1,000 routers (VPN gateways through built-in OpenVPN in the router operating systems).
Resources: Cameras monitored via VPN tunnels from a remote site.
Access needs: Site-to-site VPN between routers acting as VPN gateways and the Access Server.
Access Server: One or multiple Access Servers (cluster) for monitoring.
Recommended setup
Access Server: One or multiple nodes, with a cluster for high availability.
CPU: 4-6 cores if using split tunnel, 6-8 cores for older CPUs. Double the resources for full tunnel.
RAM: At least 8 GB for split tunnel, more for full tunnel.
Bandwidth utilization: Medium; dependent on camera data and site-to-site traffic.
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