Deep Dive: VPNs, WireGuard & Overlay Networks with C

Goal: By completing these projects, you’ll deeply understand how modern VPNs work from first principles—not just “install WireGuard and configure it,” but actually comprehending packet flow through TUN devices, cryptographic handshakes, NAT traversal mechanics, and why mesh networks like Tailscale can establish direct peer connections. You’ll internalize the architectural decisions behind WireGuard’s simplicity versus IPsec’s complexity, understand the real-world challenges of building secure tunnels, and gain the ability to reason about, troubleshoot, and even implement your own VPN-like systems. This knowledge transfers directly to understanding zero-trust architectures, service meshes, and modern cloud networking.

Why VPNs and Modern Overlay Networks Matter

The Evolution of VPN Technology

Back in 2015, Jason Donenfeld—a security researcher and Linux kernel developer—was frustrated. He needed a stealthy traffic tunneling solution for penetration testing, but the existing options (OpenVPN, IPsec/IKEv2) were nightmarishly complex, bug-prone, and used outdated cryptography. As Donenfeld later explained, “I was familiar with OpenVPN and IPsec, but I was well aware of the bugs these solutions carried.” The “dizzying complexity, bloated implementations, and often outdated cryptography created a worrisome target.”

So he created WireGuard—a VPN protocol so elegant that even Linus Torvalds praised it: “Maybe the code isn’t perfect, but I’ve skimmed it, and compared to the horrors that are OpenVPN and IPSec, it’s a work of art.”

WireGuard kernel code: ~4,000 lines OpenVPN: ~100,000+ lines IPsec (strongSwan): ~400,000+ lines

By 2020, WireGuard was merged into the Linux kernel (5.6). Today, it’s the foundation for modern mesh networks like Tailscale, which raised $160 million in 2024 and is now used by leading AI companies (Perplexity, Mistral, Cohere, Groq, Hugging Face) to secure their infrastructure.

Market Reality (2024-2025)

VPN Market Growth:

Global VPN market: Projected $61.42B in 2024 → $71.6B in 2025 (Source)
Consumer VPN usage: 1.2 billion active VPN users globally, though US usage declined from 46% (2023) to 32% (2025) (Source)
Enterprise adoption: 93% of large enterprises use VPNs, 40% adoption in US companies, 74% of remote-friendly companies require VPNs (Source)
Corporate VPN market: Cisco holds ~54% market share, business VPN market valued at $31.5B (2024) → projected $69.3B by 2030

WireGuard Adoption:

Performance: WireGuard is ~57% faster than OpenVPN on average, reaching 750+ Mbps with nearby servers (Source)
Enterprise uptake: Rapidly displacing legacy protocols due to efficiency, speed, and modern encryption (Source)

Tailscale’s Explosive Growth:

Customer growth: 5,000 paid customers (March 2024) → 10,000 (10 months later) → 20,000 (late 2025) (Source)
Revenue growth: 3,299% three-year revenue expansion (14th on Deloitte’s Canada fastest-growing companies) (Source)
Valuation & funding: $2 billion valuation, $230M total raised including $160M Series C (2025) led by Accel (Source)
Active users: 500,000+ weekly active users, millions total (Source)
AI/ML adoption: Serving AI companies (Perplexity, Mistral, Cohere, Groq, Hugging Face) + enterprise (Telus, Instacart, SAP, Nvidia, Microsoft) (Source)

Why AI Companies Choose Tailscale:

Low-latency mesh networks critical for distributed GPU training
Zero-trust security for multi-cloud infrastructure
Seamless connectivity between cloud providers, on-prem, and developer machines

Why Traditional VPNs Failed

Traditional IPsec VPN Architecture:
┌─────────────────────────────────────────────────────────┐
│                    IPsec/IKEv2 Stack                    │
├─────────────────────────────────────────────────────────┤
│ IKEv2 Daemon (400K+ lines) - Key exchange, policies    │
│  ↓                                                      │
│ IPsec Kernel Module - Packet encryption/routing        │
│  ↓                                                      │
│ Complex policy database - SPD, SAD, tunnel configs     │
└─────────────────────────────────────────────────────────┘
Problems:
• Massive attack surface (hundreds of thousands of lines)
• Configuration nightmare (dozens of knobs to turn)
• Fragile NAT traversal (NAT-T is hacky and unreliable)
• Slow cryptography (AES-GCM requires hardware acceleration)
• Difficult debugging (opaque state machines)

WireGuard Architecture:
┌─────────────────────────────────────────────────────────┐
│                  WireGuard (4K lines)                   │
├─────────────────────────────────────────────────────────┤
│ Simple config: public keys, endpoints, allowed IPs     │
│  ↓                                                      │
│ Noise protocol handshake (1-RTT)                       │
│  ↓                                                      │
│ ChaCha20-Poly1305 encryption (fast in software)        │
│  ↓                                                      │
│ UDP packets - just works through NAT                   │
└─────────────────────────────────────────────────────────┘
Advantages:
✓ Minimal code = minimal bugs
✓ 10-line config file vs pages of IPsec config
✓ NAT traversal built-in (it's just UDP!)
✓ Modern crypto (no need for AES-NI)
✓ Debuggable with simple packet captures

The Tailscale Innovation

WireGuard solved the crypto/protocol problem. Tailscale solved the “how do my devices find each other?” problem:

Traditional VPN:                    Tailscale Mesh VPN:
┌──────────────┐                   ┌──────────────┐
│   Laptop     │                   │   Laptop     │
└──────┬───────┘                   └──────┬───────┘
       │                                  │ (direct P2P via
       │ (must route through              │  NAT hole punch)
       │  central gateway)                │
       ▼                                  ▼
┌──────────────┐                   ┌──────────────┐
│ VPN Gateway  │◄─────────────────►│  Phone       │
│   (SPOF)     │                   └──────┬───────┘
└──────┬───────┘                          │
       │                                  │ (coordinator only
       │                                  │  for discovery)
       ▼                                  ▼
┌──────────────┐              ┌─────────────────────┐
│ Home Server  │              │ Coordination Server │
└──────────────┘              │  (just metadata)    │
                              └─────────────────────┘
Single point of failure       Full mesh, no SPOF
All traffic hairpins          Direct connections
High latency                  Low latency

Why this matters for AI/ML: Training distributed models requires low-latency, high-throughput connections between GPUs. Tailscale lets AI companies connect cloud GPUs, on-prem hardware, and dev machines in a zero-trust mesh without complex VPN gateways.

Why this matters for you: Understanding these systems means you can reason about modern cloud networking, debug connectivity issues, and build secure distributed systems. These projects teach you the foundational concepts that power services like AWS VPC peering, Kubernetes pod networking, and service meshes (Istio, Linkerd).

Prerequisites & Background Knowledge

Essential Prerequisites (Must Have)

Before diving into these projects, you should be comfortable with:

C Programming Fundamentals
- Pointers, structs, memory allocation
- System calls (read(), write(), open(), ioctl())
- Working with file descriptors
- Book: “C Programming: A Modern Approach” by K.N. King (Ch. 11, 13, 17, 20)
Basic Networking Concepts
- IP addressing (IPv4/IPv6)
- TCP vs UDP differences
- What “port numbers” mean
- Basic understanding of routing (“packets go from A to B”)
- Book: “Computer Networks” by Tanenbaum & Wetherall (Ch. 1, 4, 5)
Linux Command Line Comfort
- Using ip command to view interfaces/routes
- Basic tcpdump or Wireshark for packet captures
- SSH, ping, nc (netcat) for testing connectivity
- Book: “How Linux Works” by Brian Ward (Ch. 9)
Programming Tools
- GCC compilation, Makefiles
- GDB for debugging
- Valgrind for memory leak detection

Helpful But Not Required (You’ll Learn These)

These topics are covered through the projects themselves:

Cryptography details (ChaCha20, Curve25519, Noise Protocol) - Project 3-4 teach this
Advanced socket programming (select(), poll(), non-blocking I/O) - Learned in Project 2
Kernel module interaction (TUN/TAP devices) - Project 1 introduces this
NAT behavior and hole punching - Project 5 explains thoroughly

Self-Assessment Questions

Answer these to gauge your readiness:

Can you write a C program that opens a file, reads bytes, and writes them to another file?
Do you know what an IP address like 192.168.1.100 represents?
Can you explain the difference between TCP and UDP in one sentence?
Have you used ping and understand it sends ICMP packets?
Can you compile a C program with multiple files using gcc?
Are you comfortable reading man pages (man 2 socket)?

If you answered “yes” to 4+, you’re ready. If fewer than 4, spend 1-2 weeks on C basics and networking fundamentals first.

Development Environment Setup

Required:

Linux system (Ubuntu 22.04+, Debian, Fedora, Arch - anything recent works)
- WSL2 on Windows works for most projects
- macOS works but requires macOS-specific TUN/TAP setup (tuntaposx)
GCC or Clang compiler
Root/sudo access (needed for creating TUN devices and modifying routes)
Wireshark or tcpdump (for packet inspection)
Git (for version control and accessing reference implementations)

Recommended:

Two machines or VMs (for testing tunnel between endpoints)
- Alternatives: Docker containers, network namespaces
libsodium-dev (for crypto projects) - install via apt install libsodium-dev
tmux (for managing multiple terminals during testing)
A public VPS (~$5/month) for NAT traversal testing (Project 5)

Installation commands (Ubuntu/Debian):

sudo apt update
sudo apt install build-essential libsodium-dev wireshark tcpdump \
                 git tmux iproute2 iptables net-tools

Time Investment

Realistic estimates for someone with the prerequisites:

Project	Time	Intensity
1. TUN Packet Logger	1-2 weeks (8-15 hrs)	Moderate - lots of docs reading
2. UDP Tunnel	1-2 weeks (10-20 hrs)	High - debugging packet flow
3. Add Encryption	1-2 weeks (8-12 hrs)	Moderate - if you use libsodium
4. Key Exchange	2-3 weeks (15-25 hrs)	High - crypto protocols are tricky
5. NAT Traversal	2-3 weeks (15-30 hrs)	High - complex timing/coordination
Capstone (Mini-Tailscale)	1-2 months (40-80 hrs)	Very High - integrates everything

Total: 3-6 months of focused, part-time work (evenings/weekends)

Important Reality Check

These are not tutorial-style “follow along” projects. They’re engineering challenges where:

You’ll read documentation extensively (RFCs, man pages, library docs)
You’ll debug confusing packet flows and segfaults
You’ll encounter “it works on my machine but not on yours” issues
You’ll need to read WireGuard/Tailscale source code to understand edge cases

This is realistic systems programming. It’s hard, occasionally frustrating, and incredibly rewarding. You’ll emerge with deep knowledge that most developers never acquire.

If you want easier, more guided projects, consider web development tutorials. If you want to understand how the internet actually works, these projects are for you.

Core Concept Analysis

To truly understand VPNs and overlay networks, you need to grasp these building blocks:

Layer 1: Network Foundations

TUN/TAP Virtual Interfaces

Think of a TUN device as a “fake” network card that exists purely in software. When you write packets to it, the kernel routes them just like packets from a real ethernet card—except your VPN program gets to read them first.

Normal Network Interface:          TUN Virtual Interface:
┌─────────────────┐                ┌─────────────────┐
│  Application    │                │  Application    │
│   (curl)        │                │   (curl)        │
└────────┬────────┘                └────────┬────────┘
         │ socket()                         │ socket()
         ▼                                  ▼
    ┌────────┐                         ┌────────┐
    │ Kernel │                         │ Kernel │
    │ TCP/IP │                         │ TCP/IP │
    │ Stack  │                         │ Stack  │
    └────┬───┘                         └────┬───┘
         │                                  │
         ▼                                  ▼
   ┌──────────┐                      ┌──────────┐
   │   eth0   │                      │   tun0   │◄────┐
   │ (real)   │                      │ (virtual)│     │
   └─────┬────┘                      └─────┬────┘     │
         │                                 │          │
         ▼                                 │          │
    Physical                               │          │
    Network                                ▼          │
                                    Your VPN Program  │
                                    reads/writes ─────┘

Key insight: A VPN intercepts packets before they hit the wire and re-routes them through an encrypted tunnel.

Books:

“The Linux Programming Interface” by Kerrisk (Ch. 64) - Virtual network devices
“Understanding Linux Network Internals” by Benvenuti (Ch. 10) - How TUN/TAP works in kernel

IP Packet Structure

Every packet has a header (metadata) and a payload (actual data). The header tells routers where to send it:

IP Packet (simplified):
┌────────────────────────────────────────────────────┐
│               IP Header (20+ bytes)                │
├────────────────────────────────────────────────────┤
│ Version (4/6) │ Header Len │ Total Length         │
│ Source IP: 192.168.1.100   │ Dest IP: 8.8.8.8     │
│ Protocol: 17 (UDP) or 6 (TCP) or 1 (ICMP)         │
│ TTL │ Checksum │ Options...                        │
├────────────────────────────────────────────────────┤
│                   Payload                          │
│  (TCP/UDP/ICMP header + application data)          │
└────────────────────────────────────────────────────┘

Why VPNs care: Your VPN reads the entire packet (including header), encrypts everything, and wraps it in a new packet. The outer packet header has your VPN server’s address; the inner packet is encrypted.

Books:

“TCP/IP Illustrated, Volume 1” by Stevens (Ch. 3-4) - IP packet format
“Computer Networks” by Tanenbaum (Ch. 5) - Network layer in depth

UDP Sockets and Why VPNs Use UDP

TCP (connection-oriented):         UDP (connectionless):
┌────────────────────────┐        ┌────────────────────────┐
│ 3-way handshake setup  │        │ Just send packets!     │
│ SYN → SYN-ACK → ACK    │        │ (no connection setup)  │
├────────────────────────┤        ├────────────────────────┤
│ Guaranteed delivery    │        │ Best-effort delivery   │
│ (retransmits lost pkts)│        │ (packet may be lost)   │
├────────────────────────┤        ├────────────────────────┤
│ In-order delivery      │        │ May arrive out-of-order│
└────────────────────────┘        └────────────────────────┘

TCP-over-TCP Problem:              UDP Tunnel Solution:
┌──────────────────────┐          ┌──────────────────────┐
│ App uses TCP         │          │ App uses TCP         │
│   ↓                  │          │   ↓                  │
│ VPN tunnels over TCP │          │ VPN tunnels over UDP │
│   ↓                  │          │   ↓                  │
│ Both layers retrans- │          │ Only inner TCP       │
│ mit on loss →→ BAD!  │          │ retransmits →→ GOOD! │
└──────────────────────┘          └──────────────────────┘

Why this matters: WireGuard uses UDP because it avoids the “TCP meltdown” problem where nested TCP layers fight over retransmissions. Also, UDP works better through NAT.

Books:

“TCP/IP Sockets in C” by Donahoo & Calvert (Ch. 4) - UDP programming
“The Sockets Networking API” by Stevens (Ch. 8) - UDP sockets in detail

Routing Tables

When a packet arrives, the kernel checks: “Which interface should I send this out of?”

$ ip route show
default via 192.168.1.1 dev eth0          # Catch-all: send to gateway
10.0.0.0/24 dev tun0                      # VPN subnet: use TUN device
192.168.1.0/24 dev eth0                   # Local network: use eth0

Packet routing decision:
┌────────────────────────┐
│ Packet dest: 10.0.0.5  │
└────────┬───────────────┘
         │
         ▼
  ┌─────────────────────┐
  │ Check routing table │
  └─────────┬───────────┘
            │
            ├─ Matches 10.0.0.0/24? → YES → Send to tun0
            ├─ Matches 192.168.1.0/24? → NO
            └─ Matches default? → NO (already matched above)

Key insight: Your VPN adds routes that hijack traffic destined for remote networks and redirect it through the TUN device (where your VPN can encrypt it).

Books:

“Computer Networks” by Tanenbaum (Ch. 5.5) - IP routing algorithms
“TCP/IP Illustrated, Volume 1” by Stevens (Ch. 9) - Routing in practice

Layer 2: Cryptographic Primitives

Symmetric Encryption (ChaCha20-Poly1305)

Once both sides agree on a shared secret key, they use symmetric encryption for speed:

Sender:                           Receiver:
┌──────────────┐                 ┌──────────────┐
│ Plaintext    │                 │ Ciphertext   │
│ packet       │                 │ from network │
└──────┬───────┘                 └──────┬───────┘
       │                                │
       ▼                                ▼
   ┌────────────────┐             ┌────────────────┐
   │ Shared Key +   │             │ Same Shared Key│
   │ Nonce (unique) │             │ + Same Nonce   │
   └────────┬───────┘             └────────┬───────┘
            │                              │
            ▼                              ▼
   ChaCha20 Encrypt                ChaCha20 Decrypt
            │                              │
            ▼                              ▼
   ┌───────────────────┐          ┌───────────────┐
   │ Ciphertext +      │──────────►│ Plaintext    │
   │ Auth Tag (Poly)   │ Network  │ (verified)   │
   └───────────────────┘          └───────────────┘

Why ChaCha20-Poly1305?

Fast in software (no need for AES-NI CPU instructions)
Constant-time (no timing side-channels)
AEAD (Authenticated Encryption with Associated Data) - prevents tampering

Books:

“Serious Cryptography” by Aumasson (Ch. 5, 8) - Stream ciphers and AEAD
“Real-World Cryptography” by Wong (Ch. 6) - Symmetric encryption in practice

Asymmetric Key Exchange (Curve25519)

How do two strangers agree on a shared secret without transmitting it?

Alice                                    Bob
┌─────────────────┐                ┌─────────────────┐
│ Private: a      │                │ Private: b      │
│ Public: A = a*G │                │ Public: B = b*G │
└────────┬────────┘                └────────┬────────┘
         │                                  │
         │ Send public key A ──────────────►│
         │◄──────────────── Send public B  │
         │                                  │
         ▼                                  ▼
   Compute S = a*B                    Compute S = b*A
         │                                  │
         └──────── Both get same S ────────┘
                    (shared secret!)

Math: a*B = a*(b*G) = (a*b)*G = b*(a*G) = b*A
So both sides compute the same value without transmitting it!

Why Curve25519?

Fast (elliptic curve operations are efficient)
Secure (no known weaknesses)
Simple API (hard to misuse)

Books:

“Serious Cryptography” by Aumasson (Ch. 11-12) - DH and elliptic curves
“Real-World Cryptography” by Wong (Ch. 8) - Key exchange protocols

Noise Protocol Framework (WireGuard’s Handshake)

WireGuard uses the Noise “IK” pattern: Initiator knows responder’s static key, Key confirmation.

WireGuard Handshake (Noise IK):
Initiator (Client)                Responder (Server)
┌─────────────────┐              ┌─────────────────┐
│ Static: s_i     │              │ Static: s_r     │
│ Ephemeral: e_i  │              │ Ephemeral: e_r  │
└────────┬────────┘              └────────┬────────┘
         │                                │
         │  Msg 1: e_i, encrypted(s_i)   │
         │───────────────────────────────►│
         │                                │
         │  Msg 2: e_r, encrypted(ack)   │
         │◄───────────────────────────────│
         │                                │
         ▼                                ▼
    Derive keys                      Derive keys
    (from e_i, e_r, s_i, s_r)        (same inputs)
         │                                │
         └─── Both sides have ────────────┘
              shared symmetric keys

Forward Secrecy: Even if s_i or s_r is compromised later,
                 old sessions stay secure (ephemeral keys e_i, e_r are deleted)

Books:

Noise Protocol Framework spec (noiseprotocol.org) - The definitive reference
WireGuard whitepaper by Donenfeld - How WireGuard implements Noise IK
“Real-World Cryptography” by Wong (Ch. 16) - Modern handshake protocols

Layer 3: Protocol Design

Tunneling (Encapsulation)

A VPN wraps your original packet inside another packet:

Before VPN:                        After VPN:
┌────────────────────┐            ┌─────────────────────────────────┐
│ IP Header          │            │ Outer IP Header                 │
│ Src: 192.168.1.100 │            │ Src: Your public IP             │
│ Dst: 8.8.8.8       │            │ Dst: VPN server IP              │
├────────────────────┤            ├─────────────────────────────────┤
│ UDP Header         │            │ UDP Header (VPN port)           │
│ DNS query          │            ├─────────────────────────────────┤
└────────────────────┘            │ Encrypted payload:              │
                                  │ ┌─────────────────────────────┐ │
                                  │ │ Inner IP Header (encrypted) │ │
                                  │ │ Src: 192.168.1.100          │ │
                                  │ │ Dst: 8.8.8.8                │ │
                                  │ ├─────────────────────────────┤ │
                                  │ │ UDP Header (encrypted)      │ │
                                  │ │ DNS query (encrypted)       │ │
                                  │ └─────────────────────────────┘ │
                                  └─────────────────────────────────┘

Why this works: ISP sees traffic to VPN server IP, but can’t see what’s inside (encrypted). VPN server decrypts and forwards the inner packet.

Books:

“Computer Networks” by Tanenbaum (Ch. 5.7) - Tunneling protocols
“TCP/IP Illustrated, Volume 1” by Stevens (Ch. 3) - IP encapsulation

NAT Traversal

Most devices are behind NAT (home routers, corporate firewalls). NAT blocks incoming connections but allows outgoing ones. How can two NATed peers connect?

Traditional Problem:
┌────────────┐  NAT  ┌─────────┐       ┌─────────┐  NAT  ┌────────────┐
│ Client A   │◄─────►│ Router  │◄─────►│ Router  │◄─────►│ Client B   │
│ 192.168.1.5│       │ 1.2.3.4 │       │ 5.6.7.8 │       │ 10.0.0.5   │
└────────────┘       └─────────┘       └─────────┘       └────────────┘
      │                                                         │
      └──── A can't send directly to B ───────────────────────►X
            (NAT blocks unsolicited incoming packets)

UDP Hole Punching Solution:
┌────────────┐  NAT  ┌─────────┐       ┌──────────────┐
│ Client A   │◄─────►│ Router  │◄─────►│ Coordination │
│ 192.168.1.5│       │ 1.2.3.4 │       │    Server    │
└────────────┘       └─────────┘       │  3.3.3.3     │
                                       └───────┬──────┘
┌────────────┐  NAT  ┌─────────┐             │
│ Client B   │◄─────►│ Router  │◄────────────┘
│ 10.0.0.5   │       │ 5.6.7.8 │
└────────────┘       └─────────┘

Steps:
1. Both A and B connect to coordination server (creates NAT mappings)
2. Server tells A: "B is reachable at 5.6.7.8:12345"
3. Server tells B: "A is reachable at 1.2.3.4:54321"
4. A and B simultaneously send packets to each other
5. Packets arrive, NAT thinks "this is a reply to my outgoing packet" → allows it through!
6. Direct P2P connection established

This is Tailscale’s secret sauce: Coordination server (control plane) helps peers discover each other, then they connect directly (data plane).

Books:

RFC 5389 (STUN) - How to discover your external IP
“Peer-to-Peer Communication Across NATs” (Ford et al. paper) - The foundational hole-punching paper

Mesh Networking

Traditional VPN: star topology (everyone connects to central hub) Modern mesh VPN: every peer connects directly to every other peer

Star (Traditional):            Mesh (Tailscale):
      Hub                      Peer 1
       │                      ╱  │  ╲
    ╱──┼──╲                 ╱    │    ╲
   A   B   C               A─────┼─────C
                              ╲  │  ╱
Single point of failure        ╲│╱
All traffic hairpins           Peer B
High latency
                            Direct connections
                            Redundant paths
                            Low latency

Books:

“Computer Networks” by Tanenbaum (Ch. 4.4) - Routing in networks
Tailscale blog: “How Tailscale Works” - Real-world mesh architecture

Concept Summary Table

Concept	What You Must Internalize	Project(s)
TUN/TAP devices	How userspace programs intercept kernel packets	1
IP packet parsing	Reading headers to understand what’s being sent	1
UDP sockets	Connectionless communication, message boundaries	2
I/O multiplexing (`select/poll`)	Handling multiple file descriptors simultaneously	2
Routing tables	How kernel decides which interface to use	1, 2
Symmetric encryption (AEAD)	ChaCha20-Poly1305, nonce management, auth tags	3
Key exchange (DH/ECDH)	Curve25519, deriving shared secrets	4
Noise Protocol	Handshake state machines, forward secrecy	4
NAT types	Full Cone, Restricted, Symmetric NAT behavior	5
STUN	Discovering your external IP:port	5
Hole punching	Timing simultaneous sends to traverse NAT	5
Coordination protocols	Peer registration, endpoint exchange	Capstone
Mesh state management	Connection states, rekeying, peer churn	Capstone

Deep Dive Reading by Concept

For TUN/TAP and Virtual Interfaces

| Book | Chapters | Why It Matters | |——|———-|—————-| | The Linux Programming Interface (Kerrisk) | Ch. 64 | Definitive explanation of creating/managing TUN/TAP devices | | Understanding Linux Network Internals (Benvenuti) | Ch. 10, 11 | How virtual devices integrate with kernel networking stack |

For IP and Network Protocols

| Book | Chapters | Why It Matters | |——|———-|—————-| | TCP/IP Illustrated, Volume 1 (Stevens/Fall) | Ch. 3-6, 8-10 | Visual packet dissection, IP/ICMP/UDP/TCP headers | | Computer Networks (Tanenbaum) | Ch. 4, 5 | Network layer theory, routing algorithms |

For Socket Programming

| Book | Chapters | Why It Matters | |——|———-|—————-| | TCP/IP Sockets in C (Donahoo/Calvert) | Ch. 4, 6 | Practical UDP socket code, I/O multiplexing | | The Sockets Networking API (Stevens) | Ch. 6, 8, 14 | Advanced topics: non-blocking I/O, select/poll |

For Cryptography

For Systems Programming

For Debugging and Tools

| Book | Chapters | Why It Matters | |——|———-|—————-| | The Art of Debugging with GDB (Matloff) | Ch. 1-5 | Debugging network programs, segfaults, packet flows |

Quick Start (For the Overwhelmed)

If you’re looking at this and thinking “this is too much,” here’s your first 48 hours:

Day 1: Understand TUN Devices (4 hours)

Read “The Linux Programming Interface” Ch. 64 (TUN/TAP section) - 2 hours
Create a minimal TUN device in C (copy example from Kerrisk) - 1 hour
Run ping through your TUN device and see packets appear - 1 hour

Success criterion: You see raw packets printed to stdout when you ping.

Day 2: Parse IP Headers (4 hours)

Read TCP/IP Illustrated Vol 1, Ch. 3 (IP header format) - 1.5 hours
Add IP header parsing to your Day 1 code - 2 hours
Display: source IP, dest IP, protocol, length - 0.5 hours

Success criterion: Your program correctly identifies ping as ICMP, shows 192.168.x.x addresses.

Weekend: Build Your First Tunnel (8-12 hours)

Combine TUN device + UDP socket. Send packets from TUN out UDP socket to peer, receive UDP packets and inject into peer’s TUN.

Success criterion: ping 10.0.0.2 on Machine A reaches Machine B through your tunnel.

If this works, you’re ready for the full project sequence. If it’s too hard, step back and strengthen C fundamentals first.

Recommended Learning Paths

Path 1: “I Want to Understand WireGuard” (3-4 months)

Projects 1 → 2 → 3 → 4 Focus: Crypto and protocol design Outcome: You can explain WireGuard’s design choices and security model

Path 2: “I Want to Build Tailscale-like Systems” (4-6 months)

Projects 1 → 2 → 5 → Capstone Focus: NAT traversal, mesh networking, coordination Outcome: You can build your own mesh VPN

Path 3: “I Want Deep Systems Knowledge” (6+ months)

All projects in order (1 → 2 → 3 → 4 → 5 → Capstone) Focus: Complete understanding from packets to mesh Outcome: You’re a VPN/networking expert

Path 4: “I Just Want the Basics” (1-2 months)

Projects 1 → 2 Focus: Virtual interfaces and tunneling fundamentals Outcome: You understand how VPNs work conceptually

Project 1: TUN Interface Packet Logger

File: VPN_WIREGUARD_TAILSCALE_LEARNING_PROJECTS.md
Programming Language: C
Coolness Level: Level 3: Genuinely Clever
Business Potential: 3. The “Service & Support” Model
Difficulty: Level 2: Intermediate
Knowledge Area: Networking / Linux Kernel Interface
Software or Tool: TUN/TAP
Main Book: “The Linux Programming Interface” by Michael Kerrisk

What you’ll build: A C program that creates a virtual network interface (TUN device), captures all packets routed through it, and displays their structure in real-time on the terminal.

Why it teaches VPNs: Every VPN starts with a TUN/TAP interface. This is the “magic” that makes your OS think there’s a real network device. You’ll see raw IP packets exactly as WireGuard sees them before encryption.

Core challenges you’ll face:

Opening and configuring a TUN device via ioctl() (maps to understanding virtual interfaces)
Parsing IP packet headers (maps to understanding what VPNs actually encrypt)
Setting up routes so traffic flows through your interface (maps to VPN routing)
Handling both IPv4 and IPv6 packets (maps to dual-stack VPN support)

Key Concepts:

TUN/TAP interfaces: “The Linux Programming Interface” by Michael Kerrisk (Ch. 64) - Definitive explanation of virtual network devices
IP packet structure: “TCP/IP Illustrated, Volume 1” by W. Richard Stevens (Ch. 3-4) - Visual breakdown of IP headers
ioctl system calls: “Advanced Programming in the UNIX® Environment” by Stevens & Rago (Ch. 17)
Raw sockets: “The Sockets Networking API” by Stevens, Fenner & Rudoff (Ch. 28)

Difficulty: Intermediate Time estimate: 1-2 weeks Prerequisites: Basic C, familiarity with Linux command line, understanding of IP addresses

Real world outcome:

When your program works, you’ll see something magical—packets flowing through your software “network card”:

$ sudo ./tun_logger
[INFO] Created TUN device: tun0
[INFO] Device configured with IP 10.0.0.1/24
[INFO] Waiting for packets...

# In another terminal:
$ ping -c 3 10.0.0.2

# Back in your tun_logger output:
[2025-01-15 14:23:45] IPv4 Packet captured (84 bytes)
┌─────────────────────────────────────────────────────────┐
│ IP Header                                               │
├─────────────────────────────────────────────────────────┤
│ Version: 4                 Header Length: 20 bytes      │
│ Total Length: 84           Protocol: 1 (ICMP)           │
│ Source IP: 10.0.0.1                                     │
│ Dest IP: 10.0.0.2                                       │
│ TTL: 64                    Checksum: 0x3c4d             │
├─────────────────────────────────────────────────────────┤
│ ICMP Header                                             │
├─────────────────────────────────────────────────────────┤
│ Type: 8 (Echo Request)     Code: 0                      │
│ Identifier: 12345          Sequence: 1                  │
│ Payload (56 bytes):                                     │
│ 61 62 63 64 65 66 67 68  69 6a 6b 6c 6d 6e 6f 70        │
│ 71 72 73 74 75 76 77 61  62 63 64 65 66 67 68 69  ...   │
└─────────────────────────────────────────────────────────┘

[2025-01-15 14:23:45] IPv4 Packet captured (84 bytes)
[ICMP Echo Reply from 10.0.0.1 to 10.0.0.2]

You’re seeing exactly what Wireshark sees, but you built the tool yourself. You can verify this by running sudo tcpdump -i tun0 alongside your program—the packets will match perfectly.

Learning milestones:

Successfully create a TUN device that shows up in ip link show - you understand how virtual interfaces are born
Route traffic through your TUN and see raw packets - you understand the packet capture path
Parse and display IP/ICMP/TCP/UDP headers correctly - you understand packet structure deeply
Handle fragmented packets (send ping -s 2000) - you understand why VPNs care about MTU

The Core Question You’re Answering

“How does a VPN intercept packets before they reach the network?”

Answer: By creating a virtual network interface (TUN device) that the kernel treats as a real network card. When you add routes pointing to this interface, the kernel sends packets to your userspace program instead of the physical network. You’re essentially becoming a man-in-the-middle for your own traffic.

Concepts You Must Understand First

Concept	Why It Matters	Where to Learn
File descriptors	TUN device is just a file descriptor you read/write	“The Linux Programming Interface” Ch. 4-5
ioctl() system call	Used to configure TUN device properties	“Advanced Programming in the UNIX Environment” Ch. 17
IP packet structure	You need to parse headers to understand what you captured	“TCP/IP Illustrated, Volume 1” Ch. 3-4
Network byte order	IP headers use big-endian; x86 uses little-endian	“The Sockets Networking API” Ch. 3
Routing tables	How to make traffic flow through your TUN device	“Computer Networks” by Tanenbaum Ch. 5

Questions to Guide Your Design

Before you start coding, think about these:

What happens if you read from the TUN device but no packets are arriving?
- Will your program block forever? Should it?
- Hint: Think about read() behavior on file descriptors
How do you know if a packet is IPv4 or IPv6?
- Hint: First byte of IP header encodes version
What should you do with packets you can’t parse (malformed, unknown protocol)?
- Drop silently? Log error? Forward anyway?
How do you test your program without disrupting your actual network?
- Hint: Network namespaces (ip netns) or VMs

Thinking Exercise (Do This Before Coding!)

Mental model exercise: Draw the packet flow when you run ping 10.0.0.2 on a system with your TUN logger running.

Your drawing should include:
Application (ping) creating ICMP packet
Kernel routing decision (which interface?)
Packet written to tun0 by kernel
Your program reading from /dev/net/tun
Your program parsing and displaying headers
What happens next? (ping expects a reply!)

If you can sketch this flow, you’re ready to code. If not, re-read the TUN/TAP section in Kerrisk.

The Interview Questions They’ll Ask

After completing this project, you should be able to answer:

“Explain how a VPN works at the kernel level.”
- Good answer: “A VPN creates a TUN/TAP virtual interface. The kernel routes packets to this interface based on routing table entries. A userspace program reads from the TUN device, encrypts the packet, and sends it over the network to the VPN server…”
“Why do VPNs use TUN instead of TAP?”
- TUN = layer 3 (IP packets), TAP = layer 2 (Ethernet frames)
- VPNs usually only care about IP routing, not Ethernet broadcasts
“How would you debug a VPN that’s dropping packets?”
- Check TUN device existence (ip link show)
- Check routes (ip route)
- Capture packets (tcpdump -i tun0)
- Check application logs for read/write errors
“What’s the difference between read() and recv() when reading from a TUN device?”
- TUN device uses read() (it’s a character device, not a socket)
“Why might a VPN reduce your MTU?”
- Encapsulation adds overhead (outer IP+UDP headers)
- If original packet is 1500 bytes (Ethernet MTU) + VPN overhead, it exceeds MTU and must be fragmented
“How does the kernel know to send packets to your TUN device instead of eth0?”
- Routing table! Most specific route wins. If you add 10.0.0.0/24 dev tun0, packets to 10.0.0.x go to TUN.

Hints in Layers (Progressive Help)

Hint 1 (High-level approach):

Open /dev/net/tun with open()
Use ioctl(fd, TUNSETIFF, ...) to create a TUN interface
Configure IP address with ip addr add ... or programmatically
Add route with ip route add ... or programmatically
Loop: read() from TUN fd → parse IP header → print details

Hint 2 (Key struct you need):

struct ifreq {
    char ifr_name[IFNAMSIZ];  // e.g., "tun0"
    short ifr_flags;          // IFF_TUN | IFF_NO_PI
};

Hint 3 (Opening TUN device):

int tun_fd = open("/dev/net/tun", O_RDWR);
struct ifreq ifr = {0};
ifr.ifr_flags = IFF_TUN | IFF_NO_PI;  // TUN mode, no packet info
strncpy(ifr.ifr_name, "tun%d", IFNAMSIZ);  // kernel picks number
ioctl(tun_fd, TUNSETIFF, &ifr);
// Now ifr.ifr_name contains actual device name (e.g., "tun0")

Hint 4 (Parsing IP header):

struct iphdr *ip = (struct iphdr *)packet_buffer;
printf("Version: %d\n", ip->version);  // Should be 4 for IPv4
printf("Protocol: %d\n", ip->protocol); // 1=ICMP, 6=TCP, 17=UDP
printf("Src: %s\n", inet_ntoa(*(struct in_addr *)&ip->saddr));
printf("Dst: %s\n", inet_ntoa(*(struct in_addr *)&ip->daddr));

Books That Will Help

Book	Chapters	What You’ll Learn
The Linux Programming Interface (Kerrisk)	Ch. 64 (Virtual Network Interfaces), Ch. 4-5 (File I/O)	How to create TUN devices, file descriptor operations
TCP/IP Illustrated, Volume 1 (Stevens)	Ch. 3 (IP), Ch. 6 (ICMP), Ch. 10 (UDP), Ch. 17 (TCP)	Packet header structures, protocol numbers
Advanced Programming in the UNIX Environment	Ch. 17 (ioctl), Ch. 14 (Advanced I/O)	System calls for device control
Understanding Linux Network Internals (Benvenuti)	Ch. 10 (Virtual Devices)	Kernel-side view of TUN/TAP

Common Pitfalls & Debugging

Problem 1: “open("/dev/net/tun") fails with Permission denied”

Why: TUN device requires root privileges
Fix: Run with sudo, or use capabilities: sudo setcap cap_net_admin+ep ./tun_logger
Quick test: ls -l /dev/net/tun should show crw-rw-rw- permissions

Problem 2: “TUN device created but no packets arriving”

Why: No routes pointing to your TUN device
Fix: Add route: sudo ip route add 10.0.0.0/24 dev tun0
Quick test: ip route show | grep tun0 should show your route

Problem 3: “Program hangs on read() and never returns”

Why: read() blocks when no packets available
Fix: Either use select()/poll() to check for data, or send a packet (ping 10.0.0.2)
Quick test: In another terminal, ping 10.0.0.2 should unblock your read

Problem 4: “Parsing IP header gives garbage values”

Why: Network byte order (big-endian) vs host byte order (little-endian on x86)
Fix: Use ntohs() for 16-bit fields, ntohl() for 32-bit fields
Quick test: Print ip->version (should be 4). If it’s > 10, you have byte order issues

Problem 5: “ioctl(TUNSETIFF) returns -1”

Why: Either permissions issue or invalid flags
Fix: Check errno: perror("ioctl") will tell you why
Quick test: Run with sudo first to rule out permissions

Problem 6: “Kernel logs show ‘packet dropped’ messages”

Why: You read packets but never send replies (kernel thinks interface is broken)
Fix: This is expected for a logger! To fix, either:
- Ignore (this is just a logger, not a forwarder)
- Implement reply handling (Project 2 does this)
Quick test: dmesg | grep tun to see kernel messages

Project 2: Simple UDP Tunnel (Unencrypted)

File: VPN_WIREGUARD_TAILSCALE_LEARNING_PROJECTS.md
Programming Language: C
Coolness Level: Level 3: Genuinely Clever
Business Potential: 4. The “Open Core” Infrastructure
Difficulty: Level 3: Advanced
Knowledge Area: Networking / Tunneling
Software or Tool: UDP Tunneling
Main Book: “TCP/IP Illustrated, Volume 1” by W. Richard Stevens

What you’ll build: A point-to-point tunnel that takes packets from a TUN interface, wraps them in UDP, sends them to a peer, unwraps them, and injects them into the peer’s TUN. Basically a VPN without encryption.

Why it teaches VPNs: This IS a VPN (minus security). You’ll implement the exact packet flow that WireGuard uses: App → TUN → Encrypt → UDP → Network → UDP → Decrypt → TUN → App. You’re just skipping encrypt/decrypt for now.

Core challenges you’ll face:

Bidirectional packet forwarding (TUN ↔ UDP socket) using select() or poll()
Handling packet boundaries (UDP is message-oriented, unlike TCP)
Configuring both endpoints to route traffic through the tunnel
Dealing with MTU issues (encapsulation adds overhead)

Key Concepts:

UDP socket programming: “TCP/IP Sockets in C” by Donahoo & Calvert (Ch. 4) - Practical UDP client/server patterns
I/O multiplexing: “The Linux Programming Interface” by Kerrisk (Ch. 63) - select(), poll(), epoll()
Tunneling concepts: “TCP/IP Illustrated, Volume 2” by Wright & Stevens (Ch. 19)
MTU and fragmentation: “Computer Networks” by Tanenbaum & Wetherall (Ch. 5.5)

Difficulty: Intermediate Time estimate: 1-2 weeks Prerequisites: Project 1 completed, understanding of UDP

Real world outcome:

Run tunnel server on Machine A, tunnel client on Machine B
ping 10.0.0.1 from Machine B reaches Machine A through your tunnel
SSH through the tunnel: ssh user@10.0.0.1 works
Watch Wireshark show your encapsulated UDP packets crossing the network

Learning milestones:

Packets flow one direction (A→B) - you understand encapsulation
Bidirectional flow works - you understand full-duplex tunneling
You can SSH through the tunnel - you’ve built a functional (insecure) VPN
You handle MTU properly - you understand why VPNs reduce MTU

The Core Question You’re Answering

“How do packets travel between two machines when there’s no direct network connection between them?”

Answer: By creating a virtual connection through encapsulation. Your program reads packets from the TUN device (which the kernel thinks is a local network), wraps them in UDP packets, and sends them through the actual network to the peer. The peer unwraps them and injects them into its TUN device. This creates the illusion of a direct connection when there isn’t one.

Concepts You Must Understand First

Stop and research these before coding:

UDP Socket Programming
- How does sendto() differ from TCP’s send()?
- What happens if you send a UDP packet larger than the network MTU?
- Why does UDP preserve message boundaries (unlike TCP)?
- Book Reference: “TCP/IP Sockets in C” by Donahoo & Calvert - Ch. 4
I/O Multiplexing (select/poll)
- How can one thread monitor both the TUN device AND the UDP socket simultaneously?
- What does select() do when both file descriptors have data ready?
- Why can’t you just use blocking read() on both?
- Book Reference: “The Linux Programming Interface” by Kerrisk - Ch. 63
Packet Encapsulation
- What’s the difference between “inner” and “outer” IP headers?
- How much overhead does UDP encapsulation add?
- Why does this create MTU issues?
- Book Reference: “Computer Networks” by Tanenbaum - Ch. 5.7
Bidirectional Communication
- How does the server know which peer sent a packet (when using UDP)?
- What happens if both peers send simultaneously?
- Book Reference: “The Sockets Networking API” by Stevens - Ch. 8

Questions to Guide Your Design

Before implementing, think through these:

Event Loop Design
- Your program needs to handle two types of events: “packet from TUN” and “packet from UDP socket”. How will you structure your main loop?
- Will you use select(), poll(), or epoll()?
- What happens if packets arrive faster than you can process them?
Packet Routing
- When you read a packet from TUN, how do you know where to send it via UDP? (Hint: you configured the peer’s endpoint when starting)
- When you receive a UDP packet, how do you verify it’s from your legitimate peer?
Error Handling
- What if the UDP socket reports “Network unreachable”?
- What if the TUN device read fails?
- Should the program crash or try to recover?
MTU Considerations
- Ethernet MTU is typically 1500 bytes. Your tunnel adds an outer IP header (20 bytes) + UDP header (8 bytes). What’s your effective MTU now?
- Should you fragment large packets or adjust the TUN device MTU?

Thinking Exercise

Trace the packet flow: Before coding, trace what happens when Machine A pings Machine B through your tunnel.

Machine A (10.0.0.1)          Your Tunnel          Machine B (10.0.0.2)
┌─────────────────┐                               ┌─────────────────┐
│  ping 10.0.0.2  │                               │                 │
└────────┬────────┘                               └─────────────────┘
         │
         ▼
Step 1: Kernel creates ICMP Echo Request
        Src: 10.0.0.1, Dst: 10.0.0.2

Step 2: Kernel checks routing table
        "10.0.0.0/24 dev tun0" → send to tun0

Step 3: Kernel writes packet to tun0
        (Your program reads it via read(tun_fd))

Step 4: Your program encapsulates packet
        Outer: Src=A's public IP, Dst=B's public IP
        Inner: [Original ICMP packet]

Step 5: Send via UDP socket to B

Step 6: B's program receives UDP packet
        (via recvfrom(udp_fd))

Step 7: B's program extracts inner packet
        (decapsulation)

Step 8: B's program writes to its tun0
        (via write(tun_fd))

Step 9: B's kernel receives packet on tun0
        Dst=10.0.0.2 → "That's me!"

Step 10: B's kernel processes ICMP Echo Request
         Creates ICMP Echo Reply

Step 11: Reply follows same path in reverse
         (B's tun0 → B's program → UDP → A's program → A's tun0)

Step 12: A's kernel receives reply
         ping displays "Reply from 10.0.0.2"

Question: At which step does the packet cross the actual internet? (Answer: Step 5)

The Interview Questions They’ll Ask

After completing this project, you should be able to answer:

“Why do VPNs typically use UDP instead of TCP?”
- Good answer: “TCP-over-TCP creates a ‘double retransmission’ problem. If the outer TCP connection loses a packet, it retransmits. But the inner TCP also detects the loss and retransmits independently. This creates competing retransmission algorithms that can severely degrade performance. UDP tunneling avoids this by letting only the inner TCP handle retransmissions.”
“How would you handle multiple concurrent VPN connections to different peers?”
- You’d need to track peer endpoints (IP:port mappings) and route incoming UDP packets to the correct TUN interface based on source address.
“What’s the maximum throughput you’d expect from your tunnel vs a direct connection?”
- Lower, due to encapsulation overhead (~28 bytes per packet) and extra processing (read from TUN, encapsulate, send via UDP). Real-world: 70-90% of direct connection speed.
“How does MTU affect VPN performance?”
- If MTU isn’t adjusted, large packets get fragmented. IP fragmentation is handled by routers, which is slow and unreliable (fragments can arrive out of order or be dropped). Better to set TUN MTU to (Ethernet MTU - encapsulation overhead).
“What happens if your tunnel program crashes while traffic is flowing?”
- Packets get blackholed. The routing table still sends packets to tun0, but no program is reading them. Applications see timeouts.
“How would you debug ‘packets sent but peer not receiving’?”
- Steps: (1) Check tcpdump -i eth0 udp port 51820 on sender - are packets leaving? (2) Check firewall rules on both sides, (3) Check UDP packets arrive at receiver with tcpdump, (4) Check receiver is reading from UDP socket, (5) Verify IPs/ports match configuration.

Hints in Layers

Hint 1: High-Level Architecture

You need three file descriptors:

TUN device FD (from Project 1)
UDP socket FD (created with socket(AF_INET, SOCK_DGRAM, 0))
Use select() to wait for data on EITHER FD

Main loop:

while (true) {
    select(max_fd, &read_fds, ...);
    if (FD_ISSET(tun_fd, &read_fds)) {
        // Packet from TUN → encapsulate → send via UDP
    }
    if (FD_ISSET(udp_fd, &read_fds)) {
        // Packet from UDP → decapsulate → write to TUN
    }
}

Hint 2: Creating the UDP Socket

int udp_fd = socket(AF_INET, SOCK_DGRAM, 0);

struct sockaddr_in local_addr = {
    .sin_family = AF_INET,
    .sin_port = htons(51820),  // WireGuard's default port
    .sin_addr.s_addr = INADDR_ANY
};
bind(udp_fd, (struct sockaddr*)&local_addr, sizeof(local_addr));

// Peer's address (configured manually for now)
struct sockaddr_in peer_addr = {
    .sin_family = AF_INET,
    .sin_port = htons(51820),
    .sin_addr.s_addr = inet_addr("peer.public.ip")
};

Hint 3: Forwarding TUN → UDP

char buffer[2048];
int len = read(tun_fd, buffer, sizeof(buffer));
if (len > 0) {
    // buffer now contains the inner IP packet
    // Send it as UDP payload to peer
    sendto(udp_fd, buffer, len, 0,
           (struct sockaddr*)&peer_addr, sizeof(peer_addr));
}

Hint 4: Forwarding UDP → TUN

char buffer[2048];
struct sockaddr_in from_addr;
socklen_t from_len = sizeof(from_addr);

int len = recvfrom(udp_fd, buffer, sizeof(buffer), 0,
                   (struct sockaddr*)&from_addr, &from_len);
if (len > 0) {
    // Verify packet is from known peer (security!)
    if (from_addr.sin_addr.s_addr == peer_addr.sin_addr.s_addr) {
        // buffer contains the inner IP packet
        write(tun_fd, buffer, len);
    }
}

Hint 5: Using select() for Event Loop

fd_set read_fds;
int max_fd = (tun_fd > udp_fd) ? tun_fd : udp_fd;

while (1) {
    FD_ZERO(&read_fds);
    FD_SET(tun_fd, &read_fds);
    FD_SET(udp_fd, &read_fds);

    select(max_fd + 1, &read_fds, NULL, NULL, NULL);

    if (FD_ISSET(tun_fd, &read_fds)) {
        // Handle TUN → UDP
    }
    if (FD_ISSET(udp_fd, &read_fds)) {
        // Handle UDP → TUN
    }
}

Books That Will Help

Topic	Book	Chapter
UDP socket programming	“TCP/IP Sockets in C” by Donahoo & Calvert	Ch. 4 - UDP Sockets
I/O multiplexing (select/poll)	“The Linux Programming Interface” by Kerrisk	Ch. 63 - I/O Multiplexing
Advanced socket options	“The Sockets Networking API” by Stevens	Ch. 8 - UDP, Ch. 6 - I/O Multiplexing
Encapsulation and tunneling	“Computer Networks” by Tanenbaum	Ch. 5.7 - Tunneling
MTU and fragmentation	“TCP/IP Illustrated, Vol 1” by Stevens	Ch. 11 - UDP and Fragmentation

Common Pitfalls & Debugging

Problem 1: “select() returns but read() blocks forever”

Why: select() said data was ready, but between the select() call and read(), the data was consumed or the FD changed state
Fix: Either use non-blocking I/O (fcntl(fd, F_SETFL, O_NONBLOCK)), or this shouldn’t happen with TUN/UDP in practice
Quick test: Check if you’re accidentally calling select() on the wrong FD

Problem 2: “Packets sent from A but never arrive at B”

Why: Firewall, incorrect peer IP, or peer program not running
Fix: On A, run sudo tcpdump -i eth0 -n udp port 51820 - do you see outgoing packets? On B, same command - do packets arrive?
Quick test: nc -u peer_ip 51820 and send test data to verify UDP connectivity

Problem 3: “One direction works (A→B) but not reverse (B→A)”

Why: Likely routing issue. B’s kernel might not have a route back to A’s tunnel network
Fix: Check ip route on B. You need routes on BOTH sides pointing to the tunnel network
Quick test: On B: ip route add 10.0.0.0/24 dev tun0

Problem 4: “Large pings fail (ping -s 2000) but small pings work”

Why: MTU mismatch. Your tunnel can’t handle packets > ~1472 bytes without fragmentation
Fix: Set TUN MTU: ip link set tun0 mtu 1400
Quick test: ping -M do -s 1400 10.0.0.2 (forces “don’t fragment”) should work

Problem 5: “sendto() returns -1 with EMSGSIZE”

Why: You’re trying to send a UDP packet larger than the network allows
Fix: Either fragment at IP layer (complex) or reduce TUN MTU so kernel never generates huge packets
Quick test: Check packet size: if len > 1472, you’ll hit this

Problem 6: “Program works for a while then stops forwarding packets”

Why: Buffer overflow, memory corruption, or file descriptor leak
Fix: Run with Valgrind: valgrind --leak-check=full ./tunnel
Quick test: Add logging before/after every read/write to see where it hangs

Problem 7: “Received packet from unknown peer - security concern”

Why: Your UDP socket is listening on all interfaces, anyone can send you packets

Fix: Verify sender in recvfrom():

if (from_addr.sin_addr.s_addr != expected_peer_addr.sin_addr.s_addr) {
  printf("Ignoring packet from unknown peer\n");
  continue;
}

Quick test: Send spoofed UDP packet with nc -u your_ip 51820, verify it’s rejected

Project 3: Add Encryption (ChaCha20-Poly1305)

File: VPN_WIREGUARD_TAILSCALE_LEARNING_PROJECTS.md
Programming Language: C
Coolness Level: Level 4: Hardcore Tech Flex
Business Potential: 1. The “Resume Gold”
Difficulty: Level 4: Expert
Knowledge Area: Cryptography / Network Security
Software or Tool: ChaCha20-Poly1305 / Libsodium
Main Book: “Serious Cryptography” by Jean-Philippe Aumasson

What you’ll build: Extend your UDP tunnel to encrypt all packets using ChaCha20-Poly1305 (the same cipher WireGuard uses) with a pre-shared key.

Why it teaches VPNs: This transforms your toy tunnel into something resembling a real VPN. You’ll understand why WireGuard chose ChaCha20 (fast in software, constant-time, no side channels) and how authenticated encryption prevents tampering.

Core challenges you’ll face:

Integrating a crypto library (libsodium or OpenSSL)
Managing nonces correctly (NEVER reuse a nonce!)
Handling authentication tag verification
Secure key storage and memory handling (sodium_memzero)

Resources for key challenges:

“Serious Cryptography, 2nd Edition” by Aumasson (Ch. 8-9) - Best explanation of ChaCha20-Poly1305 and AEAD
libsodium documentation (doc.libsodium.org) - Practical crypto implementation

Key Concepts:

AEAD (Authenticated Encryption): “Serious Cryptography” by Aumasson (Ch. 8) - Why encryption without authentication is dangerous
ChaCha20 stream cipher: “Serious Cryptography” by Aumasson (Ch. 5)
Nonce management: Salsa20/ChaCha20 design paper by DJB - Why nonce reuse is catastrophic
Constant-time operations: “Practical Cryptographic Systems” - Preventing timing attacks

Difficulty: Intermediate-Advanced Time estimate: 1-2 weeks Prerequisites: Projects 1-2, basic understanding of symmetric encryption

Real world outcome:

Capture traffic with Wireshark - see only encrypted gibberish
Modify a byte in transit - watch authentication fail and packet get dropped
Compare performance: your tunnel vs unencrypted vs OpenVPN
Verify with tcpdump that no plaintext leaks

Learning milestones:

Encrypt and decrypt a single packet correctly - you understand AEAD basics
Nonce handling works (no reuse, proper increment) - you understand crypto hygiene
Authentication failures are caught - you understand why AEAD matters
No plaintext visible in packet captures - you’ve built real encryption

The Core Question You’re Answering

“What does it actually mean for a VPN to be ‘secure’, and why isn’t encryption alone sufficient?”

Answer: Security requires both confidentiality (encryption prevents eavesdropping) AND authenticity (authentication prevents tampering). Encrypting a packet but not authenticating it means an attacker can flip bits in the ciphertext, corrupting your data without you knowing. AEAD (Authenticated Encryption with Associated Data) provides both properties in a single operation: ChaCha20 encrypts, Poly1305 creates an authentication tag. If anyone modifies the ciphertext, tag verification fails and you reject the packet.

Concepts You Must Understand First

Stop and research these before coding:

Symmetric vs Asymmetric Encryption
- Why can’t we use RSA or ECC to encrypt every packet?
- Why do we need a shared key that both sides know?
- How fast is ChaCha20 compared to public-key crypto?
- Book Reference: “Serious Cryptography” by Aumasson - Ch. 4 (Symmetric), Ch. 10 (Asymmetric)
Stream Ciphers (ChaCha20)
- How does ChaCha20 generate a keystream from a key + nonce?
- Why is reusing a nonce catastrophic?
- What makes ChaCha20 “constant-time” (immune to timing attacks)?
- Book Reference: “Serious Cryptography” by Aumasson - Ch. 5
Message Authentication Codes (Poly1305)
- What’s a MAC and how does it differ from a hash?
- Why can’t you just use SHA-256 to authenticate?
- How does Poly1305 ensure tampering is detected?
- Book Reference: “Serious Cryptography” by Aumasson - Ch. 7
AEAD (Authenticated Encryption with Associated Data)
- What’s the “associated data” in AEAD?
- Why do we encrypt-then-MAC instead of MAC-then-encrypt?
- What happens if tag verification fails?
- Book Reference: “Serious Cryptography” by Aumasson - Ch. 8
Nonce Management
- What’s a nonce and why must it be unique per message?
- How long should nonces be?
- What counter size prevents wraparound?
- Book Reference: “Real-World Cryptography” by Wong - Ch. 6.4

Questions to Guide Your Design

Before implementing, think through these:

Key Management
- Where will the shared key come from? (For now, hardcode a 32-byte key - Project 4 fixes this)
- How will you securely pass the key to your program? (Command-line arg? File? Environment variable?)
- How will you ensure the key is wiped from memory when the program exits?
Nonce Handling
- Will you use a counter (0, 1, 2, …) or random nonces?
- If using a counter, what happens if your program crashes and restarts with the same key - how do you avoid reusing nonces?
- How will the receiver know which nonce was used for each packet?
Packet Structure
- Should you prepend the nonce to each encrypted packet, or send it separately?
- What’s the overhead? (ChaCha20-Poly1305: nonce=12 bytes, tag=16 bytes, so +28 bytes per packet)
- Can an attacker tell encrypted packets apart from random noise?
Error Handling
- What should happen when tag verification fails? (Drop packet? Log? Alert?)
- Should you stop the tunnel or keep running?
- How do you prevent replay attacks (same packet sent twice)?

Thinking Exercise

Before coding, answer this scenario:

Alice sends an encrypted packet to Bob. An attacker, Mallory, intercepts it and flips one bit in the ciphertext before forwarding it to Bob.

Original ciphertext: 0x6A 7F 3C ...
Mallory's modified:  0x6B 7F 3C ... (flipped bit 0)

Questions:

Can Bob decrypt the packet? (Yes, decryption will succeed)
Will Bob notice the tampering? (Only if you verify the Poly1305 tag!)
What will the decrypted plaintext look like? (Garbled - one bit flip cascades)
What should your code do? (Reject the packet immediately when crypto_aead_chacha20poly1305_ietf_decrypt() returns -1)

This is why AEAD matters: encryption without authentication is vulnerable to tampering.

The Interview Questions They’ll Ask

After completing this project, you should be able to answer:

“Why does WireGuard use ChaCha20-Poly1305 instead of AES-GCM?”
- Good answer: “ChaCha20-Poly1305 is fast in software without requiring AES-NI hardware acceleration. It’s also constant-time, preventing timing side-channel attacks. AES-GCM is faster on CPUs with AES-NI, but on ARM, mobile, and embedded devices, ChaCha20 wins. WireGuard prioritizes universal performance and security.”
“What happens if you accidentally reuse a nonce with the same key?”
- Catastrophic! An attacker who sees two ciphertexts encrypted with the same key+nonce can XOR them together, canceling out the keystream and revealing the XOR of the two plaintexts. This often leaks enough information to recover both messages.
“How would you detect and prevent replay attacks?”
- Maintain a sliding window of seen nonces (or packet counters). If a packet arrives with a nonce you’ve already processed, drop it. WireGuard uses a bitmap to track recently seen counters.
“What’s the difference between ChaCha20-Poly1305 and ChaCha20-Poly1305-IETF?”
- IETF version uses a 96-bit (12-byte) nonce vs original’s 64-bit (8-byte). Longer nonce reduces collision risk when using random nonces. WireGuard uses the IETF variant.
“Why can’t you just encrypt the packet without the authentication tag to save bandwidth?”
- Because attackers could flip bits in transit, causing decryption to produce garbage that your application might process (leading to crashes, vulnerabilities). AEAD detects tampering and lets you reject bad packets before they cause harm.
“How does ChaCha20-Poly1305 handle associated data (the ‘AD’ in AEAD)?”
- Associated data is authenticated but not encrypted (e.g., packet headers you want visible but tamper-proof). Poly1305 includes it in the MAC. If AD or ciphertext is modified, verification fails.

Hints in Layers

Hint 1: Installing libsodium

ChaCha20-Poly1305 is complex to implement correctly. Use libsodium (NaCl’s successor):

# Ubuntu/Debian
sudo apt install libsodium-dev

# Compile your program
gcc -o tunnel tunnel.c -lsodium

Hint 2: Key Generation (For Testing)

#include <sodium.h>

// Initialize libsodium (call once at program start)
if (sodium_init() < 0) {
    // panic! library couldn't initialize
}

// Generate a random key (for testing; Project 4 derives it properly)
unsigned char key[crypto_aead_chacha20poly1305_IETF_KEYBYTES];  // 32 bytes
crypto_aead_chacha20poly1305_ietf_keygen(key);

// In production, share this key with peer securely
// For now, hardcode the same key on both sides for testing

Hint 3: Encrypting a Packet

unsigned char nonce[crypto_aead_chacha20poly1305_IETF_NPUBBYTES];  // 12 bytes
unsigned char ciphertext[2048];
unsigned long long ciphertext_len;

// Nonce must be unique for each packet (use a counter)
static uint64_t packet_counter = 0;
memset(nonce, 0, sizeof(nonce));
memcpy(nonce, &packet_counter, sizeof(packet_counter));
packet_counter++;

// Encrypt: plaintext → ciphertext + tag
crypto_aead_chacha20poly1305_ietf_encrypt(
    ciphertext, &ciphertext_len,      // output
    plaintext, plaintext_len,          // input
    NULL, 0,                           // associated data (none for now)
    NULL,                              // secret nonce (deprecated, use NULL)
    nonce,                             // public nonce
    key                                // shared key
);

// ciphertext_len = plaintext_len + 16 (for Poly1305 tag)
// Now send: nonce (12 bytes) + ciphertext (plaintext_len + 16)

Hint 4: Decrypting a Packet

unsigned char plaintext[2048];
unsigned long long plaintext_len;

// Extract nonce from received packet (first 12 bytes)
unsigned char nonce[crypto_aead_chacha20poly1305_IETF_NPUBBYTES];
memcpy(nonce, received_packet, sizeof(nonce));

// Decrypt: ciphertext + tag → plaintext
int result = crypto_aead_chacha20poly1305_ietf_decrypt(
    plaintext, &plaintext_len,                         // output
    NULL,                                              // not used
    received_packet + sizeof(nonce),                   // ciphertext
    received_len - sizeof(nonce),                      // ciphertext len
    NULL, 0,                                           // associated data
    nonce,                                             // nonce
    key                                                // shared key
);

if (result != 0) {
    // Decryption failed - packet was tampered with!
    printf("Authentication failed! Dropping packet.\n");
    return;
}

// plaintext_len = ciphertext_len - 16 (tag removed)
// Safe to use plaintext now

Hint 5: Packet Structure

Encrypted Packet Format:
┌─────────────┬──────────────────┬────────────────┐
│ Nonce       │ Encrypted Data   │ Poly1305 Tag   │
│ (12 bytes)  │ (variable)       │ (16 bytes)     │
└─────────────┴──────────────────┴────────────────┘
     ↑              ↑                    ↑
  Sent in      Original packet    Automatically
   clear       encrypted          added by libsodium

Modify your Project 2 code:

Before sendto(): Encrypt packet, prepend nonce
After recvfrom(): Extract nonce, decrypt, verify tag

Hint 6: Secure Memory Handling

// Wipe sensitive data before freeing
sodium_memzero(key, sizeof(key));

// Lock memory to prevent swapping to disk (advanced)
sodium_mlock(key, sizeof(key));
// ... use key ...
sodium_munlock(key, sizeof(key));

Books That Will Help

Topic	Book	Chapter
ChaCha20 stream cipher	“Serious Cryptography” by Aumasson	Ch. 5 - Stream Ciphers
Poly1305 MAC	“Serious Cryptography” by Aumasson	Ch. 7 - MACs
AEAD construction	“Serious Cryptography” by Aumasson	Ch. 8 - AEAD
Nonce management	“Real-World Cryptography” by Wong	Ch. 6 - Symmetric Encryption
Libsodium API guide	Official documentation	doc.libsodium.org
Timing attacks	“Serious Cryptography” by Aumasson	Ch. 15 - Side Channels

Common Pitfalls & Debugging

Problem 1: “Decryption fails with ‘authentication failed’ on every packet”

Why: Likely key mismatch - sender and receiver don’t have the same key
Fix: Print the key (in hex) on both sides, verify they match exactly

Quick test:

for (int i = 0; i < 32; i++) printf("%02x", key[i]);
printf("\n");

Problem 2: “Program works for 256 packets then all decryption fails”

Why: Nonce counter overflow. If you use uint8_t, it wraps after 255
Fix: Use uint64_t for counter (good for 2^64 packets = never wraps in practice)
Quick test: Log the nonce value before each encrypt/decrypt

Problem 3: “sodium_init() returns -1”

Why: Libsodium can’t initialize (rare - usually memory or random number generator issue)
Fix: Check system has /dev/urandom, ensure libsodium is installed correctly
Quick test: Run ldconfig -p | grep sodium to verify library is found

Problem 4: “Encrypted packets are visible in Wireshark as readable text”

Why: You forgot to actually encrypt, or you’re encrypting but sending plaintext by mistake
Fix: Check your code flow - ensure encrypted buffer (not original) is sent via UDP
Quick test: Print first 20 bytes of buffer before sendto() - should look like random bytes

Problem 5: “Nonce reuse - packets decrypt as garbage after program restart”

Why: Counter resets to 0 on restart, reusing nonces with the same key
Fix: Generate a new key on each program start, OR persist counter to disk, OR use timestamp as nonce

Quick test: Add random offset to counter on startup:

packet_counter = (uint64_t)time(NULL) << 32;  // unique per-second

Problem 6: “Segfault in crypto_aead_chacha20poly1305_ietf_decrypt()“

Why: Buffer too small for decrypted output, or forgot to call sodium_init()
Fix: Ensure output buffer is at least ciphertext_len - 16 bytes. Call sodium_init() at start.

Quick test: Add bounds checking:

if (received_len < crypto_aead_chacha20poly1305_IETF_NPUBBYTES +
                 crypto_aead_chacha20poly1305_IETF_ABYTES) {
  printf("Packet too small\n");
  return;
}

Problem 7: “How do I securely generate/share the key between peers?”

Why: This is THE hard problem - Project 4 solves it with key exchange
Fix: For now, generate key once, copy it to both machines manually (via USB stick, SSH, etc.)
Production: NEVER hardcode keys in code or send them unencrypted over network

Problem 8: “Performance dropped significantly after adding encryption”

Why: Crypto has overhead. ChaCha20-Poly1305 is fast but not free.
Fix: This is expected. On modern hardware, ~5-15% slowdown is normal
Quick test: Benchmark with iperf3 through tunnel before/after encryption

Project 4: Key Exchange (Noise Protocol IK)

File: VPN_WIREGUARD_TAILSCALE_LEARNING_PROJECTS.md
Programming Language: C
Coolness Level: Level 5: Pure Magic (Super Cool)
Business Potential: 5. The “Industry Disruptor”
Difficulty: Level 5: Master
Knowledge Area: Cryptography / Protocol Design
Software or Tool: Noise Protocol / WireGuard
Main Book: “Real-World Cryptography” by David Wong

What you’ll build: Replace your pre-shared key with a proper handshake using the Noise Protocol Framework (specifically the IK pattern that WireGuard uses), implementing Curve25519 key exchange.

Why it teaches VPNs: This is the heart of WireGuard’s security model. You’ll understand:

Why static + ephemeral keys provide both authentication AND forward secrecy
How two parties derive the same shared secret without transmitting it
Why WireGuard’s handshake is so much simpler than IKE/IPsec

Core challenges you’ll face:

Implementing Curve25519 scalar multiplication (or using libsodium)
Following the Noise protocol state machine precisely
Deriving symmetric keys from DH outputs using HKDF
Handling identity hiding (encrypted static keys)

Resources for key challenges:

Noise Protocol Framework specification (noiseprotocol.org) - The definitive reference
WireGuard whitepaper by Jason Donenfeld - See how WireGuard uses Noise IK

Key Concepts:

Diffie-Hellman key exchange: “Serious Cryptography” by Aumasson (Ch. 11) - Foundation of all modern key exchange
Elliptic curve cryptography: “Serious Cryptography” by Aumasson (Ch. 12) - Why Curve25519 is fast and safe
Noise Protocol Framework: Official specification (noiseprotocol.org) - WireGuard’s handshake protocol
Key derivation (HKDF): RFC 5869 - Turning DH output into encryption keys

Difficulty: Advanced Time estimate: 2-3 weeks Prerequisites: Projects 1-3, understanding of public-key cryptography concepts

Real world outcome:

Two peers that have never communicated establish a secure tunnel
Capture the handshake - see only public keys and ciphertext
Each session uses different keys (forward secrecy)
Impersonation attempts fail immediately

Learning milestones:

Generate Curve25519 keypairs - you understand elliptic curve basics
Perform DH and derive matching symmetric keys on both sides - you understand key exchange
Full Noise IK handshake works - you understand WireGuard’s security model
Forward secrecy demonstrated (new keys each session) - you understand why this matters

The Core Question You’re Answering

“How can two parties who’ve never met establish a secure encrypted channel without transmitting the secret key?”

Answer: Through asymmetric key exchange. Each side has a public/private keypair. They exchange public keys openly (which are useless to attackers alone), then use elliptic curve Diffie-Hellman (ECDH) to compute a shared secret that only they know. The Noise Protocol adds identity authentication (verifying who you’re talking to) and forward secrecy (even if private keys leak later, past sessions stay secure).

Concepts You Must Understand First

Stop and research these before coding:

Diffie-Hellman Key Exchange
- How do two parties compute the same shared secret without transmitting it?
- What’s the discrete logarithm problem and why is it hard?
- Why is classical DH vulnerable to man-in-the-middle attacks?
- Book Reference: “Serious Cryptography” by Aumasson - Ch. 11
Elliptic Curve Cryptography (Curve25519)
- Why use elliptic curves instead of modular exponentiation?
- What makes Curve25519 special (speed, safety, simplicity)?
- What’s the difference between X25519 (key exchange) and Ed25519 (signatures)?
- Book Reference: “Serious Cryptography” by Aumasson - Ch. 12
Noise Protocol Framework
- What’s a “handshake pattern” (like IK, XX, KK)?
- Why does Noise use both static and ephemeral keys?
- How does Noise provide forward secrecy?
- Book Reference: Noise Protocol specification at noiseprotocol.org
Key Derivation (HKDF)
- Why can’t you use DH output directly as an encryption key?
- What does HKDF (HMAC-based KDF) do?
- How do you derive multiple keys from one shared secret?
- Book Reference: RFC 5869, “Serious Cryptography” Ch. 14

The Interview Questions They’ll Ask

“Explain Diffie-Hellman key exchange in simple terms.”
- Good answer: “Alice and Bob each have a private number (secret) and compute a public value. They exchange public values. Each combines their private number with the other’s public value, and through mathematical magic (discrete log problem), they end up with the same shared secret without ever transmitting it.”
“What’s the difference between static and ephemeral keys in Noise?”
- Static keys are long-term identity keys (like your SSH key). Ephemeral keys are generated fresh for each session and deleted afterward. Combining both provides authentication (static) and forward secrecy (ephemeral).
“What’s forward secrecy and why does WireGuard have it?”
- Even if an attacker records all your encrypted traffic and later steals your private keys, they can’t decrypt old sessions because those used ephemeral keys that were deleted.
“Why does WireGuard use the Noise IK pattern specifically?”
- IK = Initiator knows responder’s static key. This fits VPN use case: client knows server’s public key in advance (like SSH host keys). Provides 1-RTT handshake (fast connection).

Common Pitfalls & Debugging

Problem 1: “DH computation gives different shared secrets on each side”

Why: Likely byte order issue or using wrong keys
Fix: Ensure you’re computing initiator_ephemeral * responder_static on initiator side and responder_static_private * initiator_ephemeral on responder
Quick test: Print shared secrets in hex on both sides, they must match exactly

Problem 2: “Noise handshake fails with ‘bad MAC’“

Why: Handshake state machine out of sync or wrong keys mixed in
Fix: Follow Noise IK pattern EXACTLY - the order of DH operations matters
Quick test: Add logging for each handshake step to see where it diverges

Problem 3: “How do I get the responder’s static public key to the initiator securely?”

Why: This is the “trust on first use” problem
Fix: Exchange keys out-of-band (QR code, secure email, etc.) or use key pinning
Quick test: For development, hardcode server public key in client

Project 5: NAT Traversal & Hole Punching

File: VPN_WIREGUARD_TAILSCALE_LEARNING_PROJECTS.md
Programming Language: C / Go
Coolness Level: Level 4: Hardcore Tech Flex
Business Potential: 4. The “Open Core” Infrastructure
Difficulty: Level 4: Expert
Knowledge Area: Networking / NAT
Software or Tool: STUN / TURN
Main Book: “Peer-to-Peer Communication Across NATs” by Ford et al.

What you’ll build: Extend your VPN to work when both peers are behind NAT (the common case). Implement UDP hole punching with a simple coordination server.

Why it teaches Tailscale/Twingate: This is the “magic” that makes Tailscale work. Most devices are behind NAT and can’t receive incoming connections. Hole punching lets peers connect directly without a relay. You’ll understand why Tailscale needs coordination servers.

Core challenges you’ll face:

Understanding NAT behavior types (Full Cone, Restricted, Symmetric)
Implementing a STUN-like server to discover external IP:port
Coordinating simultaneous hole punch attempts
Falling back to relay when direct connection fails

Resources for key challenges:

RFC 5389 (STUN) - How to discover your public address
“Peer-to-Peer Communication Across NATs” by Ford, Srisuresh, Kegel - The definitive hole-punching paper

Key Concepts:

NAT types and behavior: RFC 4787 - Understanding NAT classification
STUN protocol: RFC 5389 - Discovering external addresses
UDP hole punching: Ford et al. paper “Peer-to-Peer Communication Across NATs” - The technique itself
ICE framework: RFC 8445 - How real systems combine STUN/TURN

Difficulty: Advanced Time estimate: 2-3 weeks Prerequisites: Projects 1-4, understanding of NAT

Real world outcome:

Two peers behind different home NATs connect directly
Coordination server shows the exchange of endpoint information
Watch with Wireshark as hole-punch packets open the NAT mapping
See direct peer-to-peer traffic (not relayed through your server)

Learning milestones:

STUN server correctly reports external IP:port - you understand NAT mapping discovery
Hole punch succeeds between two symmetric NAT peers - you understand the timing/coordination
System detects when hole punch fails and could relay - you understand Tailscale’s “DERP” relays
Multiple peers can discover and connect - you understand mesh coordination

The Core Question You’re Answering

“How can two devices behind NATs (which block incoming connections) establish a direct peer-to-peer connection?”

Answer: Through UDP hole punching. When a device behind NAT sends a UDP packet out, the NAT creates a temporary mapping (internal IP:port ↔ external IP:port) and allows replies to that mapping. If both peers simultaneously send packets to each other’s external addresses, their NATs think the incoming packets are “replies” to outgoing ones, and let them through. A coordination server helps peers discover each other’s external addresses and synchronize the punch timing.

Concepts You Must Understand First

Stop and research these before coding:

NAT Types and Behavior
- What’s the difference between Full Cone, Restricted Cone, Port-Restricted, and Symmetric NAT?
- Which NAT types allow hole punching?
- Why does Symmetric NAT make P2P nearly impossible?
- Book Reference: RFC 4787 (NAT Behavioral Requirements for UDP)
STUN Protocol
- How does STUN discover your external IP:port?
- What’s the difference between STUN, TURN, and ICE?
- Why do you need multiple STUN servers?
- Book Reference: RFC 5389 (STUN)
UDP Hole Punching Mechanics
- Why must both peers send packets simultaneously?
- What timing windows must you hit?
- What percentage of NAT combinations work? (Research by Bryan Ford: ~82%)
- Book Reference: “Peer-to-Peer Communication Across NATs” (Ford et al.)
Relay/TURN Fallback
- When does hole punching fail?
- How does a TURN relay forward packets?
- What’s the latency/throughput penalty of relaying?
- Book Reference: RFC 5766 (TURN)

Questions to Guide Your Design

Before implementing, think through these:

Coordination Server Design
- What information must peers register with the server? (Internal IP, external IP:port, etc.)
- How does the server tell Peer A how to reach Peer B?
- What happens if a peer’s NAT mapping changes during the session?
Hole Punch Timing
- How do you ensure both peers send packets at the same time?
- Should they send multiple punch packets or just one?
- What timeout indicates failure?
NAT Type Detection
- Can you detect your NAT type automatically?
- Should you attempt hole punch with Symmetric NAT?
- How do you fail gracefully?
Production Considerations
- What percentage of users will need relay fallback?
- How much bandwidth does relay consume?
- Should you prefer IPv6 (no NAT!) when available?

Thinking Exercise

Trace the hole punching sequence:

Peer A (behind NAT A)           Coordination Server         Peer B (behind NAT B)
Internal: 192.168.1.5                                      Internal: 10.0.0.5
External: (unknown)                                        External: (unknown)

Step 1: A queries STUN server
        → Discovers external IP:port: 1.2.3.4:12345

Step 2: A registers with coordination server
        → "I'm A, reach me at 1.2.3.4:12345"

Step 3: B queries STUN server
        → Discovers external IP:port: 5.6.7.8:54321

Step 4: B registers with coordination server
        → "I'm B, reach me at 5.6.7.8:54321"

Step 5: A requests connection to B
        → Server tells A: "B is at 5.6.7.8:54321"
        → Server tells B: "A is at 1.2.3.4:12345"

Step 6: Both A and B simultaneously send punch packets
        A → 5.6.7.8:54321
        B → 1.2.3.4:12345

Step 7: NATs see outgoing packets, create mappings

Step 8: Packets arrive, NATs allow them through
        (thinking they're replies to Step 6)

Step 9: Direct P2P connection established!

Question: What happens if A sends before B? (Answer: A’s packet gets dropped, but B’s creates the mapping. A’s next packet succeeds!)

The Interview Questions They’ll Ask

“Why do ~18% of NAT combinations fail to hole punch?”
- Symmetric NATs assign different external ports for each destination. When A sends to the coordination server, it gets external port X. When A sends to B, NAT assigns port Y. But the coordination server told B to send to port X, so packets don’t match and are dropped.
“How does Tailscale’s DERP relay system work?”
- DERP (Detoured Encrypted Relay Protocol) is Tailscale’s fallback. If direct connection fails, peers connect to a DERP relay server, which forwards encrypted packets between them. It’s encrypted end-to-end, so relay can’t read content.
“What’s the latency difference between direct P2P vs relay?”
- Direct: ~10-50ms (depending on peer distance). Relay: +50-200ms (extra hop through relay server). For real-time apps (gaming, VoIP), this matters.
“How would you optimize hole punching success rate?”
- Use multiple STUN servers for discovery, try IPv6 (no NAT!), send multiple punch attempts with jitter, implement TURN relay fallback.
“What’s UPnP/NAT-PMP and why don’t production systems rely on it?”
- UPnP/NAT-PMP let you programmatically open NAT ports. But many routers disable it (security risk), and it’s unreliable. Hole punching works without router cooperation.

Hints in Layers

Hint 1: STUN Client (Discover External Address)

// Simplified STUN request
struct sockaddr_in stun_server = {
    .sin_family = AF_INET,
    .sin_port = htons(3478),  // STUN default port
    .sin_addr.s_addr = inet_addr("stun.l.google.com")  // Example STUN server
};

// Send STUN Binding Request
// Receive STUN Binding Response
// Parse response to extract your external IP:port

Use existing STUN libraries for production (libnice, pjnath).

Hint 2: Coordination Server (Simple HTTP/JSON API)

# Simple coordination server (Python Flask)
from flask import Flask, request, jsonify

app = Flask(__name__)
peers = {}  # peer_id -> {external_ip, external_port}

@app.route('/register', methods=['POST'])
def register():
    peer_id = request.json['id']
    peers[peer_id] = {
        'ip': request.json['external_ip'],
        'port': request.json['external_port']
    }
    return jsonify({'status': 'ok'})

@app.route('/query/<peer_id>', methods=['GET'])
def query(peer_id):
    return jsonify(peers.get(peer_id, {}))

Hint 3: Simultaneous Hole Punch

// On both peers (after coordination server exchange)
struct sockaddr_in peer_addr = {
    .sin_family = AF_INET,
    .sin_port = htons(peer_external_port),
    .sin_addr.s_addr = inet_addr(peer_external_ip)
};

// Send multiple punch packets (increases success probability)
for (int i = 0; i < 5; i++) {
    sendto(udp_fd, "PUNCH", 5, 0, (struct sockaddr*)&peer_addr, sizeof(peer_addr));
    usleep(100000);  // 100ms between attempts
}

// Now listen for incoming packets - one should get through!

Books That Will Help

Topic	Book	Chapter
NAT behavior types	RFC 4787	NAT Behavioral Requirements
STUN protocol	RFC 5389	Session Traversal Utilities for NAT
UDP hole punching	“Peer-to-Peer Communication Across NATs” by Ford et al.	Research paper - the definitive work
ICE framework	RFC 8445	Interactive Connectivity Establishment
TURN relay	RFC 5766	Traversal Using Relays around NAT

Common Pitfalls & Debugging

Problem 1: “STUN server says I’m behind Symmetric NAT - hole punching fails”

Why: Symmetric NAT assigns different ports per destination
Fix: Implement TURN relay fallback for these cases (~15-18% of users)
Quick test: Try from different network (coffee shop, mobile hotspot) - NAT type varies

Problem 2: “Hole punch works from home NAT but fails from corporate network”

Why: Corporate firewalls often block UDP entirely or use very strict NAT
Fix: Some networks are impossible to traverse - relay is the only option
Quick test: Check if basic UDP works: nc -u peer_ip peer_port

Problem 3: “Coordination server gives external IP, but hole punch packets never arrive”

Why: Timing issue - peers sending at different times, or firewall dropping packets
Fix: Add countdown synchronization: server tells both peers “punch in 3 seconds”
Quick test: Increase punch packet count and interval

Problem 4: “External IP:port discovered by STUN changes every few seconds”

Why: Your NAT is very strict about timeouts or you have multiple external IPs
Fix: Send keepalive packets to maintain NAT mapping
Quick test: Increase punch frequency or reduce idle time

Problem 5: “STUN client hangs waiting for response”

Why: STUN server unreachable, or response is being filtered
Fix: Use multiple STUN servers, add timeout to request
Quick test: nc -u stun.l.google.com 3478 - can you reach it at all?

Problem 6: “IPv4 hole punch fails but I have IPv6 - should I use it?”

Why: IPv6 has no NAT! Direct connections just work
Fix: Prefer IPv6 when both peers support it
Quick test: Check ip -6 addr show - do you have a global IPv6 address?

Problem 7: “Hole punch succeeds but then connection dies after 30-60 seconds”

Why: NAT mapping timeout - NAT closes the hole after idle period
Fix: Send keepalive packets every 15-20 seconds
Quick test: Use WireGuard’s PersistentKeepalive = 15 setting

Project Comparison Table

Project	Difficulty	Time	Depth of Understanding	Fun Factor
TUN Packet Logger	Intermediate	1-2 weeks	⭐⭐⭐ Foundation	⭐⭐⭐ Seeing raw packets is cool
UDP Tunnel	Intermediate	1-2 weeks	⭐⭐⭐⭐ Core VPN mechanics	⭐⭐⭐⭐ “I built a VPN!”
Add Encryption	Int-Advanced	1-2 weeks	⭐⭐⭐⭐ Crypto in practice	⭐⭐⭐ Satisfying security
Key Exchange	Advanced	2-3 weeks	⭐⭐⭐⭐⭐ Deep crypto	⭐⭐⭐ Complex but rewarding
NAT Traversal	Advanced	2-3 weeks	⭐⭐⭐⭐⭐ Tailscale magic	⭐⭐⭐⭐⭐ “It just works” moment

Recommendation

Based on interest in both low-level C implementation AND understanding services like Tailscale:

Start with Project 1 (TUN Packet Logger). This gives you the foundation everything else builds on. You can’t understand VPNs without understanding virtual network interfaces.

Then follow the progression:

Projects 1-3 give you a working encrypted VPN (like a minimal WireGuard)
Project 4 teaches you WireGuard’s actual security model
Project 5 reveals the Tailscale/Twingate secret sauce

If you’re particularly interested in Tailscale specifically, Project 5 is the payoff—but you need Projects 1-4 to appreciate what it’s doing.

Final Capstone Project: Mini-Tailscale

What you’ll build: A mesh VPN system where multiple peers can discover each other through a coordination server, establish direct encrypted connections via NAT traversal, and fall back to relay when direct connection fails. Essentially, a simplified Tailscale clone.

Why it teaches the full stack: This combines everything:

TUN interfaces (packet handling)
WireGuard-style encryption (ChaCha20-Poly1305)
Noise Protocol handshakes (authentication + key exchange)
NAT traversal (STUN + hole punching)
Coordination/control plane (peer discovery)
Relay fallback (TURN-style)

Core challenges you’ll face:

Designing a coordination protocol (peer registration, endpoint exchange)
Managing multiple simultaneous peer connections
Implementing connection state machines (handshaking, established, rekeying)
Building a relay server for when NAT traversal fails
Handling peer churn (joins, leaves, network changes)

Resources for key challenges:

Tailscale blog posts (tailscale.com/blog) - They explain their architecture openly
WireGuard whitepaper - The crypto/protocol foundation
“How NAT Traversal Works” by Tailscale - Their detailed explanation

Key Concepts:

Coordination plane design: Tailscale blog “How Tailscale Works”
Mesh networking: “Computer Networks” by Tanenbaum (overlay networks section)
DERP relay protocol: Tailscale’s DERP specification on GitHub
Connection state machines: WireGuard whitepaper (timer state machine)
Multi-peer management: “The Linux Programming Interface” by Kerrisk (Ch. 63 - epoll for many connections)

Difficulty: Advanced Time estimate: 1-2 months Prerequisites: All previous projects completed

Real world outcome:

Run coordination server on a public VPS
Install your VPN client on your laptop, phone, home server
All devices automatically discover each other and connect
ping laptop from phone works, routed through your mesh
Watch the mesh heal when a peer disconnects
See direct connections established (not relayed) in your logs

Learning milestones:

Two peers connect via coordination server - you understand control planes
Three+ peers form a full mesh - you understand peer management
NAT traversal works between home networks - you understand Tailscale’s core value
Relay fallback works when hole punch fails - you understand robustness
Peer can roam (change networks) and reconnect - you understand mobility

The Core Question You’re Answering

“How does Tailscale make it feel like all your devices are on the same local network, regardless of where they physically are?”

Answer: By combining everything you’ve learned: (1) TUN interfaces make the kernel think there’s a local network, (2) WireGuard-style encryption secures traffic, (3) Noise Protocol authenticates peers, (4) NAT traversal establishes direct connections, (5) a coordination server helps peers discover each other, and (6) relay servers provide fallback when direct connection fails. The result: a secure, resilient mesh where devices can reach each other by name/IP as if they were on the same LAN.

Concepts You Must Understand First

Stop and research these before coding:

Control Plane vs Data Plane
- What’s the difference between “coordinating” and “forwarding packets”?
- Why does Tailscale’s coordination server NOT see your traffic?
- What happens if coordination server goes down but peers are already connected?
- Book Reference: “Computer Networks” by Tanenbaum - Ch. 5 (Network Layer)
Mesh Network Topologies
- Full mesh vs partial mesh - which does Tailscale use?
- How many connections exist with N peers in full mesh? (N*(N-1)/2)
- What’s the scalability limit?
- Book Reference: “Computer Networks” by Tanenbaum - Ch. 4 (Network Layer)
Connection State Machines
- States: Disconnected → Discovering → Punching → Established → Rekeying
- When do you transition between states?
- How do you handle timeouts and failures?
- Book Reference: WireGuard whitepaper (Timer State Machine section)
Peer Churn
- What happens when a peer joins the mesh?
- What happens when a peer crashes (doesn’t gracefully leave)?
- How do you detect dead peers?
- Book Reference: Distributed systems literature (failure detection)

Questions to Guide Your Design

Before implementing, think through these:

Architecture Decisions
- Will you use a centralized coordination server or P2P discovery?
- How will peers authenticate to the coordination server?
- Will you support multiple coordination servers for redundancy?
State Management
- What state must each peer maintain? (List of peers, their endpoints, keys, connection status)
- Where is state stored? (In memory? Persisted to disk?)
- How do you handle state sync after crashes?
Rekeying
- How often should peers rekey? (WireGuard: every 2 minutes or 2^60 bytes)
- Can you rekey without dropping packets?
- What happens if rekey fails?
Scale
- How many peers can your mesh support? (Tailscale: 100s, tested to 1000s)
- What’s the bottleneck? (CPU for crypto? Bandwidth? Coordination server?)

Thinking Exercise

Design the peer registration protocol:

What information must a peer send when it joins the mesh?

Peer Join Message:
{
  "peer_id": "unique-id",
  "static_public_key": "base64...",
  "endpoints": [
    {"type": "ipv4", "ip": "1.2.3.4", "port": 51820},
    {"type": "ipv6", "ip": "2001:db8::1", "port": 51820}
  ],
  "internal_ip": "10.0.0.5",
  "os": "linux",
  "capabilities": ["hole_punch", "relay"]
}

Questions:

Should peers announce their internal IP or should the server assign it? (Tailscale assigns)
How do you prevent peer_id collisions? (Use public key hash as ID)
Should endpoints include STUN-discovered external address? (Yes!)
How often should peers refresh this information? (Every 30-60 seconds)

The Interview Questions They’ll Ask

“How does Tailscale achieve zero-trust security?”
- Every peer authenticates with public keys (like SSH). Coordination server doesn’t forward traffic (can’t MITM). End-to-end encryption means even compromised relay can’t read data.
“What’s the difference between Tailscale’s coordination server and a VPN gateway?”
- Coordination server only exchanges metadata (peer endpoints, keys). It never sees or forwards actual traffic. Traditional VPN gateway forwards ALL traffic (single point of failure and bottleneck).
“How would you implement ACLs (access control lists) in a mesh VPN?”
- Coordination server distributes ACL policies to peers. Each peer enforces rules locally: “Only allow peer A to connect to my port 22”. Drop packets that violate policy.
“What’s the worst-case latency scenario in Tailscale?”
- Symmetric NATs on both ends force relay. Packet goes: Client A → Relay (maybe on another continent) → Client B. Could be 200-500ms.
“How does Tailscale handle IP address assignment to avoid conflicts?”
- Uses a CGNAT range (100.64.0.0/10) that’s unlikely to conflict with local networks. Coordination server assigns IPs from this pool, ensuring uniqueness.

Hints in Layers

Hint 1: Coordination Server API

Define a simple REST API:

POST /peers/register - Register peer, get mesh info
GET /peers/list - Get all peers in mesh
POST /peers/request_connection/<peer_id> - Request connection to specific peer
WS /updates - WebSocket for real-time peer updates

Hint 2: Peer State Machine

enum PeerState {
    PEER_DISCONNECTED,
    PEER_DISCOVERING,     // Querying STUN, registering with server
    PEER_HOLE_PUNCHING,   // Attempting NAT traversal
    PEER_CONNECTED_DIRECT,// Direct P2P connection
    PEER_CONNECTED_RELAY, // Relayed connection
    PEER_REKEYING        // Handshake in progress
};

Hint 3: Multi-Peer Management

struct peer {
    char id[64];
    unsigned char public_key[32];
    struct sockaddr_storage endpoint;  // Where to send packets
    enum PeerState state;
    time_t last_seen;
    uint64_t tx_bytes, rx_bytes;
};

struct peer *peers[MAX_PEERS];
int num_peers = 0;

Hint 4: Packet Routing (“Which peer gets this packet?”)

// Read from TUN: packet destined for 10.0.0.X
// Look up which peer owns 10.0.0.X
struct peer *dest = find_peer_by_ip(dest_ip);
if (dest && dest->state == PEER_CONNECTED_DIRECT) {
    // Encrypt and send directly
    sendto(udp_fd, encrypted, len, 0, &dest->endpoint, ...);
} else if (dest && dest->state == PEER_CONNECTED_RELAY) {
    // Send to relay server with "forward to peer X" header
}

Books That Will Help

Topic	Book	Chapter
Mesh networking	“Computer Networks” by Tanenbaum	Ch. 4 - Network Layer
State machines	“Design Patterns” by Gang of Four	Ch. 5 - State Pattern
Distributed systems	Tailscale engineering blog	“How Tailscale Works” series
Connection management	“The Linux Programming Interface” by Kerrisk	Ch. 63 - epoll for many connections

Common Pitfalls & Debugging

Problem 1: “With 3+ peers, some pairs connect but others don’t”

Why: Each peer-to-peer connection is independent. Some NAT combinations work, others don’t
Fix: Implement per-peer connection state, use relay for failed direct connections
Quick test: Log connection state for each peer pair

Problem 2: “Coordination server becomes bottleneck with 50+ peers”

Why: All peers polling server every 30 seconds = lots of requests
Fix: Use WebSockets for push updates instead of polling, or implement gossip protocol
Quick test: Monitor server CPU/bandwidth with htop and iftop

Problem 3: “Peer roams to new network (WiFi→4G) and can’t reconnect”

Why: Endpoint IP:port changed, other peers still sending to old address
Fix: Peer must re-register with coordination server, which pushes updates to other peers
Quick test: Manually change network, watch logs to see if reregistration happens

Problem 4: “Memory leak - program uses more RAM over time”

Why: Likely not cleaning up dead peer connections or packet buffers
Fix: Implement peer timeout (if no packet in 5 minutes, mark as dead and free resources)
Quick test: Valgrind with long-running test

Problem 5: “Some packets arrive out of order or duplicated”

Why: UDP doesn’t guarantee order. Multiple paths (direct + relay race condition)
Fix: Use WireGuard’s packet counter to detect duplicates and reorder
Quick test: Send burst of pings, check sequence numbers

Additional Resources for Deep Study

For the truly deep dive, read the actual implementations:

WireGuard Source Code

Kernel module: git.zx2c4.com/wireguard-linux - See how the masters did it
Userspace Go implementation: git.zx2c4.com/wireguard-go - Easier to read than kernel C

Tailscale Source Code

github.com/tailscale/tailscale - Open source, well-documented Go code
Their DERP relay implementation shows how fallback works

Papers

“WireGuard: Next Generation Kernel Network Tunnel” by Jason Donenfeld - The whitepaper
“A Formal Security Analysis of the WireGuard Protocol” - Proves the protocol correct

Summary

This learning path covers VPNs, WireGuard, and mesh networking through 6 comprehensive hands-on projects that teach you to build secure network tunnels from first principles.

#	Project Name	Main Language	Difficulty	Time Estimate	Key Learning
1	TUN Packet Logger	C	Intermediate	1-2 weeks	Virtual network interfaces, packet capture
2	UDP Tunnel (Unencrypted)	C	Intermediate	1-2 weeks	Encapsulation, I/O multiplexing, tunneling
3	Add Encryption (ChaCha20-Poly1305)	C	Int-Advanced	1-2 weeks	AEAD, nonce management, crypto hygiene
4	Key Exchange (Noise Protocol IK)	C	Advanced	2-3 weeks	DH, forward secrecy, WireGuard security model
5	NAT Traversal & Hole Punching	C / Go	Advanced	2-3 weeks	STUN, UDP hole punching, P2P connections
Capstone	Mini-Tailscale (Mesh VPN)	C / Go	Very Advanced	1-2 months	Full mesh, coordination, relay fallback

Expected Outcomes

After completing these projects, you will:

Deep Technical Understanding
- Understand exactly how VPNs work at the kernel level (TUN devices, routing, encapsulation)
- Comprehend WireGuard’s security model and why it’s superior to IPsec/OpenVPN
- Know how Tailscale achieves direct P2P connections through NAT (the “magic” demystified)
Practical Implementation Skills
- Build encrypted tunnels using modern cryptography (ChaCha20-Poly1305, Curve25519)
- Implement the Noise Protocol handshake for authenticated key exchange
- Create NAT traversal systems using STUN and UDP hole punching
- Develop coordination servers and mesh networking protocols
Systems Programming Mastery
- Master Linux network programming (TUN/TAP, sockets, I/O multiplexing)
- Handle real-world challenges (MTU, fragmentation, packet loss, NAT types)
- Debug complex network issues with tcpdump, Wireshark, and system tools
Architectural Insight
- Distinguish control plane from data plane (Tailscale’s key innovation)
- Understand zero-trust architecture in practice
- Design resilient systems with fallback mechanisms (relay when P2P fails)
Interview Readiness
- Answer deep technical questions about VPNs, encryption, and networking
- Explain WireGuard vs IPsec/OpenVPN trade-offs
- Discuss NAT traversal success rates (~82% work, ~18% need relay)
- Demonstrate knowledge of modern mesh VPN architectures
Production-Quality Code
- Write secure C code with proper memory management
- Handle cryptographic material safely (libsodium best practices)
- Implement robust error handling and timeout logic
- Build testable, debuggable network systems

Recommended Learning Paths

Path 1: “I Want to Understand WireGuard” (3-4 months)

Projects 1 → 2 → 3 → 4
Focus: Crypto and protocol design
Outcome: You can explain WireGuard’s design choices and security model

Path 2: “I Want to Build Tailscale-like Systems” (4-6 months)

Projects 1 → 2 → 5 → Capstone
Focus: NAT traversal, mesh networking, coordination
Outcome: You can build your own mesh VPN

Path 3: “I Want Deep Systems Knowledge” (6+ months)

All projects in order (1 → 2 → 3 → 4 → 5 → Capstone)
Focus: Complete understanding from packets to mesh
Outcome: You’re a VPN/networking expert

Path 4: “I Just Want the Basics” (1-2 months)

Projects 1 → 2
Focus: Virtual interfaces and tunneling fundamentals
Outcome: You understand how VPNs work conceptually

Why This Matters in 2025

The VPN landscape is rapidly evolving:

Legacy VPNs (IPsec/OpenVPN) are dying: Too complex, too slow, too many security issues
WireGuard is winning: Merged into Linux kernel, ~57% faster than OpenVPN, modern crypto
Mesh VPNs are the future: Tailscale’s explosive growth (20,000 customers, $2B valuation) proves demand
AI companies need this: Low-latency mesh networks essential for distributed GPU training
Enterprise adoption accelerating: 93% of large enterprises use VPNs, moving to modern solutions

Real-World Applications

This knowledge directly transfers to:

Cloud networking: AWS VPC peering, Azure VNets, GCP interconnects all use VPN concepts
Kubernetes networking: Service meshes (Istio, Linkerd) use overlay networks like you’ll build
IoT security: Connecting distributed devices securely
Zero-trust architectures: Modern security model replacing perimeter defense
Remote work infrastructure: Building better alternatives to corporate VPNs

What Makes This Different

This is NOT a tutorial where you copy-paste code. This is engineering education:

First principles: You understand WHY, not just HOW
Real challenges: Debug segfaults, NAT issues, timing problems (like production)
Progressive complexity: Each project builds on previous knowledge
Production-quality: Use real libraries (libsodium), follow best practices
Comprehensive guidance: Deep-dive sections answer “what if I get stuck?”

You’ll emerge with knowledge that 99% of developers never acquire—the kind of deep systems understanding that sets you apart in interviews and enables you to build truly novel systems.

Ready to start? Begin with Project 1: TUN Packet Logger. By the end of the weekend, you’ll see raw IP packets flowing through your software network interface—and you’ll understand how every VPN on earth works.

Sources and Further Reading

Web Search Sources:

Official Documentation:

RFCs:

RFC 4787 - NAT Behavioral Requirements for UDP
RFC 5389 - STUN (Session Traversal Utilities for NAT)
RFC 5766 - TURN (Traversal Using Relays around NAT)
RFC 5869 - HKDF (HMAC-based Key Derivation Function)
RFC 8445 - ICE (Interactive Connectivity Establishment)