Understanding private mesh networks and traditional VPNs
An explanation of how private mesh networks route traffic directly between devices compared to traditional centralised VPN gateways.
Virtual Private Networks (VPNs) have historically been used to connect remote users to a central office network or to route internet traffic through a secure proxy server. However, the architecture of these traditional networks introduces specific routing paths that may not be optimal for direct device-to-device communication. A private mesh network offers an alternative topology by establishing direct, encrypted connections between individual nodes without relying on a central gateway to relay the traffic. This structural shift addresses modern requirements where workloads are distributed across multiple environments, including local workstations, cloud servers, and mobile devices.
The Architecture of Traditional VPNs
In a traditional VPN setup, a central server acts as the gateway. When a client device, such as a laptop or a phone, wants to communicate with another resource, it must first establish an encrypted tunnel to this central gateway. The gateway decrypts the traffic and forwards it to the destination. If two remote devices need to exchange data, the packets must travel from the first device to the central server, and then from the central server to the second device. This routing pattern, often referred to as hub-and-spoke, can introduce significant latency and creates a single point of failure at the central gateway, which must process all network traffic.
How a Private Mesh Network Works
A private mesh network, such as the one implemented by prialo, operates on a peer-to-peer basis. Instead of routing all data through a central hub, devices establish direct encrypted connections to one another. When you install the software on a Mac, a phone, or a Linux server, each device is assigned a unique IP address within the shared 100.64.x.x range. This range is part of the Shared Address Space defined in RFC 6598, which is specifically designated for carrier-grade NAT environments, ensuring that these private addresses do not conflict with standard local home or office network ranges.
The coordination of these connections is handled by a control plane, which helps nodes discover each other's public IP addresses and negotiate direct paths. Once the connection is established, the actual data plane traffic flows directly between the devices using the WireGuard protocol for encryption. This means that sensitive data never passes through an intermediary server, preserving privacy and maximising the throughput supported by the physical internet connections of the participating devices.
Key Differences in Traffic Routing and Security
The fundamental differences between these two architectures can be categorised across several areas, highlighting how direct routing alters security and performance:
- Path efficiency: Mesh networks route packets directly between peers, reducing latency compared to routing through a distant central gateway.
- No exposed ports: Devices do not need open public ports on firewalls to accept incoming connections, as the coordination mechanism facilitates traversal through Network Address Translation (NAT) using modern hole-punching techniques.
- Reduced single point of failure: While a central coordination server is used to exchange connection details, the actual data traffic does not pass through it. If the coordination server is temporarily offline, existing direct tunnels continue to function without interruption.
- Resource isolation: Access can be restricted to specific devices on the mesh, preventing broader network lateral movement and reducing the blast radius of a compromised node.
Practical Application on Linux Servers
For system administrators managing Linux servers alongside client devices, configuring a node on a mesh network involves running a background daemon that manages the virtual network interface. Once active, the interface automatically routes traffic destined for the 100.64.0.0/10 range through the encrypted mesh. For example, verifying the status of the local node and its active peer connections can be performed using standard command-line tools:
prialo statusThis command displays the active peer connections, their assigned 100.64.x.x addresses, and the current cryptographic handshakes, ensuring that administrators can verify direct connectivity. By utilizing this mesh structure, teams can securely access remote administrative services like SSH or database ports without exposing those services to the public internet or configuring complex firewall rules.