--- title: System Requirements for Access Server canonical: https://openvpn.net/as-docs/system-requirements/ product: Access Server Docs --- # 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) | **Distribution** | **Version** | | --- | --- | | Ubuntu\* | 26.04 LTS (x86\_64 and ARM64) 24.04 LTS (x86\_64 and ARM64) 22.04 LTS (x86\_64 and ARM64) | | Debian | 13 12 | | Red Hat Enterprise Linux | 10 9 8 | > **Note** > > \*For Ubuntu, we only support long-term support (LTS) releases. Access Server is officially supported on the operating systems listed above. We recommend using one of these for production or other critical deployments. ### Security frameworks and firewall services Access Server manages its own firewall rules and networking behavior. Certain operating system frameworks or firewall services may interfere with its operation. If detected during installation, Access Server may display warning messages indicating potential conflicts. #### SELinux (RHEL-based distributions) On RHEL and RHEL-based distributions (such as Rocky Linux, AlmaLinux, and Oracle Linux), **SELinux** (Security-Enhanced Linux) provides mandatory access control policies. However, it can block internal processes required for a VPN server to function correctly. If detected, the installer displays: > Warning: SELinux has been detected, this may interfere with the functioning of Access Server. We recommend disabling SELinux to allow Access Server to manage VPN traffic and system permissions without conflict. To disable SELinux persistently: 1. Open the configuration file: ``` nano /etc/selinux/config ``` 2. Locate the line: ``` SELINUX= ``` 3. Change the value to: ``` SELINUX=disabled ``` 4. Save and exit — Ctrl + X, Y, Enter. 5. Reboot the system. A reboot is required for the change from enforcing to disabled to take effect at the kernel level. After rebooting, confirm SELinux is disabled: ``` getenforce ``` The output should return "disabled." #### firewalld (RHEL-based distributions) The default **firewalld** service on RHEL and RHEL-based systems may conflict with Access Server, which implements its own firewall rules for VPN traffic. If detected, the installer displays: > Warning: firewalld has been detected, this may interfere with the functioning of Access Server. We recommend stopping, disabling, and removing firewalld when Access Server is managing firewall rules directly: ``` sudo su systemctl stop firewalld systemctl disable firewalld yum erase firewalld ``` After rebooting, confirm firewalld has been removed: ``` systemctl status firewalld ``` The output should indicate that the service isn't found. ### 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**](https://openvpn.net/as-docs/hyper-v.md), 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](https://openvpn.net/as-docs/docker.md)** 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](https://openvpn.net/as-docs/docker.md). ### 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. ## Hardware requirements 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:** 1. Start with at least **1GB** of RAM. 2. 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. ## Docker requirements 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](https://docs.docker.com/engine/install/) installed. > **Note** > > We recommend using Docker CE for headless Linux environments. For desktop (GUI) environments, [Docker Desktop](https://docs.docker.com/get-docker/) 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](https://openvpn.net/as-docs/v3/docker.md) for other limitations and known issues when running Access Server in a Docker container. ### Related documentation - [Docker](https://openvpn.net/as-docs/docker.md) - [Access Server on Docker Hub](https://hub.docker.com/r/openvpn/openvpn-as) ## Infrastructure recommendations 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: 1. Launch an **EC2 instance** running **Ubuntu 20.04 ARM64, 22.04 ARM64, or 24.04 ARM64**. 2. Use our [installation script](https://as-portal.openvpn.com/instructions/linux/installation) to deploy Access Server on the instance. ## Software licensing for devices, users, and accounts 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. ## Example deployments 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. ### Scenario 1: Developer access to AWS internal resources only - **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. ### Scenario 2: User access to online resources - **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. ### Scenario 3: Large user base with high availability - **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. ### Scenario 4: IoT devices deployed in multiple remote locations (on-premise setup) - **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. ## Limitations ### 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](https://openvpn.net/as-docs/tutorials/tutorial--change-maximum-vpn-tunnels.md). ### 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: - [Tutorial: Change the Database Backend to MySQL or Amazon RDS with the Admin Web UI](https://openvpn.net/as-docs/tutorials/tutorial--change-db-backend-gui.md) - [Tutorial: Manually Change the Database Backend to MySQL or Amazon RDS from the Command Line](https://openvpn.net/as-docs/tutorials/tutorial--change-db-backend-cli.md) ### 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 ``` --- Prev: [Administration](https://openvpn.net/as-docs/administration.md) Next: [Simple Infrastructure](https://openvpn.net/as-docs/simple-infrastructure.md) Index: https://openvpn.net/as-docs/llms.txt