Anonymity Part 2: VPN Fundamentals

1

VPN Types & Protocols — OpenVPN, WireGuard, IPSec/IKEv2

INTERMEDIATE ✓ Done ⌄

Scenario: Before deploying a VPN solution, you need to understand the trade-offs between the major protocols. Select each protocol below to examine its technical characteristics. Then study the tunnel diagram to understand what a VPN actually does — and does not — protect.

Click each protocol card to see its details:

WireGuard

UDP / PORT 51820

OpenVPN

TCP 443 / UDP 1194

IPSec / IKEv2

UDP 500 / 4500

What a VPN tunnel looks like on the wire:

Your Device

encrypted

ISP

still encrypted

VPN Server

cleartext

Destination

encrypted tunnel

cleartext (if no HTTPS)

WHAT A VPN PROTECTS

A VPN encrypts traffic between your device and the VPN server, preventing your ISP from reading content or logging destination IPs. It also hides your real IP from websites you visit — they see the VPN server's IP instead.

WHAT A VPN DOES NOT PROTECT

The VPN provider sees all your decrypted traffic (if you visit HTTP sites) and knows your real IP. You are shifting trust from your ISP to your VPN provider. A VPN also does not protect against browser fingerprinting, cookies, or malware on your own machine.

2

WireGuard Setup — Install, Key Generation & wg0 Interface

INTERMEDIATE ✓ Done ⌄

Scenario: Your organisation has chosen WireGuard for its simplicity, speed, and small attack surface (~4000 lines of code vs OpenVPN's ~600,000). Walk through the full setup: install, key generation, configuration, and connection.

Run each command in order. The terminal accepts partial matches — focus on the key tokens of each command.

wireguard setup

# WireGuard setup — run commands in order # Step 1: install Step 2: generate keys Step 3: bring up interface Step 4: verify student@hexworth:~$

student@hexworth:~$

Commands to try in order:
1. sudo apt install wireguard
2. wg genkey | tee privatekey | wg pubkey > publickey
3. sudo wg-quick up wg0
4. sudo wg show

The /etc/wireguard/wg0.conf you create:

# /etc/wireguard/wg0.conf [Interface] PrivateKey = wEaXi4D9hGkYnP3j7rRf2mLz0bNcV5oQs1Ue8TvX6w= # your private key Address = 10.8.0.2/24 DNS = 1.1.1.1 [Peer] PublicKey = JkT9mHr3Lp2Yz0XbCnA5eOq7vDi1WsFu4Gk8NjE6cY= # server public key Endpoint = vpn.hexworth.io:51820 AllowedIPs = 0.0.0.0/0, ::/0 # route all traffic PersistentKeepalive = 25

WIREGUARD VS OPENVPN COMPLEXITY

WireGuard has a 4,000-line kernel module vs OpenVPN's 600,000+ lines of userspace code. Fewer lines means fewer bugs, faster security audits, and a smaller attack surface. WireGuard also uses a fixed, modern cryptographic suite (ChaCha20-Poly1305, Curve25519, BLAKE2) — no cipher negotiation means no downgrade attacks.

PRIVACY CONSIDERATION

WireGuard's default design logs peer IP addresses in kernel memory until the interface is brought down. If privacy against the VPN server is a concern, ensure your provider implements IP assignment rotation or uses an obfuscated front-end (like Mullvad's implementation).

3

OpenVPN Configuration — Import .ovpn & TLS Handshake Analysis

INTERMEDIATE ✓ Done ⌄

Scenario: Your corporate environment uses OpenVPN because it supports TCP mode (useful when UDP is blocked on restrictive networks) and has mature enterprise tooling. You receive a client.ovpn config file and need to connect and verify the tunnel interface came up.

Install OpenVPN, connect, and verify the tunnel interface:

openvpn client

# client.ovpn has been placed in your home directory. # Step 1: install openvpn # Step 2: connect with the config file # Step 3: verify the tun0 interface student@hexworth:~$

student@hexworth:~$

Commands to try in order:
1. sudo apt install openvpn
2. sudo openvpn --config client.ovpn
3. ip addr show tun0

THE TLS HANDSHAKE LOG

When OpenVPN connects, it logs every step of the TLS handshake: certificate exchange, cipher negotiation (you will see something like AES-256-GCM), and finally "Initialization Sequence Completed" which signals the tunnel is live. The tun0 interface appearing in ip addr output is the virtual tunnel device — all traffic routed through it exits from the VPN server's IP.

TCP vs UDP MODE

OpenVPN over TCP (port 443) is firewall-friendly — it looks like HTTPS and passes through most corporate/hotel firewalls. However, TCP-over-TCP creates "TCP meltdown" under packet loss because both the inner and outer protocol do retransmission. For performance-sensitive work, prefer UDP (port 1194) whenever the network allows it.

4

VPN Kill Switch — iptables Rules & IP Leak Prevention

ADVANCED ✓ Done ⌄

Scenario: If a VPN connection drops unexpectedly, the OS falls back to routing traffic over your real interface — exposing your IP to every site you visit. A kill switch uses iptables to block all non-VPN traffic so that if the tunnel dies, nothing leaks. Configure and test one now.

Current VPN & kill switch state:

VPN: connected | Kill switch: NOT configured (traffic leaks if VPN drops)

Apply the kill switch rules, then simulate a VPN disconnect:

iptables kill switch

# Configure iptables kill switch rules, then simulate a VPN drop. # Valid commands: iptables rules below, then: simulate vpn drop student@hexworth:~$

student@hexworth:~$

Commands to run in order:
1. iptables -A OUTPUT -o wg0 -j ACCEPT
2. iptables -A OUTPUT -o eth0 -p udp --dport 51820 -j ACCEPT
3. iptables -A OUTPUT -o eth0 -j DROP
4. simulate vpn drop — test what happens if wg0 goes down

The three rules explained:

# Rule 1 — Allow all traffic out through the VPN tunnel interface
iptables -A OUTPUT -o wg0 -j ACCEPT

# Rule 2 — Allow only WireGuard handshake packets on the real interface
#          (necessary to re-establish the tunnel if it drops)
iptables -A OUTPUT -o eth0 -p udp --dport 51820 -j ACCEPT

# Rule 3 — Block everything else leaving the real interface
#          (this is the kill switch — no route = no leak)
iptables -A OUTPUT -o eth0 -j DROP
                

WHY KILL SWITCHES MATTER

VPN software can crash. Network interfaces can flap. Without a kill switch, your OS will happily route traffic through your real interface the moment the VPN goes down — often for minutes before you notice. The iptables rules above ensure that only WireGuard-encapsulated packets (via wg0) and the WireGuard handshake itself can leave the machine.

PERSISTENCE ACROSS REBOOTS

iptables rules are flushed on reboot by default. Use iptables-save > /etc/iptables/rules.v4 and install iptables-persistent to restore them at boot. For WireGuard specifically, add the iptables commands as PostUp and PreDown hooks in wg0.conf.

5

VPN vs Tor — Scenario Decision Matrix

ADVANCED ✓ Done ⌄

Scenario: Knowing how to deploy a VPN is only half the battle. Knowing when to use a VPN versus Tor — or both, or neither — is the operational judgment that separates competent admins from security-aware ones. Work through five real-world scenarios and choose the right tool.

Click each scenario to see the recommended tool and reasoning:

THE CORE TRADE-OFF

VPN = you trust your VPN provider not to log or betray you. You get speed (WireGuard adds ~5 ms latency), stable connections, and real IP masking from sites.

Tor = you trust no single entity. Traffic is layered through three independent relays — even if one is compromised, your identity is not. The trade-off: 200–500 ms added latency and no persistent connections (breaks streaming, VoIP).

THE "VPN + TOR" TRAP

Running Tor over VPN hides Tor usage from your ISP (useful in countries where Tor is blocked) but does NOT improve anonymity — the VPN provider still knows your real IP. Running VPN over Tor (Tor first, then VPN) is almost never recommended: it breaks Tor's anonymity model and adds the VPN as a single point of trust inside the Tor circuit.

Lab Complete