\chapter{Introduction} % Main chapter title

\label{Introduction}

Peer-to-peer overlay VPNs allow nodes to connect directly regardless
of NAT or firewall restrictions. Yet practitioners choosing among the
growing number of mesh VPN implementations must rely largely on
anecdotal evidence: systematic, reproducible comparisons under
realistic conditions are scarce.

This thesis addresses that gap. We benchmark ten peer-to-peer VPN
implementations across seven workloads and four network impairment
profiles. We complement these performance benchmarks with a source
code analysis of each implementation, verified by the respective
maintainers. The entire
experimental framework is built on Nix, NixOS, and the Clan deployment
system, so every result is independently reproducible.

\section{Motivation}

Peer-to-peer architectures can provide censorship-resistant,
fault-tolerant infrastructure because they have no single point of
failure \cite{shukla_towards_2021}. Blockchain platforms like Ethereum
depend on this property, as do IoT edge networks and content delivery
systems. But these benefits only hold when nodes are spread across
diverse hosting entities.

In practice, this diversity remains illusory.
Amazon, Hetzner, and OVH collectively host 70\% of all Ethereum nodes
(see Figure~\ref{fig:ethernodes_hosting}), so nominally decentralized
infrastructure actually sits in a handful of cloud providers.
More concerning, these providers operate under overlapping regulatory
jurisdictions,
predominantly the United States and the European Union.
This concentration undermines technical sovereignty:
a single governmental action could compel service termination,
data disclosure, or traffic manipulation across a majority of the network.

\begin{figure}[H]
  \centering
  \includegraphics[width=1\textwidth]{Figures/ethernodes_hosting.png}
  \caption{Distribution of Ethereum nodes hosted by various providers
  \cite{noauthor_isps_nodate}}
  \label{fig:ethernodes_hosting}
\end{figure}

This centralization persists because self-hosting is hard. Cloud
providers offer static IP addresses and publicly routable endpoints,
which avoids the networking problems that residential and small-office
deployments face.
Most internet-connected devices sit behind Network Address Translation (NAT),
which prevents incoming connections without explicit port forwarding
or relay infrastructure.
Combined with dynamic IP assignments from ISPs, stable peer
connectivity from self-hosted infrastructure has traditionally
required significant technical expertise.

Overlay VPNs solve this problem. They establish encrypted tunnels
that traverse NAT boundaries, so peers can connect directly without
static IP addresses or manual firewall configuration. Each node
receives a stable virtual address within the overlay network,
regardless of its physical network topology. A device behind
consumer-grade NAT can therefore participate as a first-class peer
in a distributed system.

The Clan deployment framework uses Nix and NixOS to eliminate
configuration drift and dependency conflicts, which makes it
practical for a single administrator to self-host distributed
services.
Overlay VPNs are central to Clan's architecture: they supply the
peer connectivity that lets nodes form a network regardless of
physical location or NAT situation.
As illustrated in Figure~\ref{fig:vision-stages}, Clan plans to offer
a web interface that lets users design and deploy private P2P networks
with minimal configuration, assisted by an integrated LLM.

During Clan's development, a recurring problem surfaced:
practitioners disagreed on which mesh VPN to use, each pointing to
different edge cases where their preferred VPN failed or lacked a
needed feature. These discussions relied on anecdotal evidence rather
than systematic evaluation, which motivated the present work.

\subsection{Related Work}

Existing research offers only partial coverage of this space.
Lackorzynski et al.\ \cite{lackorzynski_comparative_2019} benchmark
OpenVPN, IPSec, Tinc, Freelan, MACsec, and WireGuard in the context
of industrial communication systems. They measure point-to-point
throughput, latency, and CPU overhead but do not address overlay
network behavior such as NAT traversal or dynamic peer discovery.
The most closely related study by Kjorveziroski et al.\
\cite{kjorveziroski_full-mesh_2024} evaluates full-mesh VPN solutions
for distributed systems, looking at throughput, reliability under
packet loss, and relay behavior for VPNs including ZeroTier. However,
it focuses primarily on solutions with a central point of failure and
limits its workloads to synthetic iperf3 tests.

This thesis extends that work in several directions. It evaluates a
broader set of VPN implementations with emphasis on fully
decentralized architectures and tests them under application-level
workloads such as video streaming and package downloads. It also
applies multiple network impairment profiles and provides a
reproducible experimental framework built on Nix, NixOS, and Clan.

A secondary goal was to create an automated benchmarking framework
that generates a public leaderboard, similar in spirit to the
js-framework-benchmark (see Figure~\ref{fig:js-framework-benchmark}).
A web interface with regularly updated results gives VPN developers a
concrete baseline to measure against.

\section{Research Contribution}

This thesis makes the following contributions:

\begin{enumerate}
  \item A benchmark of ten peer-to-peer VPN implementations across
    seven workloads and four network impairment profiles. The workloads
    include video streaming and package downloads alongside synthetic
    throughput tests.
  \item A source code analysis of all ten VPN implementations. Manual
    code review was combined with LLM-assisted analysis and the results
    were verified by the respective maintainers on GitHub.
  \item A reproducible experimental framework built on Nix, NixOS,
    and the Clan deployment system. Dependencies are pinned and system
    configuration is declarative, down to deterministic cryptographic
    material generation. Every result can be independently replicated.
  \item A performance analysis showing that Tailscale outperforms the
    Linux kernel's default networking stack under degraded conditions,
    and that kernel parameter tuning (Reno congestion control in place
    of CUBIC, with RACK disabled) yields measurable throughput
    improvements.
  \item The discovery of several security vulnerabilities across
    the evaluated VPN implementations.
  \item An automated benchmarking framework that produces a public
    leaderboard, giving VPN developers a target to optimize
    against.
\end{enumerate}

\begin{figure}[H]
  \centering
  \includegraphics[width=1\textwidth]{Figures/krause-js-framework.png}
  \caption{js-framework-benchmark results for Chrome 144.0
  \cite{krause_krausestjs-framework-benchmark_2026}}
  \label{fig:js-framework-benchmark}
\end{figure}

\begin{figure}[h]
  \centering

  % Row 1
  \begin{subfigure}{0.45\textwidth}
    \centering
    \includegraphics[width=\linewidth]{Figures/vision/stage1.png}
    \caption{Stage 1}
  \end{subfigure}
  \hfill
  \begin{subfigure}{0.45\textwidth}
    \centering
    \includegraphics[width=\linewidth]{Figures/vision/stage2.png}
    \caption{Stage 2}
  \end{subfigure}

  \vspace{1em} % Add spacing between rows

  % Row 2
  \begin{subfigure}{0.45\textwidth}
    \centering
    \includegraphics[width=\linewidth]{Figures/vision/stage3.png}
    \caption{Stage 3}
  \end{subfigure}
  \hfill
  \begin{subfigure}{0.45\textwidth}
    \centering
    \includegraphics[width=\linewidth]{Figures/vision/stage4.png}
    \caption{Stage 4}
  \end{subfigure}

  \vspace{1em} % Add spacing between rows

  % Row 3
  \begin{subfigure}{0.45\textwidth}
    \centering
    \includegraphics[width=\linewidth]{Figures/vision/stage5.png}
    \caption{Stage 5}
  \end{subfigure}
  \hfill
  \begin{subfigure}{0.45\textwidth}
    \centering
    \includegraphics[width=\linewidth]{Figures/vision/stage6.png}
    \caption{Stage 6}
  \end{subfigure}

  \vspace{1em} % Add spacing between rows

  % Row 4
  \begin{subfigure}{0.45\textwidth}
    \centering
    \includegraphics[width=\linewidth]{Figures/vision/stage7.png}
    \caption{Stage 7}
  \end{subfigure}
  \hfill
  \begin{subfigure}{0.45\textwidth}
    \centering
    \includegraphics[width=\linewidth]{Figures/vision/stage8.png}
    \caption{Stage 8}
  \end{subfigure}

  \caption{Planned web interface for setting up a Clan family network}
  \label{fig:vision-stages}
\end{figure}