Network OPSEC checklist for engineers

Encryption protects content. It does nothing for metadata — and metadata is what de-anonymizes you. This is a working checklist for engineers operating their own networks.

DNS

• DNS leaks. Test at dnsleaktest.com. If you see your ISP's resolver, the tunnel isn't catching DNS queries. Fix in your VPN client, not your OS.
• DNS-over-HTTPS in the browser. Firefox and Chrome can route DNS to their own DoH endpoints that bypass the tunnel. Disable browser-level DoH if you're routing DNS through the VPN.
• DoH on the right resolver. Cloudflare 1.1.1.1, Quad9 9.9.9.9, or your own Unbound — never the ISP default.
• EDNS Client Subnet. Some resolvers leak your subnet to authoritative servers. Cloudflare and Quad9 don't.

IPv6

• Disable IPv6 if your tunnel doesn't carry it. Leaks are extremely common. On Linux: sysctl -w net.ipv6.conf.all.disable_ipv6=1.
• If your tunnel does carry v6 — set AllowedIPs = 0.0.0.0/0, ::/0 in WireGuard, or equivalent.
• SLAAC / RA leaks. Local IPv6 router advertisements can give your device a routable address even when v6 is "off." Block at the firewall.

Local network noise

• mDNS / Bonjour. Broadcasts your hostname and services to the local segment. On macOS, the only way to silence it short of disabling Bonjour is firewall rules. On Linux, stop avahi-daemon.
• NetBIOS / SMB. Ancient Windows broadcast protocol. Still leaks workgroup names and machine identifiers. Disable on the WAN-facing side.
• LLMNR / NBT-NS. Used by Windows for fallback name resolution; trivially poisonable. Disable via Group Policy or registry.
• WebRTC. Browsers leak local IPs via STUN. Test at browserleaks.com/webrtc. Disable in about:config (Firefox) or via uBlock Origin.

Application-level fingerprints

• TLS fingerprints (JA3, JA4). Your TLS client hello is unique enough to identify you across IPs. Different libraries (curl vs Chrome vs Go's net/http) have different fingerprints. Some censorship systems block on JA3.
• HTTP/2 fingerprints (Akamai's HTTP/2 fingerprint, similar). Frame ordering, settings values. Less common as a block vector but rising.
• User-Agent consistency. A user-agent claiming to be Chrome paired with a curl JA3 is an instant red flag.

Routing and metadata

• Default routes. ip route should show your tunnel as default. If a more specific route bypasses it, traffic leaks. Common with corporate VPN clients that "split tunnel" by default.
• Bind interfaces. For sensitive scripts/tools, bind explicitly to the tunnel interface (curl --interface wg0 ...). Don't trust the OS to do the right thing.
• Bypass routes. Many VPN clients exclude RFC 1918 ranges from the tunnel (so LAN works). Check what's excluded — if it's broader than 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, you have a leak surface.

Time

• NTP traffic. time.apple.com, pool.ntp.org queries leak before your tunnel comes up. Use a tunnel-internal NTP server or delay first sync.
• Clock drift. Wildly inaccurate clocks break TLS and identify your machine. Run chrony or systemd-timesyncd.

OS-level identifiers

• MAC address randomization. Modern OSes do this for Wi-Fi, but not Ethernet. On Linux: ip link set dev eth0 address <random>.
• Hostname. Don't set your real name as the hostname. mDNS, NetBIOS, and DHCP all advertise it.
• DHCP options. DHCP client identifier (option 61) and class identifier (option 60) can fingerprint the device. dhclient and systemd-networkd both honor config to override.

Audit it

Run the checklist top to bottom on a fresh tunnel session. If any of the leak-test sites show your real anything (IP, DNS, ASN, location), the tunnel isn't doing its job. Fix the leak before you do anything sensitive.

This list is intentionally incomplete — if you spot a meaningful gap, tell us and we'll add it.