VPN Encryption Explained: The Lock Isn't the Whole Door
“AES-256” sounds like the whole VPN. It isn't. Strong encryption can protect the wrong route, leave traffic outside the tunnel, or deliver everything to a provider you shouldn't trust. The number on the badge is one component, not the verdict.
Open a banking site on café Wi-Fi without a VPN. HTTPS encrypts the browser-to-bank connection, so the café operator normally can't read the password or page contents.
It can still observe connection metadata, and the bank sees the café's public IP alongside the account, browser, and anything you submit.
Now turn on a full-device VPN. The operating system feeds covered traffic into an encrypted tunnel to the VPN server.
The café sees that encrypted connection and its timing and volume. The VPN provider receives the traffic at the other end of the tunnel, and the bank sees the VPN server's IP.
The bank's HTTPS encryption remains inside the VPN tunnel. One protected connection is carrying another.
The Tunnel Starts With a Stranger Check
Before the app sends ordinary traffic, it needs to establish that it's talking to the intended VPN server. The client and server perform a handshake: they authenticate the connection, agree on cryptographic material, and derive temporary keys for the session.
That authentication step matters as much as scrambling the data. A perfectly encrypted conversation with an impostor is still going to the wrong party.
Certificate errors, bad configuration, an incorrect clock, or stale software can break the check; clicking past the warning removes the protection the warning was there to enforce.
Once the handshake succeeds, the app encrypts packets with session keys. The server verifies and decrypts them, then forwards the inner traffic. Return traffic follows the process in reverse.
Modern designs rotate or replace those keys. Forward secrecy is the property that keeps a later theft of long-term credentials from automatically unlocking recordings of earlier sessions. It doesn't rescue a device that's compromised while the session is live, and the exact guarantee depends on the protocol and configuration.
Encryption Also Has to Detect Tampering
Confidentiality means an observer can't read the protected data. Integrity means an attacker can't alter it unnoticed. Authentication ties the exchange to the expected peer. A serious tunnel needs these properties to work together.
That's why “encrypted” by itself is too vague. Old or badly configured systems may encrypt without strong integrity, reuse keys incorrectly, or accept a server they haven't authenticated. The ciphertext may look unreadable while the connection is still unsafe.
The useful question is concrete: which maintained protocol and cryptographic suite protect this connection, how are peers authenticated, and what happens when verification fails?
256 Is a Key Size, Not a Product Rating
AES is a standardized block cipher. The current NIST standard defines AES with 128-, 192-, and 256-bit keys. Those numbers describe allowed key lengths inside that algorithm; they don't let you rank unrelated ciphers like phone cameras by megapixels.
AES-256 can be an excellent component. So can a well-used 128-bit construction or WireGuard's ChaCha20-Poly1305.
Implementation, key generation, authenticated-encryption mode, protocol design, and endpoint security matter more than choosing whichever marketing page prints the largest number.
The word “encryption” also covers different boundaries. A VPN protects data moving between a tunnel endpoint and a VPN server. An encrypted drive protects stored files when the drive is locked. Neither boundary replaces the other.
- Uses 256-bit hardware encryption to protect the 16GB drive independently of cloud storage
- Supports password or passphrase access plus safeguards against repeated guessing and altered USB firmware
- Offers read-only settings when you want to open files without allowing changes to the drive
If someone steals an unlocked laptop, a VPN tunnel won't re-encrypt the files sitting on its disk. If malware reads a document before the VPN app packages it, the tunnel can faithfully encrypt stolen data on its way to the attacker. Encryption protects a path or state; it doesn't clean the endpoints.
Protocol Names Tell You the Rules, Not the Result
A VPN protocol defines how the peers authenticate, exchange keys, package packets, maintain state, and recover when the network changes. WireGuard, OpenVPN, and IKEv2/IPsec can all form serious tunnels, but they make different design choices.
WireGuard uses a deliberately fixed modern suite. Its protocol description names ChaCha20-Poly1305 for authenticated encryption, Curve25519 for key agreement, and regular handshakes that rotate session keys. A smaller choice set reduces configuration ambiguity; the VPN service still has to build account assignment, routing, privacy, and failure handling around it.
OpenVPN is more configurable. It uses TLS for its control channel and can operate over UDP or TCP, with negotiated data-channel ciphers in current deployments. Flexibility helps it fit many systems and restrictive networks, but it also makes current defaults and server configuration important. The OpenVPN 2.6 manual is a better source than a provider badge that only says “OpenVPN supported.”
IKEv2 negotiates IPsec security associations and often handles transitions between Wi-Fi and cellular well. IPsec's ESP can provide confidentiality, integrity, origin authentication, and replay protection; the chosen algorithms and policy determine the actual result.
Don't pick a VPN solely because one protocol wins a synthetic speed test. Start with a maintained modern default, then switch only to solve a real compatibility or stability problem. Our VPN protocol guide compares the operational tradeoffs without turning names into medals.
The Outer Lock Opens at the VPN Server
VPN encryption doesn't run from your laptop to every destination on the internet. It ends at the VPN server because that server must remove the tunnel layer and forward the inner packet.
Return to the banking scene. The café sees the outer VPN connection but can't read its protected contents. The VPN service sees Ana connect and can observe whatever metadata its position and system expose. It forwards the inner HTTPS session. The bank terminates HTTPS, reads the request it must serve, and sees the VPN exit IP.
Without the VPN, the café and internet provider observe the direct bank connection, while HTTPS protects its contents; the bank sees the café IP. With the VPN, local observers lose the direct destination, the VPN becomes the intermediary, and the bank sees the VPN IP. The account still tells the bank who Ana is in both cases.
A router can become the first tunnel endpoint for devices behind it. That widens coverage, but it also means the traffic is unprotected by that VPN between a device and the router unless the local link has its own protection. It can also hide per-device app status, so the router's kill switch and policy deserve an actual failure test.
- Sits on a wired network as a dedicated gateway for OpenVPN or WireGuard traffic
- Can run VPN client and server roles together for remote access and protected outbound browsing
- Has no Wi-Fi radio, making it best for pairing with an existing router or access point
Hardware throughput claims aren't tunnel guarantees. Protocol choice, server distance, processor load, internet service, and firmware can all change the result. Update a gateway, confirm provider compatibility, and test which devices really use its route before treating one box as network-wide protection.
Strong Math Can't Reach Traffic That Escapes
Split tunneling deliberately sends selected traffic outside the VPN. Misconfigured DNS, IPv6, browser, or app routes may do it accidentally. Either way, the cipher inside the tunnel can't protect a packet that never enters it.
An exclusion should be visible and narrow. If the banking app bypasses the VPN, the local network again sees its direct connection and the bank sees the normal public IP; covered apps still use the encrypted VPN path. That's a routing choice, not weaker encryption.
A kill switch handles a different failure. When the tunnel drops, it blocks traffic instead of allowing the operating system to fall back to the ordinary route.
Test it during connection, sleep, network changes, and app crashes. Then run IP and DNS leak checks after major VPN or operating-system updates.
The IETF has documented how VPN traffic can escape through legitimate configurations and attacks in RFC 7359. “Connected” is a status to verify, not a lifetime promise.
The Cipher Can't Write the Privacy Policy
Once traffic reaches the VPN server, company behavior matters. The provider may be able to record account, connection, device, timing, volume, and destination information even when the local tunnel is cryptographically sound. What it actually keeps depends on the system and policy.
Read the logging policy, identify the legal company, and inspect current independent evidence. An audit can test a named scope at a moment in time. It can't guarantee future configurations or turn an unrelated app assessment into proof about VPN servers.
Before relying on a VPN, check four things:
- a maintained app and established protocol;
- server authentication that fails closed;
- a kill switch and leak behavior you've tested;
- a provider whose data practices and evidence match your risk.
“Military-grade encryption” answers none of those questions. Once the tunnel's cryptography is competently implemented, the more interesting failures happen around it: the wrong route, a leaking app, a compromised endpoint, a careless provider, or a user who mistakes an encrypted connection for anonymity.
The lock matters. First make sure it's on the right door.