Skip to content

Instantly share code, notes, and snippets.

Show Gist options
  • Select an option

  • Save salehi/d67179038778e0b674a9c6c73a8342d4 to your computer and use it in GitHub Desktop.

Select an option

Save salehi/d67179038778e0b674a9c6c73a8342d4 to your computer and use it in GitHub Desktop.

ZeroTier: Technical Deep Dive, Implementation, and Comparisons

1. ZeroTier's Aim and Goals

ZeroTier is a software-defined networking (SDN) platform that creates virtual Ethernet networks (VLANs) spanning any physical infrastructure—LAN, WAN, cloud, or mobile networks. The core philosophy is:

"Decentralize until it hurts, then centralize until it works."

Primary Goals

  • Global virtual LAN: Make geographically distributed devices appear on the same Layer 2 network
  • Zero-configuration networking: NAT traversal, routing, and peer discovery handled automatically
  • Zero-trust architecture: Cryptographic identity replaces IP-based trust
  • Hardware independence: No proprietary appliances required
  • Low latency: Direct peer-to-peer connections whenever possible

2. Technical Architecture

2.1 Two-Layer Design

ZeroTier implements a dual-layer architecture:

Layer Name Function OSI Equivalent
VL1 Virtual Layer 1 Peer-to-peer transport, encryption, NAT traversal Layer 3 (Network)
VL2 Virtual Layer 2 Ethernet emulation, SDN rules, access control Layer 2 (Data Link)

VL1 handles the "plumbing"—cryptographic identity, peer discovery, hole punching, and encrypted transport.

VL2 sits on top, emulating an Ethernet switch with VLAN boundaries, multicast, flow rules, and certificate-based access control.

2.2 Addressing Scheme

┌─────────────────────────────────────────────────────────────┐
│  ZeroTier Address: 40-bit (10 hex digits)                   │
│  Example: a1b2c3d4e5                                        │
│  Derived from: SHA-512(public_key)[0:40 bits]               │
└─────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────┐
│  Network ID: 64-bit (16 hex digits)                         │
│  Format: [40-bit controller address][24-bit network number] │
│  Example: a1b2c3d4e5000001                                  │
└─────────────────────────────────────────────────────────────┘

Addresses are cryptographically derived—the 40-bit ZeroTier address is computed from the public key, making identity unforgeable without the private key.

2.3 Cryptographic Implementation

Current Protocol (v1.x)

Component Algorithm Notes
Asymmetric Key Exchange Curve25519/Ed25519 256-bit elliptic curve
Symmetric Encryption Salsa20 (256-bit) Stream cipher
Message Authentication Poly1305 Encrypt-then-MAC
MAC Composition NaCl reference implementation
Forward Secrecy Not implemented (v1.x) By design for statelessness

Future Protocol (v2.x / ZSSP)

Component Algorithm Notes
Handshake Pattern Noise XK Identity forward secrecy
Key Exchange ECDH + Kyber1024 Hybrid post-quantum
Symmetric Encryption AES-256-GCM Hardware-accelerated
Nonce Misuse Resistance AES-GMAC-SIV FIPS compliant
Forward Secrecy Yes (ephemeral keys) Per-session

The ZSSP (ZeroTier Secure Sessions Protocol) adds:

  • Post-quantum forward secrecy via Kyber1024
  • Identity forward secrecy (Noise XK vs WireGuard's IK pattern)
  • Built-in fragmentation hardened against DoS

2.4 NAT Traversal Implementation

ZeroTier uses a lazy traversal approach—no complex endpoint characterization state machine:

┌─────────────────────────────────────────────────────────────────────────┐
│                        NAT TRAVERSAL FLOW                               │
├─────────────────────────────────────────────────────────────────────────┤
│                                                                         │
│   [Alice]                    [Root Server]                    [Bob]     │
│      │                            │                            │        │
│      │──── Packet to Bob ────────>│                            │        │
│      │                            │──── Forward to Bob ────────>│       │
│      │                            │                            │        │
│      │<─── VERB_RENDEZVOUS ───────│                            │        │
│      │     (Bob's endpoint hints) │                            │        │
│      │                            │───── VERB_RENDEZVOUS ─────>│        │
│      │                            │      (Alice's endpoints)   │        │
│      │                            │                            │        │
│      │<═══════════ UDP Hole Punch Attempts ═══════════════════>│        │
│      │                            │                            │        │
│      │<══════════════ Direct P2P Connection ══════════════════>│        │
│                                                                         │
└─────────────────────────────────────────────────────────────────────────┘

NAT Types and Success Rate:

NAT Type Traversal Method Success
Full Cone Standard hole punching ✅ Always
Restricted Cone Hole punching ✅ Always
Port Restricted Cone Hole punching ✅ Usually
Symmetric NAT Port prediction + relay fallback ⚠️ Partial
Double NAT Hairpin + LAN discovery ⚠️ Varies

Additional traversal mechanisms:

  • LAN Peer Discovery: UDP broadcast every ~60s for same-network peers
  • Port Prediction: For symmetric NAT traversal
  • uPnP/NAT-PMP: If available on local router
  • Relay Fallback: Root servers relay traffic if direct connection fails

2.5 Network Controller

The controller is the "brain" of each virtual network:

┌─────────────────────────────────────────────────────────────────┐
│                    NETWORK CONTROLLER                            │
├─────────────────────────────────────────────────────────────────┤
│  Functions:                                                      │
│  • Member authorization (join/leave)                            │
│  • IP address assignment (managed IPs)                          │
│  • Route distribution                                           │
│  • Flow rules and ACLs                                          │
│  • Certificate issuance                                         │
│                                                                  │
│  Deployment Options:                                             │
│  • ZeroTier Central (SaaS) - my.zerotier.com                    │
│  • Self-hosted controller                                        │
│  • Embedded in ZeroTierOne binary                               │
└─────────────────────────────────────────────────────────────────┘

2.6 Root Servers (Planets and Moons)

┌─────────────────────────────────────────────────────────────────┐
│  PLANET: Global root servers (operated by ZeroTier)             │
│  • Identity cache (authoritative)                               │
│  • Rendezvous facilitation                                      │
│  • Relay for failed direct connections                          │
│                                                                  │
│  MOON: User-defined root servers                                │
│  • Custom root infrastructure                                   │
│  • Reduced latency for specific regions                         │
│  • Air-gapped network support                                   │
└─────────────────────────────────────────────────────────────────┘

Key Security Property: Root servers cannot decrypt traffic—they only see encrypted packets and facilitate peer discovery. Private keys never leave endpoints.


3. Comparison with Alternative Solutions

3.1 Detailed Technical Comparison Table

Feature ZeroTier Tailscale Nebula WireGuard OpenVPN IPsec
Architecture
Network Model Virtual L2 (Ethernet) Virtual L3 (IP) Overlay L3 Point-to-point tunnel Point-to-point/Site-to-site Site-to-site/Remote access
Topology Full mesh Full mesh Full mesh Star/Mesh (manual) Star Star/Mesh
NAT Traversal Built-in (hole punch + relay) Built-in (DERP relay) Lighthouse-based Manual/External Manual NAT-T extension
Cryptography
Key Exchange Curve25519 Curve25519 (via WG) ECDH (Noise) Curve25519 RSA/ECDH IKEv2/RSA/ECDH
Symmetric Cipher Salsa20/AES-256-GCM ChaCha20-Poly1305 AES-256-GCM ChaCha20-Poly1305 AES-256-GCM/CBC AES-256-GCM/CBC
Forward Secrecy v1: No, v2: Yes Yes Yes Yes Yes (TLS) Yes (IKE)
Post-Quantum v2: Kyber1024 No No No No No
Identity & Auth
Identity Model Cryptographic (40-bit addr) SSO/OAuth Certificates (custom CA) Pre-shared public keys Username/Cert/Token Certificates/PSK
SSO Integration Yes (Enterprise) Yes (native) No No Via plugins Via RADIUS
Key Management Automatic Automatic Manual CA Manual exchange Manual/Automatic Manual/Automatic
Performance
Implementation Userspace Userspace Userspace Kernel (Linux) Userspace Kernel
Typical Throughput ~1 Gbps ~1-3 Gbps ~1-2 Gbps ~5-10 Gbps ~500 Mbps ~2-5 Gbps
Memory Usage ~10 MB ~50-200 MB ~27 MB Minimal (kernel) ~50 MB Minimal (kernel)
CPU Overhead Low-Medium Medium Low-Medium Very Low High Low
Features
SDN Rules Engine Yes (comprehensive) ACLs Built-in firewall No No No
Multicast/Broadcast Yes No No No No No
IPv6 Support Yes (rfc4193, 6plane) Yes Yes Yes Yes Yes
Mobile Support iOS, Android iOS, Android Limited iOS, Android iOS, Android Native
Deployment
Control Plane Central (SaaS/Self-host) Coordination server (SaaS/Headscale) Lighthouse (self-host) None Server (self-host) None/IKE
Setup Complexity Very Low Very Low Medium Medium-High High Very High
Open Source BSL 1.1 Partial (client) Yes (MIT) Yes (GPLv2) Yes (GPLv2) Standards-based

3.2 Architecture Diagrams

ZeroTier Architecture:

                              ┌─────────────────┐
                              │  ZeroTier       │
                              │  Central/       │
                              │  Controller     │
                              └────────┬────────┘
                                       │ Control Plane
            ┌──────────────────────────┼──────────────────────────┐
            │                          │                          │
            ▼                          ▼                          ▼
     ┌─────────────┐            ┌─────────────┐            ┌─────────────┐
     │   Node A    │◄══════════►│   Node B    │◄══════════►│   Node C    │
     │ (za:10.x)   │  P2P Data  │ (zb:10.x)   │  P2P Data  │ (zc:10.x)   │
     └─────────────┘            └─────────────┘            └─────────────┘
            │                          │                          │
            └──────────────────────────┼──────────────────────────┘
                                       │ Fallback Relay
                              ┌────────▼────────┐
                              │   Root Server   │
                              │   (Planet)      │
                              └─────────────────┘

Tailscale Architecture:

                              ┌─────────────────┐
                              │   Tailscale     │
                              │   Coordination  │
                              │   Server        │
                              └────────┬────────┘
                                       │ Control + Auth
            ┌──────────────────────────┼──────────────────────────┐
            │                          │                          │
            ▼                          ▼                          ▼
     ┌─────────────┐            ┌─────────────┐            ┌─────────────┐
     │   Node A    │◄══════════►│   Node B    │◄══════════►│   Node C    │
     │ WireGuard   │  P2P Data  │ WireGuard   │  P2P Data  │ WireGuard   │
     └─────────────┘            └─────────────┘            └─────────────┘
            │                          │                          │
            └──────────────────────────┼──────────────────────────┘
                                       │ Fallback
                              ┌────────▼────────┐
                              │   DERP Relay    │
                              └─────────────────┘

Traditional VPN (Hub-and-Spoke):

                              ┌─────────────────┐
                              │   VPN Gateway   │
                              │   (OpenVPN/     │
                              │    IPsec)       │
                              └────────┬────────┘
                                       │
            ┌──────────────────────────┼──────────────────────────┐
            │                          │                          │
            ▼                          ▼                          ▼
     ┌─────────────┐            ┌─────────────┐            ┌─────────────┐
     │  Client A   │            │  Client B   │            │  Client C   │
     │             │            │             │            │             │
     └─────────────┘            └─────────────┘            └─────────────┘
     
     Note: All traffic flows through central gateway (hairpin routing)

4. Comparison with Tor

Tor and ZeroTier solve fundamentally different problems, but both create overlay networks. Here's the technical comparison:

4.1 Core Design Philosophy

Aspect ZeroTier Tor
Primary Goal Performance + Connectivity Anonymity + Censorship Resistance
Trade-off Speed over anonymity Anonymity over speed
Trust Model Known peers, cryptographic identity No trust required, layered anonymity
Routing Direct peer-to-peer Multi-hop onion routing (3+ relays)
Latency Target Milliseconds Hundreds of milliseconds

4.2 Technical Comparison Table

Feature ZeroTier Tor
Network Layer
OSI Layer Layer 2/3 (Ethernet/IP) Layer 7 (SOCKS proxy, TCP streams)
Protocol Custom (VL1/VL2) Onion routing protocol
Transport UDP (primary), TCP fallback TCP only
Addressing
Address Format 40-bit cryptographic ID .onion (56 chars, v3) = Base32(public_key)
Address Derivation SHA-512(pubkey)[0:40] Full pubkey encoding
DNS Integration None (virtual IPs) None (.onion pseudo-TLD)
Cryptography
Circuit Encryption Single layer (E2E) Multi-layer (onion, 3+ layers)
Key Exchange Curve25519 Curve25519 + ntor handshake
Symmetric Cipher Salsa20/AES-256 AES-128-CTR
Forward Secrecy v2: Yes Yes (ephemeral keys per circuit)
Routing
Path Length 1 hop (direct) or 2 (relay) 6 hops minimum (3 client + 3 server for .onion)
Relay Selection Deterministic (root servers) Random from consensus
Path Stability Persistent Circuits rebuilt every 10 min
Anonymity Properties
Source IP Hidden No (peers know each other) Yes (from destination)
Destination Hidden No Yes (.onion services)
Traffic Analysis Resistance None Moderate (vulnerable to correlation)
Metadata Protection None High (multi-layer encryption)
Performance
Typical Latency 5-50 ms 200-800 ms
Throughput Hundreds of Mbps to Gbps 1-10 Mbps typical
Connection Setup Fast (stateless, lazy) Slow (circuit building, 6+ handshakes)
Use Cases
Remote Access ✅ Primary ⚠️ Possible but slow
Site-to-Site VPN ✅ Primary ❌ Not designed for this
Anonymous Browsing ❌ Not designed for this ✅ Primary
Hidden Services ❌ N/A ✅ Primary
IoT/Embedded ✅ Good ❌ Resource-intensive
Gaming/Real-time ✅ Good ❌ Too slow

4.3 Tor Circuit Architecture (for reference)

┌────────────────────────────────────────────────────────────────────────────┐
│                      TOR ONION SERVICE CONNECTION                          │
├────────────────────────────────────────────────────────────────────────────┤
│                                                                            │
│  CLIENT SIDE (3 hops)              SERVER SIDE (3 hops)                   │
│                                                                            │
│  ┌────────┐      ┌────────┐      ┌────────┐      ┌────────┐               │
│  │ Client │──────│ Guard  │──────│ Middle │──────│ Rende- │               │
│  │        │ E3   │ Node   │ E2   │ Node   │ E1   │ zvous  │               │
│  └────────┘      └────────┘      └────────┘      └────────┘               │
│                                         │                                  │
│                                         │                                  │
│  ┌────────┐      ┌────────┐      ┌────────┐      │                        │
│  │ Hidden │──────│ Guard  │──────│ Middle │──────┘                        │
│  │Service │ E3'  │ Node'  │ E2'  │ Node'  │ E1'                           │
│  └────────┘      └────────┘      └────────┘                               │
│                                                                            │
│  E1/E2/E3 = Encryption layers (peeled at each hop)                        │
│  Total: 6 encryption layers, 6 relays, 12 network hops                    │
│                                                                            │
└────────────────────────────────────────────────────────────────────────────┘

4.4 When to Use Which

Scenario ZeroTier Tor Traditional VPN
Corporate remote access ✅ Ideal ✅ Viable
IoT fleet management ✅ Ideal ⚠️ Complex
Gaming with friends ✅ Good ⚠️ Latency
Anonymous browsing ✅ Ideal ⚠️ Not anonymous
Whistleblowing ✅ Ideal
Bypass censorship ⚠️ Limited ✅ Ideal ⚠️ Blocked
Site-to-site enterprise ✅ Good ✅ Traditional choice
Development environments ✅ Ideal ⚠️ Overhead

5. Security Considerations

5.1 ZeroTier Security Properties

Strengths:

  • End-to-end encryption (peers can't read each other's traffic through roots)
  • Cryptographic identity (unforgeable addresses)
  • Audited by Trail of Bits (AES-GMAC-SIV construction verified)
  • FIPS-compliant option available (v2)
  • Post-quantum forward secrecy roadmap

Limitations:

  • v1.x: No forward secrecy (compromise of long-term key compromises past traffic)
  • Control plane trust: ZeroTier Central can authorize/deauthorize nodes
  • Not anonymous: Peers know each other's endpoints
  • Metadata visible: Traffic patterns, connection times visible to network observers

5.2 Threat Model Comparison

Threat ZeroTier Tor Traditional VPN
Passive eavesdropping ✅ Protected ✅ Protected ✅ Protected
Active MITM ✅ Protected ✅ Protected ✅ Protected
Endpoint compromise ⚠️ Limited protection ⚠️ Limited protection ⚠️ Limited
Traffic analysis ❌ Vulnerable ⚠️ Partially protected ❌ Vulnerable
Global adversary ❌ Vulnerable ⚠️ Correlation attacks possible ❌ Vulnerable
Metadata collection ❌ Exposed ⚠️ Partially hidden ❌ Exposed
Quantum computing (future) ✅ v2 protected ❌ Vulnerable ❌ Vulnerable

6. Summary Decision Matrix

Requirement Best Choice Runner-up
Easiest setup Tailscale ZeroTier
Best performance WireGuard (kernel) ZeroTier
Layer 2 networking ZeroTier N/A
Full open source Nebula or WireGuard N/A
Enterprise SSO Tailscale ZeroTier Enterprise
Self-hosted everything Nebula or Headscale ZeroTier self-hosted
Anonymity required Tor N/A
IoT/Embedded devices ZeroTier Nebula
Government/FIPS ZeroTier v2 IPsec
Maximum throughput WireGuard (kernel) IPsec
Legacy compatibility IPsec or OpenVPN N/A

7. References

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment