\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, producing over 300 unique measurements. 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}. IoT edge computing, content
delivery networks, and blockchain platforms like Ethereum all rely on
some form of peer-to-peer topology. 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. The result is that a
single administrator can reliably 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, measuring point-to-point
throughput, latency, and CPU overhead. Their work does 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, analyzing 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: it evaluates a broader set of VPN implementations with
emphasis on fully decentralized architectures, tests them under
application-level workloads (video streaming, package downloads),
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 (including video streaming and package downloads)
    and four network impairment profiles, with over 300 unique
    measurements.
  \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. All dependencies are pinned,
    system configuration is declarative, and cryptographic material
    is generated deterministically, so 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}

