Nested VPNs

The Problem with Single VPN

When you route all traffic through a single VPN provider, you shift trust from your ISP to your VPN provider. That provider now sees:

• Your real IP address (they know who you are)
• Every destination you connect to (they know what you do)
• All your DNS queries
• Data volumes and timing patterns

You traded one observer for another. If your VPN provider were to log, get subpoenaed, or get compromised, they have everything your ISP used to have. Plus they know your actual identity through your payment method or account.

This is not a criticism of VPN providers. It is the reality of the architecture. Single-hop VPN shifts trust. It does not eliminate it.

The Solution: Chained VPNs

Nested VPNs route your traffic through multiple providers in sequence. Each provider only sees part of the picture. No single provider has both your identity AND your activity.

This is the same principle Tor uses: split knowledge across multiple nodes so no single operator can correlate who you are with what you do.

Two Hops

The simplest nested configuration uses two providers:

Wirebump -> VPN #1 -> VPN #2 -> Internet

Provider	What they see
VPN #1	Your real IP address, but only a connection to VPN #2. No destinations, no DNS queries, no content.
VPN #2	All your traffic and DNS queries, but only VPN #1’s IP address. Not yours.

No single provider has both your identity and your browsing activity.

VPN #1 knows who you are but not what you do. VPN #2 knows what you do but not who you are.

Three Hops

For additional separation, add a middle node:

Wirebump -> VPN #1 (entry) -> VPN #2 (middle) -> VPN #3 (exit) -> Internet

Provider	What they see
VPN #1 (entry)	Your real IP connecting to VPN #2. Nothing else.
VPN #2 (middle)	VPN #1 connecting to VPN #3. No endpoints, no identity.
VPN #3 (exit)	VPN #2’s IP and all your actual traffic.

The middle node sees neither your identity nor your destinations. It only knows the previous and next hops in the chain.

Comparison to Tor

Nested VPNs and Tor share the same core idea: split knowledge across multiple operators.

Aspect	Tor	Wirebump Nested VPNs
Circuit structure	Entry, relay, exit	Entry, middle (optional), exit
Circuit rotation	Automatic (every 10 min)	Manual (you choose when)
Traffic padding	Yes (constant bandwidth)	No
Latency	Higher (more hops, padding)	Lower (direct VPN connections)
Throughput	Limited by relay capacity	Line-speed with parallel connections
Provider selection	Tor network assigns	You choose each layer

Key differences:

• Rotation: Tor rotates circuits automatically. Wirebump does not. You rebuild or switch circuits when you want to.
• Padding: Tor adds traffic padding to obscure timing patterns. Wirebump does not (though Mullvad VPN DAITA adds similar protection at the cost of throughput).
• Control: You pick which providers sit at each layer and in which countries. With Tor, the network assigns nodes.

Wirebump gives you a platform for experimenting with circuit topologies. How you use it determines the privacy/performance tradeoffs.

Configuration

In the circuit builder, add layers to your circuit. Each layer can use a different provider (Proton VPN or Mullvad VPN) and a different geographic location.

The screenshot shows a 3-layer circuit with the exit layer selected. You choose the provider and country for each layer independently.

Provider Diversity

Using different providers at different layers provides defense in depth. Even if one provider were compromised, they would only have partial information about your traffic.

Latency Tradeoff

Each hop adds latency. Your traffic travels through an additional server, potentially in a different geographic region.

Expect:

• 2-hop circuit: modest latency increase (varies by server locations)
• 3-hop circuit: noticeable but often acceptable for most use cases

The actual impact depends on server selection. Choosing servers in the same region minimizes geographic latency. Choosing servers on different continents maximizes provider diversity but adds travel time.

Test with the circuit latency indicator in the header to see real numbers for your specific configuration.

When Nested VPNs Make Sense

Scenario	Single VPN	Nested VPN
Hide traffic from ISP	Sufficient	Overkill
Distrust a single provider	Risky	Appropriate
High-stakes research or journalism	Insufficient	Consider it
Casual browsing	Fine	Unnecessary overhead
Legal/compliance requirements	Check requirements	May be required

Nested VPNs are not for everyone. They add complexity and latency. For most users, a single reputable VPN provider is sufficient.

But if your threat model includes the possibility that a VPN provider could be compelled to log, compromised, or operating dishonestly, nested VPNs reduce the damage any single point of failure can cause.

Split Knowledge Deep Dive

For a deeper look at the cryptographic and operational properties of split knowledge:

• Split Knowledge - Why no single provider can reconstruct the full picture

Combine with Parallel Connections

Nested VPNs and parallel connections are not mutually exclusive. You can run multiple nested circuits in parallel to get both:

• Split knowledge from nesting (privacy)
• Aggregated throughput from parallel paths (speed)

See Nested + Parallel for configuration details.

---

Proton VPN is a registered trademark of Proton AG. Mullvad and Mullvad VPN are trademarks of Mullvad VPN AB.