# 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.

![Layer configuration showing multi-hop setup](https://wirebump.net/screenshots/exit-layer-configuration.png)

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](https://wirebump.net/docs/privacy/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](https://wirebump.net/docs/vpn-topologies/nested-parallel) for configuration details.

---

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