Test Your VPN's No-Logs Claim With Wireshark

Wireshark can show whether your computer sends traffic outside a VPN tunnel. It cannot reveal what a remote VPN operator writes to disk, retains in an analytics system, or discloses later. A clean capture is evidence about your local traffic path, not proof of a no-logs promise.

A useful audit therefore has two tracks: test observable client behavior, and evaluate the provider's documented practices separately. The workflow below uses your own device and authorized traffic, keeps captures small, and avoids claiming more than packet evidence can establish.

Define the claim and organize your evidence

Begin by translating “no logs” into specific questions. Does it exclude browsing destinations, connection timestamps, source addresses, bandwidth accounting, or only some of those? What about account records, billing systems, support tickets, and crash reports? Different data types require different evidence.

Use the Regex Tester & Match Highlighter below to test patterns against a short, sanitized text export of your observations. For example, a JavaScript pattern can identify labels such as DNS, QUIC, or WireGuard in notes. Regex is an organizing aid, not a packet decoder or a test of whether the provider stores records.

Do not paste packet payloads, cookies, private addresses tied to your identity, or account details into an online tool. Create a minimal synthetic sample first. Keep a local evidence folder containing app version, settings, capture interface, test steps, and the exact scope of each conclusion.

Capture on the right interfaces

A VPN exposes at least two relevant viewpoints: the physical interface, where encapsulated traffic leaves the machine, and the logical tunnel interface, where inner traffic may be visible. Interface availability depends on the operating system, capture permissions, and VPN implementation. Capturing only inside the tunnel says little about bypass traffic.

Install Wireshark or its command-line companion from a trusted package source. Follow the Wireshark documentation for platform-specific capture permissions rather than running an entire graphical session as root. On Linux, an authorized short capture can look like this:

tshark -D
# Replace wlan0 with the physical interface listed above.
tshark -i wlan0 -a duration:60 -w vpn-physical.pcapng

The command writes a capture in your current directory. Choose a restricted local folder, not a synced public workspace. Captures can contain identifying metadata and unencrypted traffic from applications you forgot were running. Close unrelated applications, avoid shared computers, and capture only networks and devices you are authorized to inspect.

If practical, capture the tunnel interface during a second identical run or select both interfaces in Wireshark. Label the files clearly so that inner traffic is not later mistaken for leakage on the physical interface. Record when the VPN connected and when you generated each test request.

Test routing and DNS with controlled traffic

First connect the VPN using its normal supported settings. Generate known test traffic, such as a request to an HTTPS endpoint you control, and note the destination address and expected tunnel endpoint. Inspect both IPv4 and IPv6 behavior; an IPv4-only capture filter can hide the very bypass you are looking for.

Use Wireshark display filters after capture, not an overly narrow capture filter that discards evidence. Examples for reviewing the physical-interface capture include:

# Wireshark display-filter examples; enter one at a time.
dns
udp.port == 53 || tcp.port == 53
ip.addr == 203.0.113.20
ipv6

Replace the documentation address with your controlled endpoint's address. These are display filters, not shell commands. Traditional DNS commonly uses port 53, but encrypted DNS and application-specific resolution may not appear there. An absence of port-53 packets does not establish that every query reached the VPN's resolver.

Local network traffic also needs interpretation. ARP, neighbor discovery, DHCP, and permitted local services are not automatically internet privacy leaks. Compare observed packets with the documented route policy, including any configured split-tunnel exclusions.

If you see unexpected name resolution outside the tunnel, investigate the OS and application configuration before blaming the provider's logging policy. The Linux DNS leak guide covers a separate but related problem: resolver routing and data retention are not the same claim.

Check transitions and interpret encrypted traffic carefully

Repeat the capture during connection changes: initial connection, an authorized manual disconnect, reconnection, and a Wi-Fi transition if available. Use a harmless request to your controlled endpoint to observe whether traffic pauses, bypasses, or resumes through the tunnel. Do not disable safeguards just to obtain a convenient result.

A kill switch may intentionally block traffic after tunnel failure, but its exact behavior varies by app and settings. Keep a separate record of expected behavior. The kill-switch configuration guide provides context for distinguishing a disconnected tunnel from a failed blocking policy.

Expect encrypted outer traffic to reveal endpoint addresses, timing, and packet sizes. Encryption does not hide all metadata. HTTPS payloads are usually unreadable without additional secrets, even on the tunnel interface. Do not install interception certificates or collect browser key material for this basic routing audit.

Packet analysis also cannot identify every application reliably from a port number. UDP on an unfamiliar port is not inherently suspicious, and a recognizable tunnel endpoint does not demonstrate that the operator deletes connection records. Keep observations factual: which interface, which destination, and at what stage of the test.

Evaluate remote logging claims with different evidence

Review the provider's privacy policy, retention descriptions, and any available independent audit reports. Read the report scope, covered infrastructure, testing period, limitations, and remediation notes. An audit of one application or server image is not necessarily an audit of account systems or every production endpoint.

Look for operational consistency: does the policy explain diagnostic logging, optional analytics, legal requests, and account deletion? Ask precise questions when wording is ambiguous. The EFF Surveillance Self-Defense resources help connect those questions to a realistic threat model rather than an absolute anonymity promise.

For your local notes, return to the regex testing tool with synthetic lines and a simple pattern such as DNS|QUIC|WireGuard. Use matches to group observations, then verify each group against the capture. The MDN documentation explains JavaScript regular-expression behavior if flags or case sensitivity produce unexpected matches.

Finish with a bounded finding: “No unexpected internet-bound traffic was observed on this interface during these tests” is defensible. “The provider keeps no logs” is not established by those tests. Store captures securely, share only redacted evidence, and delete unnecessary raw data after documenting the results.

Key takeaways

• Packet captures can test local routing and leaks, not prove remote deletion or noncollection.
• Inspect physical and tunnel viewpoints, both IP families, and connection transitions before drawing conclusions.
• Use regex on sanitized text for organization; Wireshark filters and protocol analysis answer different questions.
• Evaluate policies and independent audits separately, and describe findings within the limits of the evidence.