Recently an interesting question was posted by community member Lvkezeng on Telegram about the benefits of tunnel-in-tunnel in NymVPN fast mode. Their argument was that since the client has an encrypted connection to the entry gateway, wrapping that into an additional encrypted tunnel between the entry and exit gateway just adds additional overhead and doesn’t improve overall security.
This sparked quite the discussion internally, with cofounders Ania and Claudia and many others weighing in to explain the thinking behind the tunnel-in-tunnel approach, and its benefits in terms of security and user privacy. I will share their key points here. Thank you for a thought provoking question Lvkezeng! This information will be shared on the Nym website as well.
So what are the benefits of tunnel-in-tunnel for the Fast mode (2-hop mode) of NymVPN?
In most cases the data payload is already protected by end-to-end encryption, so actually even a naked connection without VPN encryption should be fine from the perspective of data confidentiality.
The issue is metadata: the layer of encryption removed by the second (exit) node conceals the recipient of the communication from the first (entry) node. Without the second layer of encryption (between the client and the exit node), the first node would be able to see the destination of the communication, even if the content is encrypted.
So the tunnel-in-tunnel 2-layer encryption achieves the following:
- the first (entry) node sees the client and the second (exit) node, but not the destination;
- the second (exit) node sees the first (entry) node and the destination, but not the client; thus,
- no node sees both the client and the destination.
What are the performance costs of the Nym tunnel-in-tunnel approach?
This part will be short: our 2-layer tunnel-in-tunnel WireGuard implementation causes negligible performance and throughput overhead compared to a single WireGuard tunnel.
What are the privacy properties of alternative 2-hop WireGuard implementations?
Let’s take a look at the following four 2-hop WireGuard routing scenarios:
- 2 hops but single tunnel to the exit node
- 2 hops but a single tunnel to the entry node
- 2 hops and chained tunnels (some other VPNs use this approach)
- 2 hops and nested tunnels (Nym’s approach)
Single WireGuard Tunnel to the Exit Node
The client encrypts traffic for a tunnel established directly with the exit node. The entry node acts as a simple routing intermediary, forwarding encrypted traffic to the exit node without performing any encryption or decryption.
Privacy implication: 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, which uniquely identifies the client. As a result, the exit node can link the client’s identity (via their public key) with the traffic’s final destination.
Single WireGuard Tunnel to the Entry Node
The client encrypts traffic for a tunnel established directly with the entry node. The entry node decrypts the traffic and forwards it to the exit node, which then forwards the traffic to the destination.
Privacy implication: The entry node can see the client’s IP address, the decrypted traffic (if no additional payload encryption is used), and the final destination. This weakens privacy because the entry node can link client and destination.
Chained WireGuard Tunnels
The client establishes a WireGuard tunnel with the entry node. The entry node decrypts the incoming traffic, re-encrypts it, and forwards it to the exit node. The exit node then decrypts the traffic and forwards it to the final destination.
Privacy Implication: The entry node can fully decrypt and inspect the traffic, including its contents and destination. It may also modify or tamper with the traffic before re-encrypting it for the exit node. If no additional payload encryption (e.g., HTTPS or AES) is applied, both the entry and exit nodes can see the plaintext data and thus correlate client’s communication.
Nested WireGuard Tunnels (Tunnel-in-Tunnel)
The client encrypts traffic for the second tunnel (exit node) and then further encrypts it for the first tunnel (entry node). The entry node decrypts only the outer layer (its tunnel) and forwards the still-encrypted traffic to the exit node. The exit node then decrypts the inner layer and forwards the traffic to the destination.
Privacy Implication: The entry node cannot see or modify the contents of the traffic destined for the exit node or learn the final destination. Only the exit node can decrypt the second layer and access the final destination. While the exit node knows the destination, it cannot correlate it with the client’s IP address, preserving unlinkability between the client and the destination.
Should there be a 1-hop mode?
Hopefully the above clarifies the reasons behind the design of fast (2-hop) mode. It is a robust approach with minimal performance impact, hitting an excellent balance between performance and privacy. That said, it is possible to add a something like a “lightning fast mode” with a single hop to NymVPN. This would be even faster than fast mode, with location obfuscation like other VPNs, although with reduced privacy… Just like other VPNs. Would you want that? Let us know and we’ll make it happen!