Your device (left) sends packets toward a destination server (right) through a VPN server in the middle. With the tunnel up, every packet is wrapped in an encrypted envelope addressed from the VPN server's IP, not yours — an eavesdropper watching the wire between you and the VPN server sees only opaque encrypted traffic; one watching between the VPN server and the destination sees the VPN server's IP as the source, never yours. Turn the tunnel off and packets travel in the clear, carrying your real IP and readable contents the whole way.
tunnel up: you --[encrypted, src=VPN_IP]--> VPN --[encrypted]--> destination
tunnel down: you --[plaintext, src=YOUR_IP]-----------------------> destination
DNS leak: you --[plaintext DNS, src=YOUR_IP]--> ISP resolver (bypasses tunnel)
- VPN on/off — toggles whether packets are wrapped and re-addressed, or sent as themselves.
- DNS-leak attack — even with the tunnel up, a misconfigured client can still send DNS lookups (which domain does "example.com" resolve to?) straight to your ISP's resolver outside the tunnel. Those small red packets skip the VPN server entirely and reveal your real IP plus every site you're about to visit, even though your actual traffic stays encrypted.
- Packet rate — how many packets per second are generated; a busier connection makes the leak vs. tunnel split easier to compare.
- Encryption strength — a cosmetic proxy for cipher/handshake overhead (e.g. WireGuard's modern ChaCha20 vs. an older IKEv2/AES-CBC setup); higher strength thickens and slows the encrypted envelope, showing the real compute cost of stronger crypto.
Real-world relevance: this is exactly why VPN clients ship a "DNS leak protection" setting — without it, split-tunneling or a misbehaving resolver config can silently defeat the privacy the tunnel was supposed to provide, even while the bulk of your traffic looks perfectly secure.