Peer-to-peer-based VPN alternatives
Tunnel Vision

© Lead Image © Warakorn Harnprasop, 123RF.com
People wanting to encrypt the network traffic sent over public lines usually use either IPsec, SSL via port 443, or OpenVPN. We look at four alternative tunnel builders that promise VPN using the peer-to-peer method.
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).
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.
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.

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.

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:

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.
Buy this article as PDF
(incl. VAT)
Buy Linux Magazine
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters
Support Our Work
Linux Magazine content is made possible with support from readers like you. Please consider contributing when you've found an article to be beneficial.
News
-
Fedora 39 Beta is Now Available for Testing
For fans and users of Fedora Linux, the first beta of release 39 is now available, which is a minor upgrade but does include GNOME 45.
-
Fedora Linux 40 to Drop X11 for KDE Plasma
When Fedora 40 arrives in 2024, there will be a few big changes coming, especially for the KDE Plasma option.
-
Real-Time Ubuntu Available in AWS Marketplace
Anyone looking for a Linux distribution for real-time processing could do a whole lot worse than Real-Time Ubuntu.
-
KSMBD Finally Reaches a Stable State
For those who've been looking forward to the first release of KSMBD, after two years it's no longer considered experimental.
-
Nitrux 3.0.0 Has Been Released
The latest version of Nitrux brings plenty of innovation and fresh apps to the table.
-
Linux From Scratch 12.0 Now Available
If you're looking to roll your own Linux distribution, the latest version of Linux From Scratch is now available with plenty of updates.
-
Linux Kernel 6.5 Has Been Released
The newest Linux kernel, version 6.5, now includes initial support for two very exciting features.
-
UbuntuDDE 23.04 Now Available
A new version of the UbuntuDDE remix has finally arrived with all the updates from the Deepin desktop and everything that comes with the Ubuntu 23.04 base.
-
Star Labs Reveals a New Surface-Like Linux Tablet
If you've ever wanted a tablet that rivals the MS Surface, you're in luck as Star Labs has created such a device.
-
SUSE Going Private (Again)
The company behind SUSE Linux Enterprise, Rancher, and NeuVector recently announced that Marcel LUX III SARL (Marcel), its majority shareholder, intends to delist it from the Frankfurt Stock Exchange by way of a merger.