In this page you find:
Changed in version 2.5: The VPN module GUI has been partly redesigned.
New in version 2.5.: L2TP support
A VPN allows two separated local networks to directly connect to each other over potentially unsafe networks such as the Internet. All the network traffic through the VPN connection is securely transmitted inside an encrypted tunnel, hidden from prying eyes. Such a configuration is called a Gateway-to-Gateway VPN, or Gw2Gw VPN for short. Similarly, a single remote computer somewhere on the Internet can use a VPN tunnel to connect to a local trusted LAN. The remote computer, sometimes called a Road Warrior, appears to be directly connected to the trusted LAN while the VPN tunnel is active.
The Endian UTM Appliance supports the creation of VPNs based either on the IPsec protocol, which is supported by most operating systems and network equipment, or on the OpenVPN service.
A user friendly OpenVPN client for Microsoft Windows, Linux, and MacOS X can be downloaded from the Endian Network.
The Endian UTM Appliance can be set up either as an OpenVPN server or as a client, and even play both roles at the same time, in order to create a network of OpenVPN-connected appliances. The menu items available in the sub-menu are the following:
New in version 2.5: Support for L2TP
Changed in version 2.5: Moved the management of all users under a submenu.
Changed in version 2.5.1: Moved IPsec and L2TP under the same menu
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.
The page opens with the summary of the current server configuration, separated into two boxes: Global settings and Connection status and control. Two additional tabs give access to Advanced settings and to the VPN client download.
Whenever a change to the configuration of the OpenVPN server occurs or the way a user interacts with the other users is modified (e.g., by altering the Networks behind client option, see below), the OpenVPN server must be restarted, for the changes to be propagated to all users. This necessity is shown after some modification by a small box carrying a message that remembers to restart the server. The connected clients will be disconnected and automatically reconnected after a short timeout, usually without noticing the interruption.
This page shows two boxes: one that allows to set up some global settings, and an informative one that shows the connected clients.
The box on the top shows the current settings, that can be changed at will right from there, by simply modifying the following options, which are all related to the bridged OpenVPN. When the choice is the use of a routed VPN setup, however, there will be only one option available: VPN Subnet.
Tick this option to run the OpenVPN server in bridged mode, i.e., within one of the existing zones.
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.
The last possible IP address in the network of the selected zone that should be used for the OpenVPN clients.
Traffic directed to this IP pool has to be filtered using the VPN firewall.
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 Accounts tab.
Connection status and control
The box at the bottom shows a list of the currently connected clients, although the list will be empty until the OpenVPN server is running and clients have been created and have accessed the OpenVPN server. This box is identical to the one in Menubar ‣ Status ‣ OpenVPN connections, and contains for each client, its name, assigned and real IP address, the traffic (received and transmitted) in bytes, the connection time, the uptime, and the only possible action:
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:
More information about the MTU size.
In this tab, three boxes allow to specify advanced settings for the OpenVPN server. Among other settings, certificate-based authentication (as opposed to password-based) can be set here.
For a normal use these settings can be left at their default values.
The first box contains some global settings about the daemon:
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: An option to allow multiple connections.
Global push options
In the second box the network setting sent to the client can be modified. Each option, after having been changed, should be enable by ticking the respective checkbox.
The options Push these nameservers and Push domain only work for clients running the Microsoft Windows operating system.
The last box concerns the choice of the authentication method among the three available, which also determines the configuration options available.
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.
By clicking on the Download CA certificate link, the public certificate of this OpenVPN server is downloaded. It is needed by the clients to verify the authenticity of the server they are connecting to. Furthermore, a click on the Export CA as PKCS#12 file link download the certificate in PKCS#12 format (which should be kept private), which can be imported into any OpenVPN server that should be used as a fallback server.
Finally, should this system be a fallback system, two further option are available:
X.509 certificate and X.509 certificate & PSK (two factor)
When configuring the X.509-certificate-based authentication method (either certificate only or certificate plus username and password), the configuration becomes a bit more complicated. It is assumed (and required) that an independent certificate authority (CA) be employed for this purpose. It is neither possible nor desired to host such a certificate authority on Endian UTM Appliance.
It is necessary to generate and sign certificates for the server and for every client using the chosen certificate authority. The certificates type must be explicitly specified and be one of “server” and “client” in the “Netscape certificate type” field.
The server certificate file in PKCS#12 format must be uploaded in this section (specify the Challenge password that has been specified to the certificate authority before or during the creation of the certificate).
The client certificates need to have the common name fields equal to their OpenVPN user names.
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!
Finally, a revocation list (CRL) can be uploaded, in case a client certificate has been lost, to revoke that client certificate on the CA.
In this page appears the list of the Endian UTM Appliance‘s connections as OpenVPN clients, i.e., all tunnelled connections to remote OpenVPN servers. For every connection, the list reports the status, the name, any additional option, a remark, and the actions available. The status is closed when the connection is disabled, and established when the connection is enabled. Beside to enable and to disable a connection, the available actions are to edit or delete it. In the former case, a form will open, that is the same as the one that opens when adding a connection (see below) in which to see and modify the current settings, whereas in the latter case only deletion of that profile from the Endian UTM Appliance is permitted.
The creation of a new OpenVPN client connections is straightforward and can be done in two ways: Either click on the Add tunnel configuration button and enter the necessary information about the OpenVPN server to which to connect (there can be more than one) or import the client settings from the OpenVPN Access Server by clicking on Import profile from OpenVPN Access Server.
New in version 2.5: Import from Access Server.
Add tunnel configuration
There are two types of settings that can be configured for each tunnel configuration: The basic one includes mandatory options for the tunnel to be established, while the advanced one is optional and normally should be changed only if the OpenVPN server has a non-standard setup. To access the advanced settings, click on the >> button next to the Advanced tunnel configuration label. The basic settings are:
Advanced tunnel configuration
In this box, that appears when clicking on the >> button in the previous box, additional options can be modified, though the values in this box should be modified only if the server side has not been configured with standard values.
One or more (one per line) fallback OpenVPN servers in the same format used for the primary server, i.e., myvpn.example.com:port:protocol. The port and protocol values default to 1194 and udp respectively when omitted. If the connection to the main server fails, one of these fallback servers will take over.
The protocol must be written in lowercase letters.
If the Endian UTM Appliance can access the Internet only through an upstream HTTP proxy, it can still be used as an OpenVPN client in a Gateway-to-Gateway setup, but the TCP protocol for OpenVPN must be selected on both sides. Moreover, the account information for the HTTP upstream proxy must be provided in the text fields:
Once the connection has been configured, a new box at the bottom of the page will appear, called TLS authentication, from which to upload a TLS key file to be used for the connection. These options are available:
Import profile from OpenVPN Access Server
The second possibility to add an account is to directly import the profile from an OpenVPN Access Server: In this case, the following information must be provided:
The URL of the OpenVPN Access Server.
Note that the Endian UTM Appliance only supports XML-RPC configuration of the OpenVPN Access Server, therefore a URL input here has the form: https://<SERVERNAME>/RPC2.
The IPsec page contains two tabs (IPsec and L2TP), that allow to set up and configure the IPsec tunnels and to enable the L2TP support, respectively.
The IPsec tab contains three boxes: First, Global settings, serves to enable and configure IPsec. The second, Connection status and control, shows all the connections and allows to add a new one. Finally, the Certificate authorities box allows to manage the certificates. Note that by adding a new connection, new boxes will be shown, that help in the configuration of the connections’ types and of their options.
IPsec in a nutshell.
IPsec is a generic standardised VPN solution, in which the encryption and the authentication tasks are carried out on the OSI layer 3 as an extension to the IP protocol. Therefore, IPsec must be implemented in the kernel’s IP stack. Although IPsec is a standardised protocol and it is compatible to most vendors that implement IPsec solutions, the actual implementation may be very different from vendor to vendor, sometimes causing severe interoperability issues.
Moreover, the configuration and administration of IPsec is usually quite difficult due to its complexity and design, while some particular situations might even be impossible to handle, for example when there is the necessity to cope with NAT.
Compared to IPsec, OpenVPN is easier to install, configure, and manage. The Endian UTM Appliance implements an easy to use administration interface that supports different authentication methods. It is suggested to use IPsec only if absolutely needed, for example to support existing IPsec installations or when dealing with devices that do not support OpenVPN, because of interoperability problems that may arise, while the use of OpenVPN is encouraged in all other cases, especially if there is the necessity to work with NAT.
In this box can be done the configuration of the main parameters for the IPsec configuration:
Connection status and control
Here there is a list of accounts and their connection status. The list shows the name, type, common name, remark, and status of each connection. New connections are added by clicking on the Add button (see below). Possible actions on each connection are: To restart , to enable or disable , to edit or to delete it.
In the last box of the IPsec main page, the root and host certificates are shown and the existing certificates can be managed. If root and host certificates have yet to be generated, a “Not present” message is shown.
To erase an already created Certificate, click on this button at the bottom of the page.
Please note that by resetting the root certificates, not only the certificates but also certificate-based connections will be erased.
Generate root/host certificates
The following information shall be entered to create new host and root certificates.
The certificates are created after clicking on the Generate root/host certificates button. The process can take up to several minutes to complete.
Instead of generating new certificates, a previously created PKCS12 certificate file can be upload using the lower box of the page.
How to create a Net-To-Net VPN with IPsec using certificate authentication.
Problem: Connect LocalFW to CoreFW using IPsec.
Add a tunnel/Connection type
Upon clicking on Add under Connection status and control, a page will open from which to select either a Host-to-Net Virtual Private Network, a Net-to-Net Virtual Private Network, or an L2TP Host-to-Net Virtual Private Network. After the choice of the type of connection, and one click on the Add button, the page for the connection editor will open, that contains two boxes grouping the types of options: Connection configuration and Authentication.
The first box is used to configure the network parameters:
The action to perform if a peer disconnects. Available choices from the drop-down menu are to Clear, to Hold, or to Restart the peer.
Unlike in other places, clicking or moving the mouse over the ? will not provide a tooltip, but open a web page with a detailed description of the functionalities of the dead peer detection.
This box serves to configure the authentication.
Enter a pass phrase to be used to authenticate the other side of the tunnel. Choose this option for a simple Net-to-Net VPN.
Do not use PSKs to authenticate Host-to-Net connections!
In this page, that opens upon defining and saving a new connection, some advanced setting for that connection can be defined.
Unexperienced users should not change the following advanced settings!
Tick this box to enable IKE aggressive mode. It is suggested NOT to do so.
Changed in version 2.5: This option was removed from the 2.5 version.
On the website help.endian.com, the following tutorials are available:
L2TP, the Layer 2 Tunnelling Protocol, is described in RFC 2661. In a nutshell, it is a protocol that allows a tunnel connection that carries PPP packets. It is used to support VPN connections using IPSec.
The following options are available to configure L2TP.
On the website help.endian.com, there are several tutorials available, that help in the set up of the Endian UTM Appliance as IPsec server and smartphones as clients:
Changed in version 2.5: This configuration page was moved from Menubar ‣ VPN ‣ OpenVPN server ‣ Accounts and its layout was improved.
The box in this page contains the list of OpenVPN users, which is initially empty. The only available action is therefore to Add new User, while the list contains the list of the accounts already defined with some information on it: The account’s name, a remark, whether it is an OpenVPN or L2TP user, the networks used by the account, its status and the available actions.
Click on Add new User to add a VPN account. In the form that will show up, the following options can be specified for each user:
Under the VPN protocols panel, two checkboxes allow to chose the protocol used for the VPN connection:
Tick this checkbox to allow the L2TP protocol to be used.
This option can not be selected if no L2TP tunnel has yet been configured. In such a case, an informative message appears as a hyperlink: Upon clicking on it, the IPsec connection editor opens. Once done, it will be possible to allow a VPN user to connect using the L2TP Protocol.
Right below, it is possible to specify more advanced settings for each of the protocols that the user shall use. A click on the Advanced Settings hyperlink shows two more hyperlinks: Clicking on each of them reveals a new panel in which to configure further settings for the connection.
When planning to have two or more branch offices connected through a Gateway-to-Gateway VPN, it is good practice to choose different subnets for the LANs in the different branches. For example, one branch might have a GREEN zone with the 192.168.1.0/24 subnet while the other branch uses 192.168.2.0/24. Using this solution, several possible sources for errors and conflicts will be avoided. Indeed, several advantages come for free, including: The automatic assignment of correct routes, without the need for pushing custom routes, no warning messages about possibly conflicting routes, correct local name resolution, and easier WAN network setup.
Enter search terms or a module, class or function name.