Virtual private network (VPN) service with OpenVPN

Zentyal integrates OpenVPN [2] to configure and manage virtual private networks. In this section you will see how to configure OpenVPN, who has the following advantages:

  • Authentication using public key infrastructure.
  • SSL-based encryption technology.
  • Clients available for Windows, Mac OS and Linux.
  • Easier to install, configure and maintain than IPSec, another open source VPN alternative.
  • Allows to use network applications transparently.
[2]http://openvpn.net/

Configuration of a OpenVPN server with Zentyal

Zentyal can be configured to support remote clients (sometimes known as road warriors). This means a Zentyal server acting as a gateway and VPN server, with multiple local area networks (LAN) behind it, allows external clients (the road warriors) to connect to the local network via the VPN service.

Zentyal and remote VPN clients

Zentyal and remote VPN clients

The goal is to connect the data server with other 2 remote clients (Business manager and Client) and also the remote clients to each other.

First, you need to create a Certification Authority and individual certificates for the two remote clients. You need to explicitly create an unique certificate for each user that will connect to the VPN through Certification Authority ‣ General.

Note that you also need a certificate for the VPN server. However, Zentyal will issue this certificate automatically when new VPN server is created.

In this scenario, Zentyal acts as a Certification Authority.

Zentyal and remote VPN clients

Server certificate (blue underline) and client certificate (black underline)

Once you have the certificates, then configure the Zentyal VPN server by selecting Create a new server. The only value you need to enter to create a new server is the name. Zentyal ensures the task of creating a VPN server is easy and it sets the configuration values automatically.

Zentyal and remote VPN clients

New VPN server created

The following configuration parameters are added automatically and can be changed if necessary: port/protocol, certificate (Zentyal will create one automatically using the VPN server name) and network address. The VPN network addresses are assigned both to the server and the clients. If you need to change the network address you must make sure that there is no conflict with a local network. In addition, you will automatically be notified of local network detail, i.e. the networks connected directly to the network interfaces of the host, through the private network.

As you can see, the VPN server will be listening on all external interfaces. Therefore, you must set at least one of your interfaces as external at Network ‣ Interfaces. In this scenario only two interfaces are required, one internal for LAN and one external for Internet.

If you want the VPN clients to connect between themselves by using their VPN addresses, you must enable the option Allow connections among clients.

In most of the cases you can leave the rest of the configuration options with their default values.

_images/vpn-03-server-config.png

VPN server configuration

In case more advanced configuration is necessary:

VPN address:
Indicates the virtual subnet where the VPN server will be located and the clients it has. You must take care that this network does not overlap with any other and for the purposes of firewall, it is an internal network. By default 192.168.160.1/24, the clients will get addresses .2,*.3*, etc.
Server certificate:
Certificate that will show the server to its clients. The Zentyal CA issues by default a certificate for the server, with the name vpn-<yourvpnname>. Unless you want to import an external certificate, usually you maintain this configuration.
Client authorization by common name:
Requires that the common name of the client certificate will start with the selected string of characters to authorize the connection.
TUN interface:
By default a TAP type interface is used, more similar to a bridge of Layer 2. You can also use a TUN type interface more similar to a IP node of Layer 3.
Network Address Translation: (NAT)
It is recommended to enable this translation if the Zentyal server that accepts the VPN connections is not a default gateway of the internal networks to which you can access from the VPN. Like this the clients of these internal networks respond to Zentyal’s VPN instead of the gateway. If Zentyal server is both the VPN server and the gateway (most common case), this option is indifferent.
_images/vpnnat.png

VPN server using NAT to become the gateway for the VPN connection

Redirect gateway:
If this option is not checked, the external client will access through the VPN to the established networks, but will use his/her local connection to access to Internet and/or rest of the reachable networks. By checking this option you can achieve that all the traffic of the client will go through the VPN.

The VPN can also indicate name servers, search domain and WINS servers to overwrite those of the client. This is specially useful in the case you have redirected the gateway.

After having created the VPN server, you must enable the service and save the changes. Later you must check in Dashboard that the VPN server is running.

_images/vpn-04-widget.png

Widget of the VPN server

After this, you must advertise networks, i.e. routes between the VPN networks and between other networks known by your server. These networks will be accessible by authorised VPN clients. To do this, you have to enable the objects you have defined, see High-level Zentyal abstractions, in the most common case, all internal networks. You can configure the advertised networks for this VPN server through the interface of Advertised networks.

_images/vpn-05-advertised-networks.png

Advertised networks of your VPN server

Once you have done this, it is time to configure the clients. The easiest way to configure a VPN client is by using the Zentyal bundles - installation packages that include the VPN configuration file specific to each user and optionally, an installation program. These are available in the table at VPN ‣ Servers, by clicking the icon in the column Download client bundle. You can create bundles for Windows, Mac OS and Linux clients. When you create a bundle, select those certificates that will be used by the clients and set the external IP addresses to which the VPN clients must connect.

As you can see the image below, you can have one main VPN server and up to two secondary servers depending on the Connection strategy when defining the connection order, or you can also try a random order.

Moreover, if the selected system is Windows, you can also add an OpenVPN installer. The Zentyal administrator will download the configuration bundles to the clients using the most appropriate method.

_images/vpn-06-windows-bundle.png

Download client bundle

A bundle includes the configuration file and the necessary files to start a VPN connection.

You now have access to the data server from both remote clients. If you want to use the local Zentyal DNS service through the private network, you need to configure these clients to use Zentyal as name server. Otherwise, it will not be possible to access services by the hosts in the LAN by name, but only by IP address. Also, to browse shared files from the VPN [3] you must explicitly allow the broadcast of traffic from the Samba server.

You can see the users currently connected to the VPN service in the Zentyal Dashboard. You need to add this widget from Configure widgets, located in the upper part of the Dashboard.

_images/vpn-07-dashboard-widget.png

Widget with connected clients

[3]For additional information about file sharing go to section Domain Controller and File Sharing

Configuration of a VPN server for interconnecting networks

In this scenario two offices in different networks need to be connected via private network. To do this, you will use Zentyal as a gateway in both networks. One will act as a VPN client and the other as a server. The following image clarifies the scenario:

Zentyal as VPN server vs. Zentyal as a VPN client

Office interconnection with Zentyal through VPN tunnel

The goal is to connect multiple offices, their Zentyal servers and their internal networks so that one, single network infrastructure can be created in a secure way and through Internet. To do this you need to configure a VPN server similarly as explained previously.

However, you need to make two small changes. First, enable the Allow Zentyal-to-Zentyal tunnels to exchange routes between Zentyal servers. And then, introduce a Password for Zentyal-to-Zentyal tunnels to establish the connection between the two offices in a safer environment. Take into account that you need to advertise the LAN networks in Advertised Networks.

Another important difference is the routing information exchange, in the roadwarrior to server scenario described previously, the server pushes network routes to the client. In the server to server scenario, routes are exchanged in both directions, and propagated to other clients using the RIP [4] protocol. Therefore, you can, as a client, configure the Advertised Networks that will be propagated to the other nodes.

_images/vpn-08-zenTozen.png

Zentyal as VPN client

You can configure Zentyal as a VPN client at VPN ‣ Clients. You must give a name to the client and enable the service. You can configure the client manually or automatically by using the bundle provided by the VPN server. If you do not use the bundle, you must introduce the IP address and protocol-port for the server accepting requests. The tunnel password and certificates used by the client will also be required. These certificates must have been created by the same certification authority the server uses.

_images/vpn-09-upload-client-bundle.png

Automatic client configuration using VPN bundle

When you Save changes in the Dashboard, you can see a new OpenVPN™ daemon running as a client and the objective connection directed towards another Zentyal server configured as a server.

_images/vpn-10-client-dashboard-widget.png

Dashboard of a Zentyal server configured as a VPN client

Warning

The propagation of routes can take a few minutes.

[4]http://www.ietf.org/rfc/rfc1058