VPN enthusiasts and operators increasingly need rigorous, repeatable testing to detect privacy leaks and diagnose ISP or middlebox interference. This guide walks you through building a cross‑platform VPN leak and forensic test rig that works on Windows, macOS, Linux, Android, and home routers. You’ll get a clear threat model, a list of practical tests, concrete commands and captures to run, automation tips, and example interpretation of results as of October 2026.

Why a dedicated test rig?

Standard online leak checks (single web pages) are useful but fragile: they report symptoms, not root causes. A dedicated rig delivers:

  • Repeatable, instrumented tests across devices and networks.
  • Packet‑level evidence for troubleshooting and vendor conversations.
  • Automation for regression checks after client updates or server configuration changes.
  • Forensic artifacts suitable for disclosure or compliance audits.

Threat model and test goals

Define what “leak” means for you. Typical goals for the rig:

  • Detect DNS leaks (queries leaving tunnel, or over IPv6 when only IPv4 tunnel present).
  • Detect IPv4/IPv6 addressing leaks (source IPs not from VPN exit).
  • Detect WebRTC leaks (browser exposing local addresses).
  • Detect routing leaks (split‑tunnel misroute, policy bypass).
  • Detect transport‑level leaks (TCP handshake or TLS SNI exposed to ISP via misconfigured tunnel).
  • Collect reproducible packet captures and logs for root cause analysis.

Hardware and software checklist

  • Test laptop (Linux recommended for packet tooling). Example: Intel/AMD laptop running Ubuntu or Fedora.
  • Windows 11 and macOS machine for platform coverage (can be VMs).
  • Android phone (12+) with developer USB access; an iOS device if you need iOS tests (iOS capture is harder; use router‑side capture).
  • Raspberry Pi 4 or small ARM VPS to act as an instrumented VPN exit or middlebox.
  • Managed home router (OpenWrt or router that supports tcpdump / SSH) for router‑level captures.
  • Network switch with port mirroring or a cheap Ethernet TAP for hardware capture (recommended for router/ISP tests).
  • Essential software: tcpdump, tshark, Wireshark, mitmproxy (for HTTPS debugging with consent), socat, iperf3, curl, ping, nmap, and a scripting language (Python/bash).
  • For browser‑level tests: Chromium and Firefox with debugging flags.

Core tests and how to run them

Below are concrete, reproducible tests. Run each test with the VPN disconnected (baseline) and with the VPN connected. Keep time stamps and hostnames consistent for correlation.

1) Packet capture baseline

Start by capturing all traffic on the test host or upstream mirror. On Linux:

sudo tcpdump -i any -s 0 -w baseline-vpn-test.pcap

On Windows use WinDump (or run tcpdump in WSL) or PacketCapture tools and export pcap. Keep captures labeled with date/time and whether VPN was active.

2) DNS leak — raw and over IPv6

What to detect: DNS queries sent outside the encrypted tunnel or via unintended family (IPv6 when IPv4 tunnel only).

  1. On Linux/macOS, force a DNS query and watch captures:
dig @1.1.1.1 whoami.example.test +short
# or
dig @127.0.0.1 example.com

In the pcap, filter DNS: tshark -r capture.pcap -Y dns or in Wireshark: dns. Verify source IP of queries matches VPN exit (not local ISP IP).

Check for DNS over IPv6 by filtering for DNS over UDP on IPv6: tshark -r capture.pcap -Y 'ip6 and dns'.

3) WebRTC/local IP leak

Browsers can reveal local addresses via WebRTC even when a VPN is active. Test procedure:

  1. Open an instrumented browser and visit a WebRTC test page (e.g., browserleaks.com/webrtc) while capturing.
  2. Observe candidate gathering in the browser console and match to pcap; look for STUN traffic (UDP to STUN servers) that reveals local IPs.

In captures: filter for STUN/SRTP: tshark -r capture.pcap -Y stun. If STUN packets originate from a local, non‑VPN IP, you have a leak. Disable peer‑to‑peer or set browser flags to limit candidate gathering as mitigations.

4) IPv6 leaks

Many leaks happen because OS prefers IPv6 and VPN does not handle it. On Linux:

curl -6 -s https://ifconfig.co

If the returned public IPv6 is your ISP’s prefix instead of the VPN’s IPv6 or an expected disabled response, you have an IPv6 leakage problem. Capture and inspect packets with ip6 filters.

5) Routing leaks and split‑tunnel verification

To test whether routes bypass the VPN unexpectedly:

  1. Measure traceroutes to controlled endpoints behind the VPN exit. On Linux use tracepath or traceroute -n -I.
  2. Run traceroute to a known IP hosted at your exit node and ensure the first public hop is the VPN exit.

Compare routing table entries before and after connecting VPN (ip route show or route print on Windows). Look for unexpectedly persistent routes that prefer the default interface.

6) Application leak / split‑tunnel per‑app checks

Test popular apps that may bypass system proxies (e.g., package managers, system updates). Use socket‑level monitoring: 

sudo ss -tunap | grep -E 'apt|dnf|AppName'

Or watch pcap for connections originating from app process IDs. On Linux, use tcpdump -i any -w app-test.pcap 'host X.Y.Z.W' and correlate with process logs.

7) MTU/fragmentation and packet‑level leaks

Small MTU or fragmentation issues can produce identifiable patterns. Run an MTU probe:

ping -M do -s 1472

Observe ICMP fragmentation or packet drops in the capture. Misconfigured tunnels may leak fragments to the ISP.

Automating tests and continuous checks

Make repeatability easier by scripting the tests and running them in CI or a scheduled job on your Raspberry Pi or VPS. A minimal automation approach:

  • Containerize test scripts (Docker) with access to network namespace and tcpdump.
  • Use pytest or a simple bash harness to run test cases in sequence: baseline capture, DNS query, WebRTC, traceroute, compare results to golden‑file expectations.
  • Store pcaps and parsed summaries in an artifact store (S3 or a server you control) with timestamps.
  • Alert on regressions — e.g., DNS queries outside expected IP ranges.

Interpreting results — common root causes

After you collect captures and logs, common conclusions and where to look:

  • DNS queries from ISP IP: Check client resolver settings, systemd‑resolvd fallback, and VPN DNS push options. On Windows, check DNS suffix and adapter priority.
  • WebRTC STUN from local IP: Configure browser to disable non‑host candidates or use mDNS obfuscation, and ensure VPN forces UDP tunneling or blocks STUN.
  • IPv6 public address visible: Either disable IPv6 on client or configure IPv6 routing through the VPN or use firewall rules to drop native IPv6 when VPN up.
  • Split‑tunnel bypass: Look for persistent static routes from other software (container engines, virtualization) and examine client scripts that add routes on VPN connect.
  • Transport leaks at TCP/TLS: Some enterprise middleboxes may intercept TLS (SNI visible) using transparent proxies. Capture TLS ClientHello packets to inspect SNI exposure in clear text.

Preserving forensic integrity

Timestamps, checksums, and metadata matter if you will share evidence. Best practices:

  • Use synchronized NTP on all test devices.
  • Hash pcaps (SHA‑256) immediately after capture and archive checksums with your logs.
  • Record environment: OS, VPN client version, server endpoint, configuration snippets (sanitized if necessary), and the exact commands used.
  • If you plan to publish, remove third‑party personal data and redact where appropriate, but keep enough context to reproduce.

Example quick checklist to run before publishing a bug report

  1. Repeat the failing test three times with fresh captures.
  2. Collect ip route / ip addr and output of VPN client status.
  3. Collect application logs (VPN client debug mode).
  4. Package pcaps, checksums, and a README describing reproduction steps.
  5. Attempt to reproduce on a different network and device to rule out local factors.

Hardening and mitigations

Once you identify leaks, apply mitigations that match your environment:

  • Client side: enforce “kill switch” iptables/nft rules, disable native IPv6 when VPN lacks IPv6 support, harden browser WebRTC settings, pin DNS to VPN‑provided resolvers.
  • Server side: push DNS and IPv6 routes, enforce full tunneling for critical services, provide a clear API for clients to query expected exit IPs, and support ephemeral session metadata for verification.
  • Router/edge: drop native traffic when VPN is active (for managed devices), use firewall policies to block pre‑VPN egress.

Closing: maintain a test culture

Leak detection is not a one‑off activity. Treat the rig as part of an operational toolkit: run smoke tests after client updates, include it in incident response playbooks, and share anonymized summaries with upstream VPN developers or the community. With the right captures and process, you’ll turn noisy symptom reports into actionable, verifiable fixes.