Double VPN — How It Works

QuFabric's double VPN creates two independent WireGuard tunnels — one inside the other — using different encryption algorithms and independent key management. This page explains the data path, interface architecture, and how the two layers interact.

Data Path

Every packet from an application traverses two full WireGuard encryption layers before reaching the network:

Application (e.g. SSH, HTTPS)
    │
    │  cleartext
    ▼
┌──────────────────────────────────────────────────────────┐
│  aes0 — AES WireGuard Interface (Inner Tunnel)           │
│  Cipher: AES-256-GCM                                     │
│  Noise: Noise_IKpsk2_25519_AESGCM_BLAKE2s                │
│  PSK: Injected by DSKE (rotated every 120s)              │
│  Listen port: 51830                                      │
└──────────────────────────────────────────────────────────┘
    │
    │  AES-encrypted WireGuard packet
    ▼
┌──────────────────────────────────────────────────────────┐
│  wg0 — Standard WireGuard Interface (Outer Tunnel)       │
│  Cipher: ChaCha20-Poly1305                               │
│  Noise: Noise_IKpsk2_25519_ChaChaPoly_BLAKE2s            │
│  Keys: WireGuard DH + Rosenpass PQC (rotated every 120s) │
└──────────────────────────────────────────────────────────┘
    │
    │  double-encrypted packet
    ▼
Network (internet, LAN, cellular, satellite, etc.)

On the receiving side, the process is reversed: wg0 decrypts the outer layer, then aes0 decrypts the inner layer, delivering cleartext to the application.

Two Interfaces, One Network

QuFabric manages both interfaces transparently. Each peer receives two IP addresses:

The AES IP is allocated by the management server and distributed to all peers via the network map. Both IPs are resolvable via DNS:

Route Steering

The client automatically routes traffic through the correct interface:

• AES-capable peers: Application traffic routes via aes0 (double encrypted)
• AES-exempt peers: Traffic routes via wg0 (single WireGuard encryption)
• Security hubs: Always communicate via wg0 (they provide key management, not data transport)

This happens transparently — applications connect to the AES IP and the routing table handles the rest.

Firewall and Access Control

Users create access policies against peer groups as a single logical network. The client locally decides which interface to enforce rules on:

When both peers use AES, the wg0 interface is locked down to only allow:

All other application traffic must flow through the AES tunnel. For diagnostics use cases (e.g., iperf benchmarking), operators can open additional ports on wg0 — see WG Lockdown Extra Ports.

Post-Quantum Protection on the Outer Tunnel

The outer WireGuard tunnel (wg0) runs Rosenpass by default, a post-quantum secure key exchange protocol. Rosenpass uses Classic McEliece and Kyber to continuously generate and rotate WireGuard pre-shared keys every 120 seconds, protecting the outer tunnel against "harvest now, decrypt later" quantum computing threats.

This means the complete encryption stack is:

Both layers independently protect against quantum threats through different mechanisms — Rosenpass via post-quantum algorithms on the outer tunnel, and DSKE via out-of-band symmetric key distribution on the inner tunnel.

AES WireGuard Implementation

The AES WireGuard interface uses a fork of the standard wireguard-go implementation with a single modification: the Noise protocol cipher suite is changed from ChaCha20-Poly1305 to AES-256-GCM.

Everything else — the Noise IKpsk2 handshake pattern, session key derivation, UAPI interface, timers, peer management — is identical to standard WireGuard. The interface is verified at startup to confirm the correct cipher:

Noise_IKpsk2_25519_AESGCM_BLAKE2s

Key Properties

• Same WireGuard private key as the primary interface — no additional key management for the tunnel itself
• Independent PSK from DSKE — this is the additional key material that enables the second encryption layer
• Automatic MTU: Derived from the primary WireGuard MTU minus 60 bytes (IPv4 overhead)
• Userspace implementation: Runs entirely in userspace for portability

PSK Security Gate

When a new AES peer is added, the interface initializes with a random PSK that is different from the remote peer's random PSK. This means:

1. The WireGuard handshake on aes0 will intentionally fail — both sides have different PSKs
2. No application traffic can flow over the AES tunnel
3. DSKE must establish a shared secret before the tunnel becomes operational
4. Once DSKE injects the agreed-upon PSK on both sides, the handshake succeeds within seconds

This is a deliberate security gate: the AES path is blocked until DSKE establishes governance. There is never a window where the AES tunnel operates without DSKE-managed keys.

Key Rotation

DSKE rotates the PSK every 120 seconds. Rotation is seamless:

1. DSKE generates a new secret and both peers inject it
2. The existing WireGuard session continues with its current session keys
3. At the next natural WireGuard rekey (every 120 seconds), the new PSK is used
4. No traffic interruption, no forced handshake on rotations