Complete VPN leak test 2026: DNS, WebRTC, IPv6, MTU, kill switch - unified methodology

An active and technically connected VPN doesn't mean guaranteed anonymity. Five distinct leak vectors can compromise the confidentiality of a session even with an apparently operational VPN tunnel: DNS (name resolution outside the tunnel), WebRTC (IP exposure via browser API), IPv6 (clear-text transit if not blocked), MTU (fragmentation and clear-text fragment leakage), failing kill switch (clear traffic during invisible micro-cuts). Independent research regularly finds that a sizable share of home VPN setups present at least one leak among these five vectors despite a VPN client displaying "protected".

This guide consolidates the testing methodology covering all 5 dimensions, with two open-source CLI tools we maintain (dns-leak-detector-cli and webrtc-leak-detector), reproducible shell commands, and validation thresholds to respect. It targets technical users (sysadmins, devs, security) and GDPR-Article-32-compliant freelancers documenting quarterly verification. Total protocol duration: ~30 minutes for a standard home setup.

Why DNS test alone is no longer enough in 2026

The standard DNS leak test has become insufficient for two specific technical reasons. First reason: the generalization of IPv6 among ISPs. Comcast, Verizon, AT&T, BT, Orange, Deutsche Telekom have massively deployed IPv6 on their fiber/cable links since 2023-2024. May 2026, ~40% of fiber connections in the US and EU have a native dual-stack IPv4/IPv6 setup. If the VPN client doesn't explicitly tunnel IPv6 (default case on some OpenVPN versions without specific configuration), IPv6 traffic exits via the default ISP route - full identity leak not detected by a standard DNS test focused on IPv4.

Second reason: WebRTC prevalence in modern browsers. WebRTC (Web Real-Time Communication) is enabled by default in Chrome, Edge, Firefox, Safari to allow integrated video calls (Google Meet, WhatsApp Web, Microsoft Teams Web). The RTCPeerConnection API enumerates ICE (Interactive Connectivity Establishment) candidates exposing the device's local AND public IP. On Chrome and Edge in 2026, approximately 30% of installations still expose a local or public IP distinct from the VPN tunnel one, even with VPN active. This leak is invisible user-side (no browser indicator) and silent VPN-side (the tunnel remains "connected").

Add to that leaks from miscalibrated MTU (fragmentation causing clear-text fragment leakage during server-side reassembly) and kill switch failures (1-3 second micro-cuts during WiFi/4G network changes, during which traffic passes in clear via the default ISP route).

Vector 1 - DNS leak: detailed method

DNS leak occurs when the VPN client doesn't capture all name resolution queries and lets the OS query ISP or public resolvers (8.8.8.8 Google, 1.1.1.1 Cloudflare) in parallel. Consequence: these resolvers see every query (consulted domains) pass through, exposing a complete activity log to the ISP or public operator.

Recommended test - dns-leak-detector-cli. Node.js CLI tool we maintain on GitHub ricco020/dns-leak-detector-cli. Installation and execution:

npx dns-leak-detector --resolver auto --hostnames 10 --verbose

The script resolves 10 distinct hostnames (random subdomains) and analyzes server-side resolvers handling each query. Expected output: all identified resolvers belong to the VPN provider pool. Failing output: presence of ISP resolvers (known ASN prefixes AS7922 Comcast, AS701 Verizon, AS2856 BT, AS3215 Orange) or non-VPN public resolvers (8.8.8.8 Google, 9.9.9.9 Quad9, 1.1.1.1 Cloudflare).

Complementary web tests. dnsleaktest.com (extended test on 1000+ resolvers), browserleaks.com/dns. Advantage: no installation. Drawback: rely on browser query, can mask system-level leaks (OS) outside the browser.

Repair if leak detected. In NordVPN settings: Settings → DNS → Use NordVPN DNS (enabled by default). In Surfshark: Settings → Advanced → Custom DNS (disable, leave auto). In ExpressVPN: automatic. If persistent leak after client verification: check that the OS doesn't have a hardcoded DNS resolver (macOS Network Preferences → DNS, Windows Network Settings → Properties → IPv4 → DNS). For open-source VPNs (manual WireGuard), explicitly add the DNS = 10.0.0.1 directive (VPN server internal DNS IP) in the config file.

Vector 2 - WebRTC leak: the least known

WebRTC exposes via the JavaScript API RTCPeerConnection.createOffer() all ICE candidates including: local IP (private LAN 192.168.x.x, 10.x.x.x, 172.16-31.x.x), public IP (network exit via STUN), sometimes native IPv6. A malicious or simply curious website can query these candidates within milliseconds without explicit user permission.

Recommended test - webrtc-leak-detector. Standalone HTML page ricco020/webrtc-leak-detector. Open in browser with VPN active. The script collects ICE candidates and compares with expected tunnel IP.

Expected output: only the VPN server public IP visible. No local IP exposed. No alternative public IP.

Typical failing output: tunnel public IP + private LAN local IP visible (partial leak, identifies local network but not country), or tunnel public IP + distinct ISP public IP (full leak, identifies real country).

Repair. In NordVPN: Settings → Advanced → enable "Block WebRTC". In Chrome: install WebRTC Control extension that disables non-tunneled ICE candidates. In Firefox: about:config → media.peerconnection.enabled = false. On Safari: more delicate configuration, usually solved via VPN client Block WebRTC.

Vector 3 - IPv6 leak: 40% of US/EU fibers affected

IPv6 is the most underestimated leak zone in 2026. ISPs (Comcast, BT, Orange, Telefonica, Deutsche Telekom) massively deploy dual-stack IPv4/IPv6 on fiber. If the VPN client tunnels IPv4 but lets IPv6 exit via the default route, any request to an IPv6-capable service (Google, Facebook, Cloudflare, AWS) transits outside the tunnel.

Direct CLI test:

curl -6 https://ipv6.icanhazip.com --max-time 5

Expected output: either timeout (IPv6 blocked by VPN, safe configuration) or IPv6 IP belonging to the VPN pool.

Failing output: native ISP IPv6 IP visible. Typical prefixes: 2001:558::/29 Comcast, 2600:1700::/24 Verizon, 2a00:23c::/29 BT, 2a01:e00::/27 Orange, 2003:a::/24 Deutsche Telekom.

Repair. In NordVPN: Settings → Advanced → enable "Block IPv6". In Surfshark: auto by default since v4.x. In ExpressVPN: Settings → Advanced → Block IPv6. OS-level alternative: Linux sysctl net.ipv6.conf.all.disable_ipv6=1, Windows Disable-NetAdapterBinding -ComponentID ms_tcpip6, macOS via Network Preferences → disable IPv6 on the interface.

Vector 4 - Miscalibrated MTU: fragmentation and partial leaks

MTU (Maximum Transmission Unit) defines the maximum size of an IP packet transmitted without fragmentation. On standard Ethernet, MTU = 1500 bytes. A VPN tunnel adds overhead: ~80 bytes for WireGuard, ~28-50 bytes for OpenVPN UDP, up to 70 for OpenVPN TCP with compression. Effective tunnel MTU = 1500 - overhead.

If the OS continues sending 1500-byte packets over a tunnel with 1420 effective MTU, fragmentation: the packet is split into 2 fragments, transmitted separately, reassembled at destination server. Consequences: degraded performance (latency +50-100ms typical), sometimes losses (intermediate routers handle IPv6 fragmentation poorly), and per VPN implementations, clear-text fragment leak if the tunnel rejects oversized packets (rare but documented on OpenVPN UDP with compression).

Direct CLI test:

# Linux / macOS
ping -M do -s 1472 example.com

# Windows
ping -f -l 1472 example.com

Interpretation: 1472 bytes payload + 28 bytes ICMP/IP header = 1500 total. If echo returns: MTU 1500 acceptable. If "message too long": step down by 50 (1422, 1372, 1322...) until echo returns.

Optimal MTU per VPN protocol: NordLynx / WireGuard 1420 typical, OpenVPN UDP 1450 typical, OpenVPN TCP 1430 typical, NordWhisper 1420 typical. Configure this value manually on the VPN interface if degraded performance observed.

Vector 5 - Failing kill switch: invisible micro-cuts

The kill switch is the last line of defense in case of VPN tunnel drop. Two modes exist: app mode (blocks traffic of specific applications) and system mode (blocks all outgoing OS traffic). Only system mode is robust enough to guarantee leak absence during 1-3 second micro-cuts invisible to the user (WiFi network change, subway 4G loss, LTE↔5G transition).

Reproducible test:

# Terminal 1 - launch a continuous ping to ipinfo.io
watch -n1 curl -s ipinfo.io | jq .ip

# Terminal 2 - brutally disconnect the VPN
sudo killall -9 nordvpn-daemon  # or equivalent per client

Expected output: the curl in terminal 1 fails immediately with timeout/refused. No transparent fallback to ISP IP. The kill switch worked.

Failing output: the curl continues to return an IP, but it's no longer the VPN IP - it's the real ISP IP. The micro-cut let traffic through. Kill switch in app mode only or not enabled.

Repair. In NordVPN: Settings → Kill Switch → enable Kill Switch (system-level) and Internet Kill Switch. In Surfshark: Settings → VPN settings → Kill switch (enabled). In ExpressVPN: Network Lock (enabled by default). For open-source VPNs (manual WireGuard), implement kill switch via explicit iptables/nftables rules denying all outbound traffic not encapsulated in wg0.

Documenting for GDPR Article 32 compliance

For a freelancer or company subject to GDPR, the quarterly test constitutes a reasonable verification of the VPN technical measure under Article 32. Recommended documentation:

• Dated screenshot of each test result
• Archive in vpn-tests/{date}/ with SHA-256 hash of the file
• Line in Records of Processing: "Quarterly absence-of-VPN-leak verification - last test DD/MM/YYYY"
• In case of leak detected and corrected: note the leak, the cause, the applied correction, and the retest date

This documentation is requested in case of regulatory audit. See our complete GDPR freelancer guide for legal context.

What to keep in mind

Testing a VPN in 2026 is no longer a single DNS check - it's a unified 5-dimension methodology (DNS, WebRTC, IPv6, MTU, kill switch) taking ~30 minutes and able to reveal silent leaks that a standard DNS test misses. Open-source tools available: dns-leak-detector-cli and webrtc-leak-detector, with complementary shell commands for IPv6, MTU and kill switch. Quarterly test mandatory or at any context change (new ISP, OS update, new VPN client). For GDPR Article 32, document each verification with dated screenshot - proof of reasonable diligence in case of audit.

Disclosure: Eric Gerard maintains the open-source tools dns-leak-detector-cli and webrtc-leak-detector cited in this article. No direct monetization of the tools - only NordVPN affiliate links in the editorial content. Technical sources: RFC 4787 NAT behavior, RFC 5245 ICE, WireGuard whitepaper, W3C WebRTC specification.