Building a truly decentralized WireGuard VPN network

When it comes to online privacy, using a Virtual Private Network (VPN) is often one of the first suggestions. But not all VPNs offer the same level of protection, and understanding how they work is crucial if you truly care about minimizing your digital footprint.

In this post, we’ll dive deep into how traditional (centralized) VPNs function, explore the concept of decentralized 2-hop VPNs, and unpack the different architectural choices, especially through the lens of the WireGuard protocol.

The traditional VPN Model: A single point of trust

VPN protections

In a conventional VPN setup, all of your internet traffic is tunnelled through a single server operated by the VPN provider. Here's what that means in practice:

• Encryption: Your traffic is encrypted between your device and the VPN server, preventing local eavesdroppers (like ISPs or public Wi-Fi operators) from seeing what you're doing.
• Anonymization (partial): Your IP address is masked from the outside world, replaced with that of the VPN server.

The vulnerability of traditional VPNs

However, there's a major caveat: the VPN server itself becomes a powerful surveillance point. It sees your real IP address and the final destination of your traffic. Even if the connection is encrypted, the VPN provider can track every website you visit and when. You’ve essentially swapped trust in your ISP for trust in your VPN provider.

In most real-world use cases, such as web browsing, the data inside the VPN tunnel is encrypted at the application layer using HTTPS. This means that while the VPN provider can see which server you're connecting to (e.g., the IP address or even the domain, via DNS or TLS metadata), it cannot read the actual content of your communication, such as the web pages you view or the data you submit in forms. Still, the provider retains visibility into connection metadata like destination IPs, domains (in some cases), traffic volume, and timing information that can still be used to profile user activity.

Why two hops? Enter the multi-hop VPN

To mitigate this centralization problem, 2-hop VPNs, often referred to as decentralised VPNs (dVPNs), route traffic through two separate servers: an entry node and an exit node. The core idea is that no single server should be able to link your identity to your activity:

• The entry node (or gateway) sees your IP address but not that of the final destination of your traffic on the web
• The exit node sees the final destination’s IPaddress, but doesn’t know who you are.

This split trust model significantly increases privacy if the two nodes are run by independent, non-colluding entities. But that's a big "if." For example, if a single company or entity operates both the entry and exit servers, they can correlate and reconstruct the trail of your entire activity. This brings us right back to the original problem of centralized trust above.

WireGuard: Four ways to design a 2-hop VPN

Let’s explore different ways of constructing a 2-hop VPN using WireGuard, a fast, modern VPN protocol known for its simplicity and performance. Each method carries different privacy implications.

1. Single WireGuard tunnel to the exit node

How it works

The client creates a WireGuard tunnel directly with the exit node. The entry node merely forwards the tunnel-encrypted packets without performing any encryption or decryption. The connection from the client to the entry node can use any transport protocol, for example, QUIC, TCP, or even an obfuscated tunnel, depending on what the system supports.

Privacy implications

The WireGuard tunnel is established between the client and the exit node, requiring an exchange of public keys. This means the exit node knows the client’s public key, and since WireGuard keys are long-lived by default, the exit node can track and correlate the client’s activity across multiple sessions, even if the IP address changes. While key rotation can reduce this risk, it isn’t handled automatically by WireGuard. As a result, the exit node can link the client’s identity with the traffic’s final destination. Hence, this setup can potentially enable long-term profiling of clients.

2. Single WireGuard tunnel to the entry node

How it works

The client establishes a WireGuard tunnel with the entry node, which decrypts the traffic and forwards it to the exit node over regular channels. The connection between the entry and exit nodes can use any transport protocol, but it is not part of the WireGuard tunnel established with the client.

Privacy implications

Since the WireGuard tunnel terminates at the entry node, the entry node can see the client’s IP address and the intended destination. Although the exit node sees only traffic from the entry node and cannot link it to the original client, the entry node has access to both the client’s identity and the destination, allowing the node to correlate who the user is and where they're going. If your goal is unlinkability between client identity and destination, this model fails because the entry node has visibility into both ends of the conversation. Hence, from a privacy perspective, this is no better than a traditional VPN.

3. Chained WireGuard tunnels (re-encryption at entry node)

How it works

The client establishes a WireGuard tunnel with the entry node. The entry node decrypts the client’s traffic, then re-encrypts it to the exit node within a new WireGuard tunnel. The exit node decrypts this second tunnel and forwards the traffic to the final destination.

This design involves two separate WireGuard tunnels:

1. One from the client to the entry node
2. One from the entry node to the exit node

The client only participates in the first tunnel. The second is managed entirely by the entry and exit nodes.

Privacy implications

Since the client’s WireGuard tunnel terminates at the entry node, the entry node has full visibility into the user's identity and activity. It sees the client’s real IP address and the decrypted contents of the traffic, including the destination IP and any unencrypted data. This means the entry node can inspect, log, or modify the traffic before passing it along.

The exit node, on the other hand, receives the traffic from the entry node inside a separate WireGuard tunnel. It does not know the original client’s IP address but can see the destination IP and any plaintext content. This approach offers a partial improvement over single-hop VPNs by involving two nodes, but the entry node still has visibility into both the client’s identity and the destination. Only the exit node is isolated from knowing the source of the traffic. Also, without application-layer encryption (e.g., HTTPS), the content of the communication is also exposed to both nodes.

4. Nested WireGuard tunnels (NymVPN’s tunnel-in-tunnel approach)

How it works

In this setup, the client establishes two nested WireGuard tunnels: an inner tunnel to the exit node and an outer tunnel to the entry node. The inner tunnel is created first and encapsulates the actual traffic; the outer tunnel then wraps this inner tunnel.

Traffic is encrypted first for the exit node, then again for the entry node. The entry node decrypts only the outer WireGuard tunnel and forwards the inner WireGuard tunnel, still fully encrypted, to the exit node. The exit node then decrypts the inner layer and forwards the traffic to its final destination.

Privacy Implications

Because the entry node only decrypts the outer WireGuard tunnel, it has no access to the content of the traffic or the destination IP. It knows the client’s IP address, as it establishes the outer tunnel directly with the client, but it only sees the inner WireGuard tunnel intended for the exit node. It cannot inspect, modify, or learn anything about the destination.

The exit node, meanwhile, decrypts the inner WireGuard tunnel and sees the final destination IP and the decrypted traffic. However, it only receives packets from the entry node and has no visibility into the client’s original IP address or identity.

This strict separation of information means that neither node, on its own, can correlate the source (client IP) with the destination (server IP). The entry node knows who the user is, but not where they’re going. The exit node knows where the traffic is headed, but not who it came from. As long as the two nodes are independently operated and do not share logs or metadata, this setup ensures strong unlinkability between the user's identity and their online activity. Even if one node is compromised, it cannot fully deanonymize the user on its own. Only collusion or correlation across both entry and exit nodes could reconstruct the full picture, making this approach the most robust for privacy among the models discussed.

This is the approach used by NymVPN's Fast mode, which leverages nested WireGuard tunnels to preserve unlinkability between users and their destinations.

Conclusion: VPN design matters

“Decentralization” is often thrown around in VPN marketing, but the real privacy gain comes from how systems are architected, not what they're called. A 2-hop VPN setup can be meaningfully better for privacy, but only if:

• The entry and exit nodes are operated by independent, non-colluding parties
• The protocol and tunnel design prevent traffic inspection and correlation

If you're evaluating a dVPN solution or thinking about setting one up, keep in mind: decentralization isn't just about having more nodes, it's about distributing trust in a way that no single party can piece together the full picture of your online life.