Configuration

When you purchase an activation key for the number of active connections and time frame chosen, you need to activate it. To do this, simply copy and the key from the Access Server portal into the field, Enter Activation Key here and click on Activate.

To add more VPN connections, simply increase the number of connections for your subscription. Your activation key scales up or down as you adjust it in the pricing portal on our website. You can see your total VPN connections on your Activation page, the Status Overview page, and your pricing portal.

To add connections, sign in to the portal on OpenVPN.net, increase the number needed, then complete the payment process. Your updates automatically display on your Access Server.

You no longer need to manually enter new keys to renew your activation key. Within the subscription portal, your key automatically renews monthly or annually, depending on your choice.

If you need to replace your subscription key, you can do that by copying and pasting the new key into the field, Enter Activation Key here, then click Replace.

To configure Access Server for a cluster, you can create a new cluster or join an existing cluster.

Selecting either option displays configuration fields.

When you select Setup a New Cluster, found in the Cluster Setup section, additional sections display at the bottom of the page.

The following UI fields are relevant to an Access Server that is part of a network of nodes.

After you configure the cluster fields and restart Access Server, this message displays: You are currently viewing Settings for the whole Cluster. The side menu of the Admin Web UI has sections that are inaccessible when viewing the cluster and others that are inaccessible when viewing an individual node. Certain settings can only apply to specific nodes, while others apply to the entire Access Server cluster.

Cluster Overview

The following changes in functionality now affect the Status Overview page. The name in the sub-menu remains the same but when you click it, you navigate to the Cluster Overview page. This page consists of a table listing relevant information for each node in the cluster, providing an overview of the node(s) while also providing an interface to execute actions for each node.

Status/Node Name	This column displays the node status, active or inactive, and the general name. When you click on the column, you can see more information about the node: activation type, authentication, IP address, port, OSI layer, and server cipher.
Node IP Address Port	This column displays the host IP address of the node and the port it's using.
Version	This column displays the Access Server version for the node. Ensure all nodes are running the same version and we recommend being on the latest version.
VPN Connections	This column lists the total amount of VPN connections permitted for the node based on your subscription.
More Info	Clicking this icon displays additional information about the node. The table that displays when you click the node's name is the same.
View Node	Clicking this icon allows you to configure the settings of the specific node. Here, you can view the node's status and current users, generate logs, and configure the routing settings. However, certain settings are unavailable, such as authentication, since these are handled by the cluster instead of the individual nodes.
Restart	Clicking on this icon restarts the node.
Remove	Clicking on this icon removes the node from the cluster.

To configure the TLS options for the OpenVPN protocol, click the toggle to select the minimum TLS protocol to use. The default is TLS 1.2.

Not all OpenVPN clients support the minimum TLS protocol setting, which may prevent some clients from connecting to the server. When possible, we recommend updating older clients to use improved security protocols.

Changing these settings here may restart the web server. Ensure you refresh your browser to reload the page after the server restarts.

To choose between TLS options for the Access Server web server, toggle between the different protocol versions. The default is TLS 1.2. Toggling these settings restarts the server. Again, refresh your browser when you change settings.

Use this section to configure the VPN server's hostname or IP address, interfaces, protocols, daemons, and ports. Incorrect configuration of your server's hostname or IP address breaks Access Server functionality. Any changes to these settings directly affect client configuration files issued to VPN clients. Thus, making any alterations requires users to update their connection profiles.

Ensure you correctly configure the server's hostname or IP address for Access Server to function. You can choose between using TCP, UDP, or both protocols. You can also define the port used by each protocol. When you select both protocols, you can define how many daemons both protocols may have.

The admin and client UIs sections allow you to configure the ports to access each and the interfaces they listen on. You can change these settings with one of the three options beneath Interface and IP Address.

The Client Web Server section can use the same IP address and port as the Admin Web UI. If chosen, it inherits the port, interface, and IP address defined for the Admin Web UI. You will see additional configuration options if you choose to use a different IP address or port.

If you select Use a different IP address or port, then additional fields display for configuration.

When a VPN client connects to your Access Server, it is assigned a unique IP address on the virtual VPN IP network. This is managed by the dynamic IP address network you can configure with this page.

You can define the VPN IP subnetworks from which an address is pulled when a user connects to the network. If the user doesn't have a predefined IP address, Access Server assigns one for the connection. (You configure predefined IP addresses on the User Permission page at the user level.)

You can configure important global settings here. This is where you globally define whether or not connected users can access server-side resources, whether all traffic routes through the VPN, and whether clients can access network services on the VPN gateway IP address. If you have user or group-specific routing needs, ensure you configure them at the user or group level.

In the DNS section, you can leave the client’s DNS settings as is, use the Access Server’s DNS settings, or push specific DNS server IP addresses.

If you choose yes for Should client Internet traffic be routed through the VPN?, you must have clients use the same DNS servers as the Access Server host or specifically defined servers here.

Below these are optional DNS resolution zones and default domain suffix settings. You can alter these settings after setting up Access Server; they are pushed to the client with each connection.

OpenVPN data channel offloading (DCO) improves performance when enabled on the VPN server and clients. DCO offloads the data channel encryption and decryption to the kernel space. Handling encryption in the kernel space rather than the user space improves performance.

This setting determines if users can connect with each other.

This setting determines if the same user can have multiple simultaneous connections to the server. Each connection is counted as a separate concurrent user in terms of user limits. If you configure a user with a static IP address, they can't have multiple concurrent VPN connections, regardless of this setting.

OpenVPN protocol uses two communication channels during the VPN session. One is the control channel, where key negotiation, authentication, and configuration occur. The other is the data channel where the encryption packets are. The control channel can be secured further by signing and verifying the packets with a shared key. This is called TLS Auth. With TLS Crypt for OpenVPN, we add another layer of encryption to the control channel on top of signing and verifying with a shared key as TLS Auth does. This extra layer of encryption applies even to the key exchange before the TLS session starts.

You can choose from these values:

Access Server 2.9.0 and newer support all the above options, with tls-crypt as the default.

The data-channel encryption cipher encrypts and decrypts the data packets transmitted through the OpenVPN tunnel. Here, you can configure it on the server and client sides. The server and client must agree on a cipher they both support and allow. Enter the ciphers here in a string format with multiple ciphers separated by a colon, for example, AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305.

You can configure Windows-specific settings to enable/disable NetBios for connected clients. These settings don’t affect clients installed on other operating systems.

Network Basic Input/Output System (NetBIOS), is an API providing services for legacy applications to communicate with other computers within a local area network (LAN). A typical use case for NetBIOS is that a user running a page-formatting application might want to print remotely to a printer within its LAN. In the case of Windows, many of its older operating systems use Windows Internet Name Service (WINS) as a legacy name registration and resolution service. WINS maps NetBIOS names to IP addresses, hence why these settings may be important for Windows clients.

This setting determines the amount of time in minutes Access Server renegotiates each TLS session.

This setting allows you to define specific subnets that should use routing instead of NAT, even when you select NAT as the default access method in VPN Settings. By adding subnets to this configuration, those networks will use routing, allowing direct communication with the VPN clients while other traffic continues to use NAT. This option provides flexibility in managing traffic flow to specific networks in your VPN setup.

You can configure directives that aren’t covered elsewhere in the text boxes for the server and client side. For instance, to push a specific interface metric to clients, you would enter the following in the Server Directives:

push “route-metric 10”

To push a specific route to clients:

push “route 10.0.0.0 255.255.255.0”

To alter the cipher used for the VPN tunnel to AES-256-CBC, enter the following in both Server and Client Config Directives:

cipher AES-256-CBC

This first section details the information about the SSL web certificate. When installing Access Server, you encounter warnings about your browser not trusting the Admin Web UI's security certificate. This is because Access Server uses a self-signed certificate to start. You can replace that with a verified and trusted SSL certificate.

In order to set this up, ensure you have a Fully Qualified Domain Name (FQDN) to replace the IP address for connecting to the Admin Web UI.

This section is where you upload your commercial SSL web certificate bundle. We recommend providing a valid web cert from a root authority to avoid the warnings associated with a self-signed certificate.

When you click the toggle for User-provided Certificate, you can provide a certification bundle.

To upload and validate your own certificate, you need three items:

Ensure the certificate file format is Apache-compatible, such as X509/Base64 or PEM/CER format. If you receive files in .p12 or .pfx format, they are suitable for Windows but not Linux. You can convert the certificates to the required format using a certificate utility.

This section allows you to provide users with access to the Client Web UI, or the client web server (CWS), where they can download clients or profiles for their VPN connections. By default, Restrict Client Web Server access to Access Server Administrators is set to No. This allows users to sign into the Client Web UI and access the CWS. Change this to Yes , and only users defined as administrators have access.

Note: This doesn’t prevent access using the XML-RPC/REST API. The next section covers that.

The configurations within this section allow you to control access using the API with the following options:

With these configuration options, you can determine what users see on the Client Web UI. You can display all options or select specific clients and profile types. For instance, hide user-locked profile if you don’t want users to download their own profiles.

OpenVPN Connect v3 desktop downloads display by default.

This section allows you to enable the LAN-based redundancy model in case of server failure. Select the option LAN model (UCARP-based failover) to enable this feature.

Access Server failover uses the LAN redundancy model, in which the primary and secondary nodes have IP addresses in the same subnet and share a third, virtual IP address within that same subnet.

When you complete the details for the primary and secondary nodes, you then validate the setup. Validation creates new log files in the var/log directory titled, openvpnas-node.log.

UCARP relies heavily on rsync to share databases. Communication and any errors are recorded in log files.

The final step after validation is to click Commit and Restart.

Access Server 2.9.0 and newer provides a CA Management section in the Admin Web UI where you can view your current CA certificates and generate new ones. Access Server manages and issues these certificates—clients that connect with an older certificate will continue to connect as long as the public and private keys of the certificates on your Access Server match.

By default, Access Server generates a certificate authority (CA) from which server certificates and client certificates are generated with a 10-year lifetime, although this is adjustable. For a VPN connection to succeed, both the client certificate and the CA it uses to verify against must be valid. To ensure this remains the case, if Access Server starts up and detects the current CA is older than one year, it generates a new CA and uses that for creating new client certificates. This ensures that any newly generated user profiles with their associated certificates are valid for at least 9 years.

The CA Management tab displays all of the CAs on your Access Server with these details:

You can create a new CA by clicking on the Create New CA tab. Enter a Common Name (CN) and choose a signing algorithm. We recommend secp384rl for your algorithm and provide some inline information to help you with your key-signing choices. When you create a new CA, this forces a service-level Access Server restart.