I recently spent a weekend auditing a couple of consumer VPN setups—one based on WireGuard, one using the ProtonVPN client—to answer the question I get a lot: "How can I check a VPN for leaks and hidden telemetry without becoming a reverse‑engineering expert?" I wanted something practical you can reproduce with open tools and a modest amount of time. Below I walk you through the tests I run, why they matter, and concrete commands and techniques that work on a Linux desktop. I’ll call out differences between a simple WireGuard user configuration and a more full‑featured client like ProtonVPN.
What I’m trying to discover
When I audit a VPN I’m focused on a few concrete outcomes:
These are the pragmatic risks for most users. Advanced forensic tracing of intentionally obfuscated telemetry is possible but rare for mainstream clients; the tests below catch most common misconfigurations and suspicious behaviour.
Baseline environment and tools
My test machine is a Linux laptop. Tools I rely on:
If you’re on macOS or Windows, equivalents exist (Packet Capture, tcpdump, Sysinternals Process Explorer), but commands will differ. For ProtonVPN, I test both the GUI/daemon and the low‑level system behaviour produced by their client.
Step 1 — Establish a reproducible baseline
Before enabling any VPN, I record what my IP addresses, DNS servers and interfaces look like. This gives me a baseline to detect leaks.
Commands I run:
Save the outputs to a file (e.g. baseline.txt). Also run a quick tcpdump to capture any background chatter for a minute:
Step 2 — WireGuard: config check and behavioral tests
If you’re using a simple WireGuard configuration (wg-quick or a home server), start by inspecting the config file.
Bring up the interface:
Then monitor traffic:
You should see your traffic on wg0 and very little on the physical interface after tunnel is up. If you still see HTTP/DNS from your user processes on the physical interface, you have a leak.
Step 3 — DNS and WebRTC leaks
DNS is the most common leak. If your resolver doesn’t get routed into the VPN, your ISP sees your lookups. To test:
Also check DNS queries in a capture (filter by port 53 or by DNS protocol in Wireshark). For WebRTC leaks from a browser, I use a private tab and run a JavaScript test page (there are several) while watching packet capture to see whether STUN requests go via the tunnel.
Step 4 — IPv6: the silent leak
Many consumer VPNs and clients don’t handle IPv6 well and simply ignore it, letting traffic flow outside the tunnel. Test IPv6 enabling/disabling:
If you see an IPv6 public address that’s not from the VPN, you have an IPv6 leak. The safe immediate fix is to disable IPv6 locally (sysctl or NetworkManager) until the provider supports it.
Step 5 — Kill switch testing
A good kill switch should block any non‑VPN traffic if the tunnel drops. Test it by simulating a tunnel failure:
If traffic continues on the physical interface, the kill switch failed. For WireGuard setups you can implement policy routing and firewall rules that drop traffic not sent via the wg interface. For ProtonVPN their Linux client exposes a kill switch option—verify behavior by force‑killing the daemon and observing whether the system firewall persists.
Step 6 — Detecting telemetry and background connections
Telemetry is often small DNS requests or HTTPS POSTs from the client or bundled binaries. To find it I combine process monitoring and packet capture.
In ProtonVPN’s case, I watched the daemon create TLS connections to a handful of domains after startup—these can be support/telemetry endpoints, subscription checks, or VPN control plane. Cross‑reference domains with open data (whois, reverse DNS). Small background DNS queries to analytics domains are a red flag.
Using network namespaces to isolate and observe
One of my favorite tests is to run an application inside a network namespace that has only the VPN interface. That way, if the app manages to leak outside, it’s a bug in the VPN or tunnel routing.
This helps separate host‑level telemetry from what the app itself is doing.
Quick reference: tests, tools and what to look for
| Test | Tool/Command | What indicates a problem |
|---|---|---|
| IP leak | curl https://ifconfig.co | Public IP on physical interface, not VPN IP |
| DNS leak | tcpdump port 53, dig | Queries sent to ISP/third‑party resolvers |
| IPv6 leak | curl -6 https://ifconfig.co | Public IPv6 reachable outside tunnel |
| Kill switch | Bring tunnel down while transfer active | Traffic continues on physical interface |
| Telemetry | strace, lsof, tcpdump | Unexpected connections to analytics/control domains |
When I test ProtonVPN specifically, I combine their GUI/daemon behaviour checks with the same packet captures. Proton is transparent about a no‑logs policy, but client behaviour still matters—does it phone home? Are connections encrypted and tethered to the VPN control plane only? I found it useful to run the Proton client with debug logging enabled and correlate with my packet captures.
Finally, one important note: some telemetry or control plane connections are legitimate (e.g., certificate revocation checks, update checks). The audit goal is to be able to explain each connection, not to assume all background traffic is malicious. The combination of strace/lsof to find the originating process and tcpdump/Wireshark to inspect destination and content (SNI, certs, query names) lets you make that call.
