Every developer I know has a VPN. Most of them have it running while they're logged into Google, sending data through Chrome, and using apps that do their own certificate pinning — which means the VPN is protecting approximately nothing meaningful in that moment.
This isn't a knock on VPNs. It's a scoping problem. Here's what the tool actually covers, what leaks around it, and how to test it properly.
What's Actually Happening at the Network Layer
A VPN operates at Layer 3 (Network) of the OSI model. It creates an encrypted tunnel — typically using WireGuard, OpenVPN, or IKEv2/IPSec — between your device and a VPN server. All IP traffic gets routed through that tunnel.
Protocol comparison:
| Protocol | Speed | Security | Port | Notes |
|---|---|---|---|---|
| WireGuard | ⭐⭐⭐ Fast | ⭐⭐⭐ Strong | UDP 51820 | Modern, audited, ~4000 lines of code |
| OpenVPN | ⭐⭐ Medium | ⭐⭐⭐ Strong | TCP 443 / UDP 1194 | Battle-tested, ~100k lines |
| IKEv2/IPSec | ⭐⭐⭐ Fast | ⭐⭐ Good | UDP 500/4500 | Native on mobile, good reconnect |
| L2TP/IPSec | ⭐ Slow | ⭐ Weak | UDP 1701 | Avoid — potentially compromised |
WireGuard is the correct choice in 2026 unless you have a specific reason not to use it. Smaller codebase = smaller attack surface. Most audited VPN providers now use it by default.
What Leaks Around the Tunnel
The VPN handles IP routing. It doesn't handle everything else.
DNS leaks are the most common issue. If your system's DNS resolver isn't explicitly routed through the tunnel, your DNS queries go directly to your ISP — revealing every domain you visit even with the VPN active.
Test this from the terminal:
# Check your current DNS resolver
cat /etc/resolv.conf
# Test for DNS leak (run while VPN is active)
# Should show your VPN provider's DNS, not your ISP's
nslookup whoami.akamai.net
# More thorough test
dig +short myip.opendns.com @resolver1.opendns.com
Most reputable VPN clients handle DNS routing automatically, but worth verifying — especially on Linux where DNS management is fragmented across systemd-resolved, dnsmasq, and NetworkManager depending on your distro.
WebRTC leaks expose your real IP through browser APIs even when a VPN is active. This is a browser-layer problem, not a network-layer problem.
// WebRTC leak test — run in browser console while on VPN
// If this returns your real IP, you have a WebRTC leak
const pc = new RTCPeerConnection({
iceServers: [{ urls: 'stun:stun.l.google.com:19302' }]
});
pc.createDataChannel('');
pc.createOffer().then(offer => pc.setLocalDescription(offer));
pc.onicecandidate = (e) => {
if (e.candidate) {
const ip = e.candidate.candidate.match(/(\d+\.\d+\.\d+\.\d+)/);
if (ip) console.log('IP exposed via WebRTC:', ip[1]);
}
};
Fix: Firefox has media.peerconnection.enabled in about:config. Chrome requires an extension or a VPN client with WebRTC leak protection built in.
Application-layer tracking doesn't touch the network layer at all. If you're authenticated in your browser, that session follows you. Cookies, localStorage, IndexedDB — none of this is affected by routing your IP through Amsterdam.
The Kill Switch and Why It Matters
A kill switch blocks all traffic if the VPN connection drops. Without it, your traffic briefly reverts to your real IP when the tunnel reconnects. This is the correct default for any privacy-sensitive setup.
On Linux with ufw:
# Block all traffic by default
sudo ufw default deny outgoing
sudo ufw default deny incoming
# Allow only traffic through VPN interface (tun0 for OpenVPN, wg0 for WireGuard)
sudo ufw allow out on tun0
sudo ufw allow out on wg0
# Allow LAN traffic if needed
sudo ufw allow out on eth0 to 192.168.0.0/16
sudo ufw allow out on eth0 to 10.0.0.0/8
sudo ufw enable
WireGuard users can use PostUp/PreDown hooks in the config for a more integrated approach:
[Interface]
PrivateKey = <your_private_key>
Address = 10.x.x.x/32
DNS = 1.1.1.1
PostUp = iptables -I OUTPUT ! -o wg0 -m mark ! --mark $(wg show wg0 fwmark) -j REJECT
PreDown = iptables -D OUTPUT ! -o wg0 -m mark ! --mark $(wg show wg0 fwmark) -j REJECT
Split Tunneling: Route Only What You Need
Split tunneling lets you route specific traffic through the VPN while everything else goes directly. Useful when you need VPN for specific services but don't want to tunnel your local development traffic or internal network requests.
Most GUI clients support this natively. For WireGuard directly:
[Peer]
PublicKey = <server_public_key>
Endpoint = <server_ip>:51820
# Route only specific subnets through VPN instead of all traffic
AllowedIPs = 10.0.0.0/8, 172.16.0.0/12
# vs. route everything:
# AllowedIPs = 0.0.0.0/0, ::/0
What a VPN Actually Buys You (Honest Summary)
- ✅ Your ISP can't see which domains you visit
- ✅ Traffic encrypted against public WiFi eavesdropping
- ✅ Your IP hidden from destination servers
- ✅ DNS queries protected (if configured correctly)
- ❌ No protection against cookie/session tracking
- ❌ No protection against browser fingerprinting
- ❌ No protection while authenticated in any app or service
- ❌ No protection from the VPN provider themselves
The tool solves a specific set of network-layer problems. For application-layer privacy, you need application-layer solutions — content blocking, session isolation, fingerprint-resistant browsers.
If you're setting up a VPN for a team or personal setup and want the technical layer done properly: WireGuard, verified DNS routing, kill switch enabled, and DNS leak tested before you trust it. Everything else is marketing.
Consumer version — what this means for people who don't want to touch iptables: lucas8.com/what-vpn-actually-protects
SOCIAL SHARE CARD GENERATOR