Set the interface and ports for the OpenVPN daemons
In the Admin UI under Server Network Settings there's the option to set the specific interface that the OpenVPN daemons should listen on. These are the programs that handle any incoming OpenVPN tunnel connections. This can for example be set to all so that it will simply listen to all available network interfaces, and usually this is the default. But in some situations it is desirable to configure the OpenVPN daemons to listen on a specific network interface only. You can also change the ports that the OpenVPN daemons listen on here, but we normally recommend not changing these unless there are unique circumstances.
Please note that the OpenVPN daemons and the web services are connected in a way. By default the OpenVPN Access Server comes configured with OpenVPN daemons that listen on port 1194 UDP, and OpenVPN daemons that listen on port 443 TCP. While the best connection for an OpenVPN tunnel is via the UDP port, we implement TCP 443 as a fallback method. It is likely that if you are on a public network that Internet connectivity is restricted. But TCP 443 is the port used for HTTPS traffic, and a lot of websites use HTTPS by default. So by having an OpenVPN TCP daemon on port TCP 443, chances are that even on such a restricted network your OpenVPN client program will be able to make a connection to the OpenVPN Access Server using the TCP fallback. It's no guarantee since some firewalls are quite sophisticated and can see the difference between a web browser and an OpenVPN client program, but it works on most simple firewalls.
As mentioned, TCP 443 is also used for HTTPS traffic, which the web interface of the OpenVPN Access Server also uses. You cannot have 2 different processes listening on the same port on the same server, so we use something we call service forwarding or port sharing. When you open the web interface of the Access Server on its default TCP port 443, the OpenVPN TCP daemon sees that request and recognizes that it is a browser request. It then internally redirects the traffic to the web services which are actually running on port TCP 943. When you change which interface the OpenVPN daemons listen on, you could be inadvertently denying yourself access via this port forwarding method. The solution then is to use the port that the web services are actually running on; TCP 943. To access the web interface at that port put :943 in the URL like so: https://your.vpnserver.com:943/
Warning: changing these values may mean you have to reinstall your clients in order to be able to make a connection again, as these settings do not update automatically on the clients.
To set the interface name that the OpenVPN daemons should listen on:
./sacli --key "vpn.daemon.0.server.ip_address" --value <INTERFACE> ConfigPut ./sacli --key "vpn.daemon.0.listen.ip_address" --value <INTERFACE> ConfigPut ./sacli start
To set a specific port for the UDP OpenVPN daemons:
./sacli --key "vpn.server.daemon.udp.port" --value <PORT_NUMBER> ConfigPut ./sacli start
To set a specific port for the TCP OpenVPN daemons:
./sacli --key "vpn.server.daemon.tcp.port" --value <PORT_NUMBER> ConfigPut ./sacli start
To restore the default so it listens to all interfaces and ports TCP 443 and UDP 1194:
./sacli --key "vpn.daemon.0.server.ip_address" --value "all" ConfigPut ./sacli --key "vpn.daemon.0.listen.ip_address" --value "all" ConfigPut ./sacli --key "vpn.server.daemon.udp.port" --value "1194" ConfigPut ./sacli --key "vpn.server.daemon.tcp.port" --value "443" ConfigPut ./sacli start
As an aside, it is not possible to have the OpenVPN UDP daemons and OpenVPN TCP daemons listen on 2 separate interfaces, they have to listen on the same interface. If you do want to change this you can use iptables to redirect traffic on a specific port and interface internally to the correct port and interface.
Disable multi-daemon mode and use only TCP or UDP
Because the OpenVPN 2 code base is single-thread, meaning that an OpenVPN process can run on only 1 CPU core and doesn't know how to make use of multi-core systems, the OpenVPN Access Server comes with the ability to launch multiple OpenVPN daemons at the same time. Ideally there would be one OpenVPN daemon for every CPU core. But there's more involved. To make it possible for OpenVPN clients to establish a connection via the UDP protocol and via the TCP protocol, there are additional OpenVPN daemons necessary. In the case of the OpenVPN Access Server this means we launch 1 TCP and 1 UDP daemon per CPU core. On a system with 4 CPU cores this means there are in total 8 daemons running, 2 per CPU core; 1 TCP and 1 UDP. The Access Server performs a sort of internal load balancing. When connections come in, the Access Server decides which CPU core and thus which OpenVPN daemon is least busy, and connects you to that daemon.
In some rare cases it can be desirable or necessary to turn off multi-daemon mode and simply launch one TCP or UDP OpenVPN daemon, and handle all incoming OpenVPN tunnel connections through one single OpenVPN daemon. This is possible but has some possibly negative side effects. For one, service forwarding is used to field incoming browser requests on the TCP OpenVPN daemons on port TCP 443, and internally redirect them to the actual web services port TCP 943 internally. Disabling the TCP OpenVPN daemons and running with only one UDP daemon means normal access to the web services has now been blocked and you have to manually type the correct port number in the URL like so: https://vpn.yourserver.com:943/. Another side effect is that on restrictive networks where UDP connections are blocked, but TCP 443 (the default HTTPS port) is still open, then while running only an UDP OpenVPN daemon you could be unable to make a connection from such a restrictive network, whereas with default settings it would likely have worked. And if you decide to use TCP daemons only, then the TCP Meltdown phenomenon may adversely affect your connection. So in short; the defaults are the best, but if you want to, you can disable multi-daemon mode.
To disable multi-daemon mode and use only 1 TCP daemon:
./sacli --key "vpn.server.daemon.enable" --value "false" ConfigPut ./sacli --key "vpn.daemon.0.listen.protocol" --value "tcp" ConfigPut ./sacli --key "vpn.server.port_share.enable" --value "true" ConfigPut ./sacli start
To disable multi-daemon mode and use only 1 UDP daemon:
./sacli --key "vpn.server.daemon.enable" --value "false" ConfigPut ./sacli --key "vpn.daemon.0.listen.protocol" --value "udp" ConfigPut ./sacli --key "vpn.server.port_share.enable" --value "false" ConfigPut ./sacli start
Reset multi-daemon mode and number of TCP/UDP daemons
In the commands below we are using the sacli GetNCores command to get the amount of CPU cores detected on this system, and then use that to configure the amount of TCP daemons and amount of UDP daemons to spawn when Access Server starts. The characters around the ./sacli GetNCores command in the commands shown below are backticks , not single quotes, and this makes a significant difference in how the command is executed. We recommend copying and pasting the commands to be sure the commands are executed properly. We are also resetting the default setting here to use multi-daemon mode where multiple OpenVPN daemons are launched.
Restore the default of using multi-daemon mode, with the amount of processes same as CPU cores (recommended):
./sacli --key "vpn.server.daemon.enable" --value "true" ConfigPut ./sacli --key "vpn.daemon.0.listen.protocol" --value "tcp" ConfigPut ./sacli --key "vpn.server.port_share.enable" --value "true" ConfigPut ./sacli --key "vpn.server.daemon.tcp.n_daemons" --value "`./sacli GetNCores`" ConfigPut ./sacli --key "vpn.server.daemon.udp.n_daemons" --value "`./sacli GetNCores`" ConfigPut ./sacli start
Reset OpenVPN web services and daemons to defaults
Aside from offering you the chance to undo any wrong settings that have accidentally locked out of access to the web services, these steps are also vital when you have restored a backup of an OpenVPN Access Server configuration from one system to another system, and the interface names that were on the old server are not the same as the new server. If for example on the old server you have it configured to listen only to eth0, but the new server only has ens192, then you have a problem since the Access Server will be unreachable and you can't access the Admin UI to correct these settings. With the commands below these settings related to interface names and such are all reset to "all", meaning that the OpenVPN Access Server will simply listen to all available interfaces, and at the default ports (TCP 443, TCP 943, UDP 1194).
Reset web services, service forwarding, and OpenVPN daemons to default ports and listen on all interfaces:
./sacli --key "admin_ui.https.ip_address" --value "all" ConfigPut ./sacli --key "admin_ui.https.port" --value "943" ConfigPut ./sacli --key "cs.https.ip_address" --value "all" ConfigPut ./sacli --key "cs.https.port" --value "943" ConfigPut ./sacli --key "vpn.server.port_share.enable" --value "true" ConfigPut ./sacli --key "vpn.server.port_share.service" --value "admin+client" ConfigPut ./sacli --key "vpn.daemon.0.server.ip_address" --value "all" ConfigPut ./sacli --key "vpn.daemon.0.listen.ip_address" --value "all" ConfigPut ./sacli --key "vpn.server.daemon.udp.port" --value "1194" ConfigPut ./sacli --key "vpn.server.daemon.tcp.port" --value "443" ConfigPut ./sacli start
The OpenVPN Access Server uses XML-RPC internally between web services and core component, and between OpenVPN Connect Client for Windows and Macintosh, and the XML-RPC interface on the web services (at /RPC2 URL). On the OpenVPN Connect Client it is only used in a limited fashion to check credentials to see if they are valid, and to obtain a user-locked profile for connecting, when the Connect Client is using a server-locked profile. If the XML-RPC interface setting is changed to full support, either in the Client Settings page in the Admin UI, or via the command line with the configuration option shown below, then the Access Server can be fully remotely controlled using XML-RPC calls instead. Authentication is done via HTTP basic authentication over a secure SSL connection. To retrieve a user-locked profile a standard user's credentials are sufficient, but for other functions only an admin user's credentials are sufficient.
We do not provide documentation or support for the XML-RPC interface.
However, we can give you the tools to determine what calls to make and how, and you can use that information to use or make XML-RPC capable programs that can remotely control the Access Server.
To see XML-RPC calls on the command line with the sacli VPNSummary function:
OPENVPN_AS_DEBUG_XML=1 ./sacli VPNSummary
You will get a result which shows the XML query, and the response. This system of getting information works for pretty much every sacli function. And sacli controls just about everything that the Access Server can do.
To change the XML-RPC function support:
./sacli --key "xmlrpc.relay_level" --value <NUMBER> ConfigPut ./sacli start
Where <NUMBER> is:
- 0 - disable the XML-RPC API via web services entirely, and will break server-locked profile type connections.
- 1 - enable XML-RPC API via web services in a limited fashion, for server-locked profile type connections only (default).
- 2 - fully enable XML-RPC API via web services, allows full remote control of the Access Server's function.
Logging of XML-RPC API calls is by default not enabled, but can be enabled with an XML-RPC debug flag.