The P2P-based VPN solutions described here range from software following the classic model to a simple peer-to-peer model. The first approach uses two networks; in the second approach, the computer joins the network using an ID, and routing is done automatically.

Some of the projects also offer clients for other operating systems, including those for mobile devices. I looked at four candidates in all, and the tests were performed in a virtualized environment with suitable remote peers on the Internet.

Tinc [1] is the most senior of the programs being tested. Freelan [2] is still quite a young project, which offers clients for Linux, Windows, and Mac OS X. Students from the University of Florida have been instrumental in helping develop IPOP [3], which is similar to Tinc. ZeroTier [4] is the only candidate implemented as a pure peer-to-peer VPN.

Tinc

The Tinc project [1] has been around since 1998, and the most recent changes to the website were made in 2014. Tinc lets you establish a meshed VPN, which basically means that each node finds a path to every other node (Figure 1). Mutual authentication is based on RSA keys (2048 bits).

Figure 1: Tinc establishes a meshed VPN and tunnels encrypted UDP traffic.

Tinc defines logical networks, which each have a name; in the test, for example, the name was LM. The Tinc daemon expects a subfolder in each network with the same name under /etc/tinc. Additionally, the daemon expects a tinc.conf file in each folder. In the most basic case, the file only contains two entries: The logical name of the system within this network and the device that establishes the tunnels.

The tinc.conf man page lists additional options that, for example, determine which interface the service uses and whether the host should act as an intermediate node or not. The simplest form of the file looks like this:

Name = left
Device = /dev/net/tun

Tinc then expects another subfolder, hosts, in the /etc/tinc/LM folder. Below this is a separate folder with the host's logical name for each host involved.

Two hosts were used in the test – called left and right. Figure 2 shows the contents of left. The Subnet entry there describes the network that the node wants to route to itself; Address is the officially accessible address. Because the test was performed in a closed environment, this is an RFC address.

Figure 2: Each participating host receives its own configuration file in Tinc.

You can just leave out the key in the first attempt, because Tinc generates it later and automatically adds it. Thus, you only need to enter the first two lines on the left host during the initial setup. Next, you can call up:

tincd -n LM -K

If you don't enter a key length via the -K option, Tinc will use 2048 bits and then automatically enter the public key in /etc/tinc/LM/hosts/left. The -n option specifies the network name.

The /etc/tinc/LM/tinc-up file is also worth mentioning. It is an executable shell script with the job of activating the tunnel interface and giving it an IP address. This script for the left host looked as follows in the test:

#! /bin/bash
ifconfig $<INTERFACE> 192.168.22.1 \
  netmask  255.255.255.0

Attentive observers will certainly have noticed that the IP address is in a network whose netmask includes hosts more than the subnet in Figure 1. This ensures that the host can access all other participants via the tunnel interface, thanks to the route set by the kernel. The specific route on the LAN interface aims to make sure the hosts remain accessible on the LAN.

Next, you can add the matching public key and distribute the left host file to all those involved. This is done in an any-to-any process, which can mean a fair amount of overhead. As well as those already mentioned, the file can contain additional parameters, such as specific encryption algorithms or alternative ports.

Before starting Tinc, you need to make sure that Linux has loaded the tun module. Tinc doesn't do this automatically, but it is needed for a working VPN. After starting the daemon for all those involved, Tinc then routes the package – as expected – via the tunnel.

The software worked well in the test, ran stably, and fulfilled the requirement of the full mesh. However, the approach also has limitations. For example, a lot of overhead is required to distribute all the host files to all those involved. Tinc needs to resend the file if the configuration changes for a host. This works well with five hosts, but becomes a bit confusing with 100.

Each node must also be reachable externally. This requires access to a firewall to connect through the incoming port. Alternatively, Tinc can run on a host accessible via the Internet. So, it is a good thing that it provides Tinc for Linux and most BSD derivatives (including Mac OS X) and as a build for OpenWrt. In Windows, it supports versions 2000(!) up to 7.

Freelan

Freelan [2] has not been around as long as Tinc. According to GitHub, development started in 2011 and is largely a one-man show. Freelan allows both classic site-to-site and peer-to-peer VPNs or a mixture of both forms and is established like Tinc (Figure 1).

The software is available on the website [2] for Windows (XP to 8), Mac OS X (10.7-10.9), and Linux. There are Debian packages (which was used in this test) for the free operating system and source code for compiling it yourself. Compiling turned out not to be non-trivial in our lab, at least not with the Gentoo Test VM used as a standard.

In contrast to Tinc, the hosts mutually authenticate using X.509 certificates. In the simplest scenario, each host needs its own certificate with a private key and the CA certificate, which the participants' certificates have signed in order to authorize the others.

A very simple configuration for two hosts looks like that shown in Figure 3 (a source of certificates required). This is the configuration of the host Alice in /etc/freelan/LM-Test.conf. The tunnel interfaces use addresses from the 10.10.1.0/24 network. Alice has the host address 1 and needs to access Bob's computer using the specified hostname and port. The Alice computer actively tries to establish a connection using the contact statement.

Figure 3: The configuration for Alice contains the IP address and links to the X.509 certificates, among other things.

Using the /etc/freelan/LM-Test.conf configuration file, it is also possible to operate several networks side by side at the same time. You can control which configurations you activate using entries in /etc/default/freelan. Here you can also determine whether Freelan accepts incoming connections, excludes certain network areas from establishing contact, and controls which incoming certificates Freelan accepts using a configurable script. The tunnel can be set up in next to no time in the configuration with mutual contact establishment, and the addresses can be accessed on the 10.10.1.0/24 network.

There is also a server mode, and in this mode, a central web server is given a network's parameters. This allows the participants to get to know the other participants. Unfortunately, the documentation doesn't say anything about how to set up server mode. The configuration example provided only demonstrates how to connect to the master server. Users can fire up their VPNs because the service also works without this mode.

Because the software uses certificates instead of key pairs, as for Tinc, nodes do not have quite as much to do. As with Tinc, however, you need to make the nodes aware of all the publicly accessible IP addresses and hostnames. This means that two nodes, with NAT devices they do not control, will not find common ground.

However, the network doesn't need to be fully meshed for Alice still to be able to communicate with Felix via the VPN. The relay_mode is active by default – meaning there only needs to be one chain of contact between Alice and Felix, although this isn't exactly conducive to latency.

IPOP

The IPOP project [3] was launched in 2006 at the University of Florida. It uses a slightly different method than the first two candidates. Instead of connecting clients directly, Jabber [5] acts as an intermediary. The Jingle [6] extension, which was actually intended for multimedia content, brokers the user data connections (Figure 4). IPOP offers two VPN variants: Social VPN interconnects individual clients, Group VPN instead helps servers contact one another.

Figure 4: IPOP chooses a different approach than Tinc and Freelan, in that it requires a Jabber server and supports both STUN and TURN.

If there are two nodes in a NAT connection, they use a STUN [7] or TURN [8] server as a connection point on the Internet. The software is available for download [3] and on GitHub [9] for all major Linux distributions. There is also a version for Windows, Android, and OpenWrt.

We specifically looked at the Group VPN variant. In the first test, two juxtaposed VMs established contact; later two VPNs behind NAT gateways communicated to test this also.

A Jabber server on which all participants can divide an account is needed to operate IPOP. There is a description in the documentation on the website [3] explaining how you can use Openfire for this purpose. However, IPOP also works with public servers such as talk.google.com, which was used in the test.

After downloading the tarball, create a configuration file named config.json as the first step (Figure 5). The first three parameters describe access to the XMPP server. The two IP parameters are for the IP address of the node in the VPN and the network mask, the others are only responsible for logging. Now, start two processes one after the other:

Figure 5: IPOP requires a configuration file in JSON format, which allows access to the XMPP server.

ipop-tincan-x86_64 1> out.log 2> err.log &

and:

gvpn_controller.py \
  -c config.json &> log.txt &

Before doing so you need to load the tun module in the kernel manually – as with the other candidates. Make both calls as root or with sudo.

Now you need a bit of patience to connect to the Jabber server. If there are nodes on the VPN with the same User ID, but on different branches, IPOP will switch on the tunnel and the partner IP addresses can be accessed.

Unfortunately, the entries in the logfiles are only meaningful if you set the log level to debug. However, you can ask the IPOP server processes for the current status: Using this command

echo -e '\x02\x01{"m":"get_state"}' | \
  netcat -q 1 -u 127.0.0.1 5800

you will receive a status indicator that displays the found partners, among other things. If the participants are in NAT gateways, you can incorporate a STUN or TURN server in the configuration just as with audio connections.

To do this, you need to expand the config.json file with the line

"stun": ["<STUN-Server-on-the-Internet>"]

to incorporate a STUN server. Or, use the line

"turn": [{"server": \
  "<TURN-Server>:<Port>", \
  "user": "<Username>", \
  "pass": "<Password>"}]

for a TURN server. Readers with JSON experience will quickly realize that it is also possible to define multiple TURN servers.

The possibility of using a STUN or a TURN server to bridge NAT is really convenient for users. However, it's a nightmare for security managers in the enterprise, where the security policy allows all traffic from inside to outside. Unfortunately, this policy is common among companies. If a STUN or TURN server is used, however, the packages need to go through the Internet several times – and of course this doesn't exactly speed up performance.