In this page you find:
Changed in version 3.0: The OpenVPN server now supports multiple instances.
When configured as an OpenVPN server, the Endian UTM Appliance can accept remote connections from the uplink and allow a VPN client to be set up and work as if it were a local workstation or server.
Starting with version 3.2, the OpenVPN server deployed on the Endian UTM Appliance allows the simultaneous presence of several instances. Each server will listen to one different port, accepting incoming connections on that port only. Moreover, when the hardware on which Endian UTM Appliance is installed has multiple CPU cores, every instance may be assigned more that one core, thus resulting in an increase of the throughput and data processing of that instance. It is nevertheless also possible to have multiple instances of OpenVPN running on a device equipped with a single-core CPU, though this results in the CPU carrying the load of all instances.
The OpenVPN server settings page is composed of two tabs: Server configuration and VPN client download.
This page shows a switch Enable OpenVPN server 
, that will
start the OpenVPN server and all services related to it (like e.g.,
the VPN firewall if enabled) once clicked. Below,
there is one box, OpenVPN settings, that allows to set up some
global settings. Right below, a link allows to define a new server
instance while at the bottom of the page there’s the list of the
available OpenVPN servers running on the Endian UTM Appliance, if any has
already been defined. The list shows the following data about each
OpenVPN server instance defined: The name, remark, and details about
the configuration, namely: The port on which it is listening, the
protocol, the type of device, and the type of network. Finally, the
actions available are:
- the server is active or stopped.
- modify the server’s configuration
- remove the configuration and the server.Note
When starting the OpenVPN server for the first time, the root and host certificates are generated automatically.
The box on the top shows the current OpenVPN settings, which concern the authentication method, and are:
There are three available authentication methods to connect clients to the OpenVPN server running on the Endian UTM Appliance:
Warning
When employing certificate-only authentication, a client with a valid certificate will be granted access to the OpenVPN server even if it has no valid account!
Endian UTM Appliance‘s default method is PSK (username/password): The client authenticates using username and password. To use this method, no additional change is needed, while the other two methods are described below.
This drop-down menu is used to select the method of creation of a new certificate. The available options are:
Generate a new certificate. Create a new certificate from scratch. This option is only available if no host certificate has already been generated. A form will open where to specify all options necessary to create a new certificate. These are the same found in the new certificates generation editor, with two slight changes: Common name becomes System hostname and Organizational unit name becomes Department name.
Use selected certificate. Select one certificate from those available, shown on the right-hand side of the drop-down menu. It is possible to see the full details of this certificate by clicking on the View details hyperlink.
Hint
The name of the certificate selected appears right above the hyperlink.
Use an existing certificate. A second drop-down menu on the left allows to select a certificate that has already been created and stored on the Endian UTM Appliance.
Upload a certificate. By clicking on the Browse... button that appears underneath the drop-down menu it will be possible to select from the workstation and to upload an existing certificate. The password for the certificate, if needed, can be provided in the textfield on the right-hand side.
Upload a certificate signing request. The Browse... button that appears underneath the drop-down menu can be clicked to select from the workstation and upload an existing certificate signing request. The validity of the certificate in days can be provided in the textfield on the right-hand side.
The list of already defined OpenVPN instances is shown in this panel, above which is present the Add new OpenVPN server instance byperlink. A click on this link will open an editor in which to provide all the necessary configuration values for a new VPN instance.
Note
When the number of OpenVPN instances in greater than the cores, a yellow callout informs that the performances may degrade.
In the editor, the following configuration options are shown.
Tick this option to run the OpenVPN server in bridged mode, i.e., within one of the existing zones.
Note
If the OpenVPN server is not bridged (i.e., it is routed), the clients will receive their IP addresses from a dedicated subnet. In this case, appropriate firewall rules in the VPN firewall should be created, to make sure the clients can access any zone, or some server/resource (e.g., a source code repository). If the OpenVPN server is bridged, it inherits the firewall settings of the zone it is defined in.
Routed and bridged OpenVPN server, static and dynamic.
When configuring a pool of IP addresses to be reserved for clients connecting via OpenVPN, it is necessary to keep in mind a few guidelines that help both the prevention of future malfunctioning and the cleaner and easier design and set up.
Before starting the configuration of the server, there is a golden rule to remember, concerning the implementation of the VPN multicore architecture: Regardless of the bridged or routed mode used for a multicore VPN server instance, the reservation of static IP addresses is neglected. In other words, a client connecting to this VPN server, will receive a dynamic IP address, even though in her configuration there is a static IP assignment.
The first choice is to define whether the OpenVPN server should act in routed or bridged mode. In the former case, it is necessary to define a suitable VPN subnet that will provide the IP addresses for the clients. The traffic directed to this subnet has to be filtered, if necessary, using the VPN firewall. In the latter case, the OpenVPN server is configured to consider the clients, upon connecting, as they were physically connected to that zone, i.e., the server bridges the client to one of the zones. In this case, a pool of IP addresses must be defined within that zone using the two option that appear right before this box. This pool must be entirely contained in the zone’s subnet and smaller than that one. It is also important to make sure that this pool does conflict with other pools defined in that zone, like e.g., a DHCP server.
In a bridged OpenVPN server it is possible to assign to some (or even to all) user a static IP address. When planning this possibility, it is a good practice that these static IP addresses do not belong to any of the IP pools defined in that zone, to prevent any conflicts of address and wrong routing. Traffic to this particular client can then be filtered using the VPN (or IPsec) user as source or destination of traffic in the Firewall rules.
In the Advanced options box, additional options can be configured.
Normally, one client is allowed to connect from one location at a time. Selecting this option permits multiple client logins, even from different locations. However, when the same client is connect twice or more, the VPN firewall rules do not apply anymore.
New in version 2.5.
Select from the drop-dow menu the modalities of the communications between clients of the OpenVPN server. This option is only available on single-process servers, i.e., on servers running only one instance of the OpenVPN server.
Changed in version 3.0: This option replaces the Don’t block traffic between clients option, which is equivalent to the new Allow direct connections option.
Note
In case of Appliances having multi-core CPUs, there is no selection possible and the option Filter connections in the VPN firewall is automatically activated
Note
The options Push these nameservers and Push domain only work for clients running the Microsoft Windows operating system.
The first time the service is started a new, self-signed CA certificate for this OpenVPN server is generated, an operation that may take a long time. After the certificate has been generated, it can be downloaded by clicking on the Download CA certificate link. This certificate must be used by all the clients that want to connect to this OpenVPN server, otherwise they will not be able to access.
After the server has been set up, it is possible to create and configure accounts for clients that can connect to the Endian UTM Appliance in the Authentication tab.
Troubleshooting VPN connections.
While several problem with VPN connections can be easily spotted by looking at the configuration, one subtle source of connections hiccups is a wrong value of the MTU size. The Endian UTM Appliance sets a limit of 1450 bytes to the size of the VPN’s MTU, to prevent problems with the common MTU value used by the ISP, which is 1500. However, some ISP may use a MTU value lower that the commonly used value, making the Endian MTU value too large and causing therefore connection issues (the most visible one is probably the impossibility to download large files). This value can be modified by accessing the Endian UTM Appliance from the CLI and following these guidelines:
See also
More information about the MTU size.
Click on the link to download the Endian VPN client for Microsoft Windows, MacOS X, and Linux from the Endian Network. A valid account is needed to download the client.