Advanced Options Managed From The Command-Line Interface

The OpenVPN daemons manage OpenVPN tunnel connections. By default, they listen on all available network interfaces, using UDP port 1194 and TCP port 443. You can customize these settings via the Admin Web UI or CLI.

The OpenVPN 2 code base is single-threaded, meaning each OpenVPN process runs on a single CPU core and can't utilize multiple cores. To overcome this, Access Server can launch multiple OpenVPN daemons simultaneously, ideally one per CPU core. Additionally, to support both UDP and TCP protocols for client connections, Access Server requires separate OpenVPN daemons for each protocol.

You may encounter a scenario where you want to turn off multi-daemon mode. If so, follow this tutorial:

You can configure the number of TCP and UDP daemons that spawn when Access Server starts.

Refer to this tutorial: Reset Multi-Daemon Mode and the Number of TCP/UDP Daemons.

If you need to revert settings that have locked out of your web services or restore an Access Server backup configuration to a new system with a different interface name, it's helpful to run the commands from this tutorial:

Access Server utilizes XML-RPC for communication between its web services, core components, and OpenVPN Connect apps. This interface primarily checks credentials and retrieves user-locked profiles when using server-locked profiles. You can enable full XML-RPC support to remotely control all Access Server functionality. While documentation and support for XML-RPC are not provided, tools are available to help determine necessary calls and their execution.

Access Server has default settings for handling authentication and database connections, which can sometimes lead to issues under high load or specific scenarios like out-of-band MFA or slower authentication systems. By adjusting the maximum number of threads and connection QueuePool size, you can ensure smoother performance and avoid connection bottlenecks.

Access Server, by default, allows up to 2048 VPN tunnels. While this is sufficient for most scenarios, there are situations where you might need to increase or decrease this limit. Adjusting this setting can help manage server load and control access. However, be aware that changing this value will restart the OpenVPN daemons, causing all connected VPN clients to reconnect.

UCARP/VRRP failover ensures high availability for Access Server by having a secondary node take over if the primary node fails. When using multiple pairs on the same network, each pair requires a unique VHID to differentiate their heartbeat signals. Refer to the tutorial for steps on how to adjust the VHID and configure additional UCARP parameters.

Access Server's global NAT behavior setting controls how outgoing traffic from VPN clients is handled. By default, Access Server uses NAT for traffic destined for public IP addresses. However, in some scenarios, such as when you want to log VPN clients' private IP addresses, it may be desirable to disable this NAT behavior or specify a different interface or IP address for outgoing NAT operations.

To manage NAT behavior settings for your Access Server, refer to this tutorial:

Access Server utilizes Linux iptables extensively to implement NAT functionality and enforce VPN-level access control rules. It aims to coexist with other applications that use iptables by maintaining its own chains and making minimal additions to standard chains such as INPUT, OUTPUT, and FORWARD. By default, Access Server prepends to these standard chains to ensure proper functionality. However, you can modify this behavior to append instead of prepend, allowing you to create custom rules that take priority over Access Server-generated rules. Additionally, you can disable Access Server's iptables management, although this is not recommended as it may lead to security issues and loss of functionality.

Access Server transfers information by unicast: only traffic with a specific destination IP address can pass through the VPN server. Access Server blocks multicast or broadcast traffic with a to-whom-it-may-concern characteristic. You can lift the restriction on UDP multicast and IGMP packets allowing these to pass freely between VPN clients and the VPN server. Some software programs use these to auto-detect network systems or services, so this option may be necessary for such a situation. The configuration key vpn.routing.allow_mcast allows this traffic to pass through. It is disabled by default.