Network Planning
This guide helps you plan your QuFabric deployment with the AES double VPN. It covers subnet design, security hub placement, and PSRD sizing.
IP Address Planning
Each peer in the network receives up to two IP addresses:
| Address | Range | Allocated By | Used For |
|---|---|---|---|
| WireGuard IP | 100.64.0.0/10 (CGNAT space) | Management server | Standard WireGuard tunnel, infrastructure traffic |
| AES IP | Configurable subnet | Management server | AES double-encrypted tunnel |
AES Subnet Sizing
Choose an AES subnet large enough for all peers that will participate in the double VPN. AES-exempt peers and security hubs don't need AES IPs, but all regular Linux peers do.
| Network Size | Suggested AES Subnet | Available Addresses |
|---|---|---|
| Small (< 50 peers) | /24 | 254 |
| Medium (50–500 peers) | /22 | 1,022 |
| Large (500+ peers) | /16 | 65,534 |
Security Hub Placement
Minimum Configuration
You need at least 2 security hubs (the default shares_required is 2). With exactly
2 hubs, both must be available for every key operation — there is no redundancy.
Recommended Configuration
For production deployments, deploy 3 or more hubs with shares_required=2. This gives
you N-of-2 redundancy — any 2 of your N hubs can reconstruct secrets.
| Hubs | Shares Required | Tolerated Hub Failures |
|---|---|---|
| 2 | 2 | 0 (no redundancy) |
| 3 | 2 | 1 |
| 4 | 2 | 2 |
| 5 | 2 | 3 |
Placement Strategy
For maximum security and availability:
- Geographic distribution: Place hubs in different data centers, regions, or cloud providers
- Administrative separation: Have different teams manage different hubs where possible
- Network independence: Ensure hubs don't share the same network path to prevent correlated failures
- Stable connectivity: Hubs should have reliable, low-latency connections to the WireGuard mesh
Hub Resource Requirements
Security hubs are lightweight — they primarily store key shares and generate PSRD:
| Resource | Requirement |
|---|---|
| CPU | Minimal (key operations are lightweight) |
| Memory | ~100 MB |
| Storage | ~1 GB (PSRD pool + SDK database) |
| Network | Must be reachable by all peers via WireGuard |
PSRD Sizing
Consumption Rate
PSRD is consumed with every key rotation:
| Parameter | Value |
|---|---|
| Key rotation interval | 120 seconds per peer pair |
| PSRD per rotation | ~4 KiB (approximate) |
| Rotations per hour | ~30 per peer pair |
| PSRD per hour per peer pair | ~120 KiB |
Calculating PSRD Needs
For a peer connected to N other AES-capable peers:
Daily PSRD consumption ≈ N × 120 KiB/hour × 24 hours ≈ N × 2.8 MiB/day
Examples:
| Peers Connected To | Daily PSRD Consumption | Standard 256 KiB PSRD File Lasts |
|---|---|---|
| 1 | ~2.8 MiB | ~2 hours |
| 5 | ~14 MiB | ~25 minutes |
| 10 | ~28 MiB | ~13 minutes |
| 50 | ~140 MiB | ~2.5 minutes |
For deployments with many peer pairs, automatic online PSRD refill handles replenishment transparently. The initial PSRD file bootstraps the connection; subsequent entropy is requested from the hub online.
PSRD Provisioning Plan
For initial deployment:
- Generate PSRD files for each client on each hub (standard: 256 KiB per file)
- Transfer files securely to each client
- Ingest files on each client (one per hub)
- Monitor levels via
qufabric dske status - Rely on auto-refill for ongoing operations
DNS Planning
Domain Structure
| Zone | Purpose | Example |
|---|---|---|
| Standard DNS domain | WireGuard IP resolution | peer.qufabric.cloud → 100.64.0.1 |
| AES DNS domain | AES IP resolution | peer.aes.qufabric.cloud → 100.64.128.1 |
Applications should use the AES DNS domain to ensure traffic flows through the double-encrypted tunnel.
DNS Configuration
The AES DNS domain can be:
- Automatic: Defaults to
aes.<dns_domain> - Custom: Set via the management API or server flag
See AES DNS Configuration for details.
Access Control Planning
Policy Design
Design policies as if you have a single network — the dual-interface enforcement is handled automatically by each client:
- AES-capable peers: User policies enforce on
aes0, infrastructure lockdown onwg0 - AES-exempt peers: All policies enforce on
wg0(standard behavior) - Security hubs: Reachable by all peers via auto-created policy
Security Hub Access
The management server automatically creates a "DSKE Security Hubs" group and bidirectional policy. Do not delete or modify this policy — it ensures all peers can reach the hubs for DSKE operations.
Deployment Checklist
- Choose AES IP subnet and configure on management server
- Deploy at least 2 security hub peers
- Verify hub provisioners are generating PSRD files
- Add DSKE clients on each hub for each client peer
- Generate and securely distribute PSRD files
- Ingest PSRD on each client (one file per hub)
- Verify
qufabric dske statusshows 2+ hubs with PSRD - Verify
sudo wg show aes0shows active handshakes - Test connectivity via AES IPs or AES DNS names
- Mark non-Linux peers as AES-exempt
- Configure AES DNS domain (optional)
- Set up PSRD level monitoring