Openvpn Port

[Malva Ferster]

Thisdocument provides information about Access Server's advanced features executed from the command line interface (CLI). For all commands, ensure you connect to your server with root privileges and run the commands from /usr/local/openvpn_as/scripts/.

You can set the interface and ports for the OpenVPN daemons from the Admin Web UI or the CLI. Use the commands below to change this in the CLI. Before you change the default settings, ensure you understand the information below about how the daemons work with the web interface to avoid problems accessing your Admin or Client Web UIs after making changes.

The OpenVPN daemons handle OpenVPN tunnel connections. These programs listen on all available network interfaces as the default. Alternatively, you can configure the OpenVPN daemons to listen on a specific network interface. You can also change the ports the OpenVPN daemons listen on, but we recommend only doing that in unique circumstances.

When you open a web browser and go to your Admin or Client Web UIs, the OpenVPN TCP daemon handles that browser request by internally redirecting the traffic to the web services that are actually running on port TCP 943.

Important: When you change the interfaces, the OpenVPN UDP and TCP daemons must listen on the same interface, and it's impossible to have them listening on two separate interfaces. If you want to change this, use iptables to internally redirect traffic on a specific port and interface to the correct port and interface.

In some rare cases, it can be desirable or necessary to turn off multi-daemon mode and launch one TCP or UDP OpenVPN daemon to handle all incoming OpenVPN tunnel connections through one single OpenVPN daemon. This may have some adverse side effects:

The commands below use the sacli GetNCores command to output the number of CPU cores detected on the system. With that information, you can configure the number of TCP and UDP daemons to spawn when Access Server starts.

Note: The characters around the sacli GetNCores command below are backticks, not single quotes, and this makes a significant difference in how you execute the command. We recommend copying and pasting the commands to ensure they execute properly. We also reset the default setting here to use multi-daemon mode, where multiple OpenVPN daemons launch.

Suppose you change the XML-RPC interface setting to full support in the Admin Web UI Client Settings page or via the CLI with the configuration option below. In that case, you can remotely control all Access Server functionality using XML-RPC calls instead. Authentication is done via HTTP basic authentication over a secure SSL connection. A standard user's credentials are sufficient to retrieve a user-locked profile, but only an admin user's credentials are adequate for other functions.

The result shows the XML query and the response. You can use this way of getting information for pretty much every sacli function. And sacli controls just about everything that Access Server can do.

Access Server has default values for the authentication and database threads, which handle requests during active connections. It's possible you could encounter an issue with not having enough threads in these scenarios:

You can use the commands below to increase the authentication and database threads for these situations. We recommend that you increase both so they stay the same number. Increasing the queue sizes resolves cases where the authentication or database calls exceed normal limits.

By default, Access Server allows 2048 VPN tunnels on a single installation, which is usually enough, but if you want to, you can increase that limit. If you change this value, even a warm restart of Access Server will restart the OpenVPN daemons, meaning all your VPN clients get kicked off and need to reestablish their connection, which should happen automatically.

Where is the maximum number of connected VPN tunnels. By default, this configuration key isn't present in Access Server, and when it is not present, it will be assumed to be 2048. You can set it to any valid number of your choice.

When you enable and configure Access Server's built-in failover mode, the primary node sends heartbeat signals to the local network. The secondary node monitors these heartbeat signals and takes over if the primary node fails. However, if you have multiple active pairs on the same network or other systems using UCARP/VRRP for automatic failover, the system needs a way to differentiate the signals. For this, Access Server uses a VHID, which is a unique number embedded in the heartbeat signals. Each failover pair needs its own ID. By default, this number is 94 on an Access Server failover pair. To adjust it to another number, change the value of the ucarp.vhid configuration key with the command below, but beware that you should follow the steps carefully described below for both nodes and that this will lead to having to restart the Access Server service on each node in turn, causing a total of two failover events. Plan this appropriately.

Now wait a full minute to ensure that the primary node has had a chance to create a new configuration backup file and relay it to the secondary node. For a brief moment, both nodes will try to be the primary node, as each does not see the other anymore due to the mismatched VHID number.

Finally, advanced users can pass additional parameters to the UCARP process using the ucarp.extra_parms configuration key. See the command below on how to pass extra parameters to the UCARP process that Access Server manages. Please note that changing this will result in a failover event, and you will then have to restart the Access Server service on the secondary node to ensure it goes back to the primary node.

Suppose, for example, you want to override the standard scripts that Access Server uses when the node becomes active or has to be a standby node. In that case, you can pass new --upscript and --downscript parameters directly to UCARP and specify new scripts instead. For example, you could copy the original ucarp_standby and ucarp_active up/down scripts in the /usr/local/openvpn_as/scripts/ directory and edit them to suit your needs. If you edit the scripts directly, they will be reset to standard whenever you upgrade or reinstall Access Server. Thus, we recommend creating copies of the up/down scripts to customize instead with the following commands.

Since you can't route private IP addresses on the internet, when VPN clients are connected to Access Server and have been given instructions to send traffic for public IP addresses through the VPN server, Access Server chooses the network interface with the default gateway on it and uses NAT to send traffic out through there. In some cases, it is desirable to disable this NAT behavior, such as when you wish to implement a firewall system that logs the VPN clients' private IP addresses as the traffic passes from the VPN client, through the VPN server, through the firewall, and then to the internet. You can implement the NAT behavior further in the connection chain before it goes onto the public internet. For this, you use a global setting that applies to the entire server for outgoing traffic through NAT. Disabling this setting or specifying a different IP address for outgoing NAT or even a range of addresses randomly selected for outgoing NAT operations is possible. Binding a specific public IP for outgoing NAT operations to a specific VPN client isn't possible.

The randomization of that last option is done using the Linux/Netfilter to-source algorithm. You must use interfaces and IP addresses that are available, configured, and working correctly on your system. We provide examples of specifying the interface and address for outgoing NAT below.

Access Server heavily uses Linux iptables to enable NAT functionality and enforce VPN-level access control rules. However, it also tries to play well 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 standard chains, which remains the default. Prepending means it tries to come first in an existing list of iptables settings to ensure Access Server works properly. However, you can change this behavior to append instead of prepend using the following config key. This can make it easier to develop custom rules which take priority over Access Server-generated rules.

It's also possible to completely disable Access Server's activities regarding iptables. However, this may lead to insecure situations as traffic may be allowed through that you didn't permit, and things may no longer function as intended. Disabling iptables means you're taking away one of the pillars on which the Access Server functionality is based, and you are then expected to take care of the required actions in iptables yourself. If you do not, the Access Server may completely fail. We do not recommend disabling Access Server managing the iptables settings. But if you must, for whatever reason, and you have the required knowledge to get things working, then the option is available. There are three distinct iptables items that Access Server manages, all enabled by default, but you have the option to disable them:

We don't recommend using Access Server in layer 2 bridging mode. It's considered a deprecated feature. Bridging mode disables much of Access Server's functionality as it no longer implements access control, IP address assignment, etc.

If you still wish to continue and enable layer 2 bridging, use the below command. Only use this with on-premise hardware, as it won't function with cloud-based servers. It's important to note that we don't provide support for this functionality.

3a8082e126