Reproducible laboratory specification · version 1.0.0
VPN leak test protocols
Four versioned protocols define what to test, what evidence to preserve, and what a pass can—and cannot—prove. They are publication specifications, not published test results. A provider receives no result until completed runs and review records exist.
Protocol kill-switch · version 1.0.0
VPN kill switch and route-transition protocol
Measures whether controlled DNS and HTTPS probes escape outside the VPN during connection failures and route changes.
Scope
- Windows
- macOS
- iOS
- Android
- full-tunnel mode
- declared kill-switch modes
Required evidence
- App version and build identifier
- Timestamped route and interface snapshots
- Packet capture covering baseline, interruption, and recovery
- Public-IP and resolver observations
- At least five repetitions per scenario
Test matrix
VPN process termination
Observe the traffic boundary when the VPN process exits unexpectedly.
Actions
- Start capture and probes
- Terminate the VPN process
- Continue probes through recovery
Pass condition
No controlled probe reaches its target outside the encrypted tunnel.
Scenario ID: ks-process-termination
Network change
Test protection while moving between available network paths.
Actions
- Start capture
- Switch network path
- Run controlled probes before and after reconnect
Pass condition
Traffic remains blocked until a protected tunnel is restored.
Scenario ID: ks-network-change
Sleep and wake
Test route protection across device suspension.
Actions
- Start capture
- Suspend and wake device
- Run controlled probes immediately
Pass condition
No controlled traffic escapes during the wake and reconnection window.
Scenario ID: ks-sleep-wake
Limitations
- A pass applies only to the recorded app build, operating system, mode, server, and network.
- Packet capture must cover every usable physical interface; an incomplete capture is inconclusive.
- This protocol does not prove protection against traffic not generated by the controlled probes.
Protocol dns · version 1.0.0
VPN DNS path and resolver-leak protocol
Compares configured resolvers, packet-level destinations, and controlled authoritative DNS observations.
Scope
- IPv4 DNS
- IPv6 DNS
- system resolver
- browser secure DNS
- connect and reconnect states
Required evidence
- System resolver configuration
- Packet capture on tunnel and physical interfaces
- Unique per-run query names from a controlled domain
- Authoritative resolver log with timestamps
- Browser secure-DNS setting
Test matrix
Connected resolver path
Identify the resolver and network path used while the VPN is connected.
Actions
- Capture interfaces
- Resolve A and AAAA records
- Compare local and authoritative logs
Pass condition
No query is observed on an undeclared non-tunnel resolver path.
Scenario ID: dns-connected
Resolver transition
Detect stale or ISP resolver use during reconnect.
Actions
- Interrupt network path
- Issue queries throughout reconnect
- Inspect resolver state after recovery
Pass condition
Queries are blocked or use only declared protected resolvers throughout transition.
Scenario ID: dns-reconnect
Limitations
- A public resolver address alone does not prove which organization received the complete query.
- Cached responses are not valid evidence of a resolver path.
- Encrypted DNS inside the browser must be recorded separately from the operating-system resolver.
Protocol webrtc · version 1.0.0
Browser WebRTC address-exposure protocol
Records ICE candidates across browsers and distinguishes public, private, relay, and mDNS-obfuscated addresses.
Scope
- Chrome
- Firefox
- Safari
- Edge
- default browser settings
- VPN connected state
Required evidence
- Browser name and exact version
- Browser WebRTC and secure-DNS settings
- Raw sanitized ICE candidate list
- Public IP observed outside and inside the VPN
- Repeat run in a clean browser profile
Test matrix
Default-profile ICE gathering
Measure addresses exposed under supported default browser behavior.
Actions
- Open local test page
- Gather candidates to completion
- Classify each candidate
Pass condition
No non-VPN public address appears in an ICE candidate or related request.
Scenario ID: webrtc-default-profile
ICE gathering after network change
Detect stale non-VPN candidates after an interface transition.
Actions
- Gather baseline
- Change network
- Gather candidates after VPN recovery
Pass condition
No non-VPN public address is exposed during or after the transition.
Scenario ID: webrtc-network-change
Limitations
- Private RFC1918 addresses and mDNS hostnames are not automatically public-IP leaks.
- Browser policy changes can alter results without a VPN app update.
- A page-level test does not prove that every embedded browser or native WebRTC stack behaves identically.
Protocol ipv6 · version 1.0.0
VPN IPv6 protection protocol
Measures native IPv6, DNS over IPv6, and transition behavior on dual-stack, IPv6-only, and NAT64 networks.
Scope
- dual-stack
- IPv6-only where supported
- NAT64/DNS64
- IPv6 route changes
- full-tunnel mode
Required evidence
- IPv4 and IPv6 interface addresses with public values redacted where necessary
- IPv6 route table before and after VPN connection
- Packet capture on tunnel and physical interfaces
- Controlled A, AAAA, and HTTPS endpoints
- Network type and translation mechanism
Test matrix
Dual-stack protection
Determine whether IPv6 bypasses an IPv4-only or dual-stack tunnel.
Actions
- Capture all interfaces
- Query A and AAAA
- Connect to controlled IPv4 and IPv6 endpoints
Pass condition
IPv6 is protected by the tunnel or intentionally blocked without fallback exposure.
Scenario ID: ipv6-dual-stack
IPv6-only and NAT64/DNS64 path
Test protection where IPv4 services are reached through translation.
Actions
- Connect VPN
- Resolve controlled A-only and dual-stack names
- Inspect translated connections
Pass condition
Controlled connections use the protected path and expose no non-VPN IPv6 source.
Scenario ID: ipv6-nat64
Limitations
- Results from one access network do not cover other IPv6 transition technologies.
- Disabling IPv6 can prevent a leak but is not equivalent to providing IPv6 through the tunnel.
- A browser-only address check cannot replace route and packet observations.