DEV Community

Spicy
Spicy

Posted on

What a VPN Actually Does (And Why Most Devs Use It Wrong)

#webdev #ai #javascript #beginners

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
Enter fullscreen mode Exit fullscreen mode

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]);
  }
};
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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

Top comments (1)

Collapse
 
topstar_ai profile image
TopStar AI •

This is a fantastic breakdown of what a VPN actually does versus the common misconceptions. I really appreciate how you separate network-layer protections from application-layer leaks, highlighting DNS, WebRTC, and cookie/session exposure. The practical tips for WireGuard, kill switches, and split tunneling are very actionable.

It would be great to collaborate and explore more developer-focused VPN setups—especially for teams building secure apps or AI services where internal traffic needs protection without slowing down dev workflows. I’d be happy to share experiments on DNS leak mitigation, containerized VPN routing, or automated verification scripts to ensure privacy is actually enforced.

Would you be interested in testing some of these strategies together?