IPsec¶

To enable IPsec on the UTM, the switch at the top of the page should be set to Enabled. If it is grey, click on it to start the service.

The IPsec module is divided into two pages: The first one is Configuration, in which various common options for all tunnels can be configured, also for debugging purposes; the second one is Connections, which shows all the defined connections and allows to manage them.

IPsec, L2TP, and XAuth 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 interoperability issues.

Moreover, the configuration and administration of IPsec may become 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. However, mobile devices rely on IPsec, thus the UTM implements an easy-to-use administration interface for IPsec, that supports different authentication methods and also two-factor authentication when used together with L2TP or XAuth.

Indeed, IPsec is used to authenticate clients (i.e., tunnels) but not users, so one tunnel can be used by only one client at a time.

L2TP and XAuth add user authentication to IPsec, therefore many clients can connect to the server using the same encrypted tunnel and each client is authenticated by either L2TP or XAuth.

An additional option is available when using XAuth and is called XAuth hybrid mode, which only authenticates the user.

Configuration¶

IPsec settings

In this box a few global IPsec options can be set, namely the certificates used for the IPsec tunnels, the Dead Peer Detection, and numerous debugging options.

Roadwarriors virtual IP pool: The IP address pool from which all roadwarrior connections receive their IP address.

Dead Peer detection

Ping delay (in seconds): The amount of seconds between two successive pings, used to detect whether the connection is still active.
Timeout interval (in seconds) - IKEv1 only: The maximum amount in seconds of the exchange interval for the IKEv1 protocol.

Hint

IKEv2 does not need a timeout interval, as it is capable of detecting when the other endpoint does not reply and which actions to take.

server certificate

Certificate configuration: This drop-down menu is used to select the method of creation of a new certificate. The available options are:

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.

When a certificate has been chosen, below the Certificate configuration drop-down menu appear the name of the currently used certificate and the View details link. The latter will show all information about the certificate when clicked.

Debug options

Debug options are rather advanced settings and usually it is not needed to enable them for normal use, because they will increase the number of events and messages recorded in the log and therefore increase the log file’s size.

Each of the debug options refers to a subsystem of IPsec, hence they can be selectively activated to debug only a given problem. For example, if the connection apparently suffers from IKE-related problem, activate option IKE network communication, restart the connection and check the log to search for the more precise and technical messages that this option will produce.

Connections¶

In this table are shown all the existing IPsec connections, with the following information:

Name. The name given to the connection.
Type. What kind of tunnel is used.
Common Name. The name of the certificate used to authenticate the connection.
Remark. A comment about the connection.
Status. Whether the connection is either Closed, Connecting or Established.
Actions. The possible operations that can be made on each tunnel.

Note

The information icon does not appear if the connection is closed.

Hint

When a connection is reset from the UTM, it is necessary for the client to reconnect in order to establish the connection.

Upon clicking on Add new connection, a panel will appear, which contains all options needed to set up a new IPsec connection.

Add new connection

Name

The name of the connection.

Remark

A comment for the connection.

Connection type

There are four different connection modalities can be chosen for the IPsec tunnel:

Host-to-Net. The client connecting to the IPsec server on the UTM is a roadwarrior user (single device).
Net-to-Net. The client is another IPsec VPN router/gateway device. This connection is used to connect two different devices at separate locations together so that the internal networks (and devices on them) can communicate with each other. This can be used to connect to another UTM or (more commonly) a different third-party IPsec VPN device.
L2TP Host-to-Net. The client is a roadwarrior user (single device) that will connect using L2TP with IPSec. This connection is required in order to support users connecting via L2TP.
XAuth Host-to-Net. The client is a roadwarrior user (single device) that will connect using XAuth over IPSec. This connection is required in order to support users connecting via XAuth.

Most of the options available for each connection are shared between the different type. There is one more option available for Net-to-Net connections.

Authentication

Authentication Type

The option selected from the drop-down menu determines how the client’s authentication is carried out. Available values are:

Password (PSK). The client shall supply the password specified in the Use a pre-shared key textfield situated on the right.
Peer is identified by either IPV4_ADDR, FQDN, USER_FQDN or DER_ASN1_DN string in remote ID field. The client is authenticated by its IP address, domain name, or by other unique information of the IPsec tunnel.
Use an existing certificate. The certificate chosen from the drop-down menu on the right shall be used.
Generate a new certificate. Additional options will be shown to create a new certificate.
Upload a certificate. Select from the local workstation a certificate to use.
Upload a certificate request. Select from the local workstation a certificate request to obtain a new certificate.
XAUTH hybrid. Only available for XAuth Host-to-Net connections: The user needs to authenticate, while the encryption tunnel must not.

Local

Local ID: A string that identifies the client within the local network.
Interface: The interface through which the host is connecting.
Local subnets: The local subnets that will be accessible from the client.

Note

Mobile devices running iOS can not properly connect via XAuth to the UTM if this value is not set, therefore the special subnet 0.0.0.0/0’ is automatically added when the `Connection type is set to XAuth.

Remote

Remote ID: The ID that identifies the remote host of the connection.
Remote host/IP: The IP or FQDN of the remote host.

Note

When a hostname is supplied in this option, it must match the local ID of the remote side.
Remote subnet: Only available for Net-to-Net connections, it specifies the remote subnet.

Hint

When using IKEv2 it is possible to add more than one subnet.
Roadwarrior virtual IP: The IP address specified in the textfield will be assigned to the remote client.

Hint

This IP address must fall within the pool defined in the IPsec settings below.

Note

This option is available neither for Net-to-Net connections, nor for L2TP Host-to-Net connections; in the latter case it is L2TP that takes charge of IP address assignment to clients.

Options

Dead peer detection action: 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.

Advanced

In the Advanced panel, additional options are available, to choose and configure the desired encryption algorithms used to set up the tunnel.

Warning

The values of the algorithms chosen here must match exactly those that are defined on the other peer, otherwise the connection might not be established correctly.

Internet Key Exchange protocol configuration

IKE encryption: The encryption methods that should be supported by IKE.

Hint

Click on the drop-down menu to choose one algorithm at the time. It is also possible to write one or more letter, to filter among the available algorithms and the click on desired one.
Accept only chosen encryption algorithms: Tick the checkbox to activate the so-called strict mode for IKE: in this mode only the selected algorithm will be accepted upon connection.
IKE integrity: The algorithms that should be supported to verify the integrity of packets.
IKE group type: The IKE group type.
IKE lifetime: How many hours are the IKE packets valid.
IKE version: Choose from the drop-down menu which version should the connection use. Available values are IKEv1, IKEv2, and Both IKEv1 and IKEv2.

Encapsulating security payload configuration

ESP encryption: The encryption methods that should be supported by the ESP.
Accept only chosen encryption algorithms: Tick the checkbox to activate the so-called strict mode for ESP: In this mode only the selected algorithm will be accepted upon connection.
ESP integrity: The algorithms that should be supported to verify the integrity of packets.
ESP group type: The ESP group type.
ESP lifetime: How many hours should an ESP key be valid.

Additional options

Negotiate payload compression

Tick the checkbox to allow payload compression.

Mode config

This option determines how a virtual IP is assigned to the client, either push or pull. This option is relevant for IKEv1 only.

Connection startup

This option appears only if the IPsec connection is of type net-to-net. Three options are available for this option, which will determine the tunnel’s behaviour upon connection:

Brings the connection up immediately. The connection starts immediately after the tunnel configuration is loaded into IPsec configuration. This correspond to the auto=start configuration value.
Starts the connection if traffic is detected. The connection is loaded, but the actual connection will be established as soon as some traffic is detected from the tunnel. This correspond to the auto=route configuration value.
Loads the connection without starting it. The connection is only loaded but it will not start. This correspond to the auto=add configuration value.

Hint

If no IPsec traffic is detected even if the connection is established, use the auto=route option, i.e., the second option.