Most security professionals understand conceptually how a VPN works, but the specifics matter when you’re evaluating whether a VPN fits a particular threat model. They also matter when you’re debugging a leak or advising someone on protocol selection. This guide covers the technical mechanics from packet handling to key exchange, the failure modes you need to know about, and where VPN architecture is heading in enterprise environments.
How a VPN Works: The Packet Flow
When a VPN client is active, it inserts itself into the network stack below the application layer. Every outgoing packet gets intercepted before it leaves your device. The client encrypts the original packet and encapsulates it inside a new packet. That outer packet’s destination is the VPN server’s IP address. So to everything on the path between you and the server, the traffic looks like an ordinary encrypted stream to one endpoint.
At the VPN server, the process reverses. The outer packet is stripped, the payload is decrypted, and the original packet is forwarded to its real destination. Return traffic follows the same path in reverse: the destination server responds to the VPN server’s IP, which encrypts the response and sends it back down the tunnel to your client.
Because of this, requests appear to originate from the VPN server’s IP address when viewed from the sites you visit. From your ISP’s perspective, all your traffic is an encrypted stream to one IP. Neither party sees the full picture, which is the point.
Protocol Comparison: WireGuard, OpenVPN, and IKEv2
Protocol choice affects security, performance, and deployment flexibility. Here’s what each one actually does differently.
WireGuard
WireGuard integrates directly into the Linux kernel (or runs as a user-space implementation on other platforms) and uses a fixed, non-negotiable cipher suite. Data encryption uses ChaCha20; message authentication uses Poly1305; key exchange uses Curve25519 elliptic-curve Diffie-Hellman. There are no configuration options for these, so you can’t accidentally choose a weak cipher.
The Curve25519 key exchange provides perfect forward secrecy. Each session generates a new ephemeral key pair. The session key is derived from both the long-term static keys and the ephemeral keys. So even if a long-term private key is later compromised, past session traffic can’t be decrypted.
WireGuard’s codebase is roughly 4,000 lines, compared to tens of thousands for OpenVPN or the full IPsec implementation. That matters for security. More code means more attack surface and more effort required to audit. WireGuard deliberately restricts its feature set to keep the codebase small and reviewable.
Performance is strong, particularly on mobile devices. ChaCha20 runs fast in software on processors without AES hardware acceleration, which covers most ARM-based smartphones. Connection establishment takes under a second, which matters when a protocol frequently reconnects as network conditions change.
OpenVPN
OpenVPN operates in user space using the TUN/TAP virtual network interface. It uses TLS for the control channel and a configurable cipher suite for the data channel. With AES-256-GCM and a proper TLS setup (TLS 1.3, strong cipher suites, certificate pinning), OpenVPN is secure. However, the risk lies in the configuration surface: older setups may still negotiate weak cipher suites, and some commercial VPN providers have shipped clients with suboptimal configurations.
OpenVPN’s main advantage is firewall traversal. It can operate over TCP port 443, making it hard to distinguish from HTTPS traffic to most deep packet inspection systems. Where WireGuard’s UDP traffic gets identified and blocked, OpenVPN on TCP/443 typically passes through. For users in environments with aggressive VPN blocking, that’s decisive.
The downside is overhead. User-space operation and TLS handshake add latency. Connection establishment typically takes two to four seconds, compared to under a second for WireGuard.
IKEv2/IPsec
IKEv2 negotiates and manages the tunnel; IPsec handles the actual packet encryption. The combination is native to most operating systems and is the default on Apple platforms. IKEv2’s MOBIKE extension lets the VPN session persist across network changes without a full re-handshake. If you switch from Wi-Fi to mobile data, the tunnel migrates automatically. For mobile workers, this is a clear win.
IPsec with AES-256-GCM and SHA-256 for integrity is cryptographically sound. Performance overhead is roughly 10-15% of native bandwidth. But the main operational concern is that IPsec uses specific ports and protocols (UDP 500, UDP 4500, ESP protocol 50) that some firewalls block. Unlike OpenVPN, there’s no good way to disguise it as HTTPS traffic.
Encryption: What the Algorithms Actually Do
AES-256-GCM is an authenticated encryption scheme. AES-256 provides confidentiality by encrypting the data; GCM provides authentication by detecting tampering. Without authentication, a passive eavesdropper could modify packets without detection. Authenticated encryption closes that gap.
ChaCha20-Poly1305 provides the same guarantees by different means. ChaCha20 is a stream cipher; Poly1305 is a message authentication code. Together they form an authenticated encryption scheme like AES-GCM, but with a software performance advantage on devices without AES-NI hardware.
Perfect forward secrecy (PFS) means session keys are derived from ephemeral material discarded after the session ends. If an attacker records encrypted traffic now and later obtains your long-term private keys, PFS defeats that plan: without the ephemeral key material, past sessions can’t be decrypted.
Common Leak Vectors
A VPN that leaks is worse than no VPN in one important respect: it creates false confidence. Here are the three vectors that most frequently cause real-world leaks.
DNS Leaks
DNS queries need to go through the tunnel to the VPN provider’s resolver. If the client fails to update system DNS settings, or if the OS has hardcoded fallback resolvers, those requests bypass the tunnel. They go directly to your ISP’s resolver instead. Your ISP can then see every hostname you resolve, even if it can’t see the encrypted traffic that follows. Testing is simple: check dnsleaktest.com and verify that only the VPN provider’s resolvers appear.
WebRTC Leaks
WebRTC uses STUN servers to discover IP addresses for peer-to-peer connections. STUN requests are sent via UDP directly from the browser’s network stack, bypassing any VPN or proxy configuration set at the OS level. A browser can expose your real IP address to any website that initiates a WebRTC connection, even while a VPN is active. The fix depends on the browser: Firefox has a setting to disable non-proxied UDP; Chromium-based browsers require a flag or extension. VPN clients that implement a network-level kill switch capture all interfaces and prevent this, but not all do.
IPv6 Leaks
Many VPN clients only tunnel IPv4 traffic. If your device has an IPv6 address and makes an IPv6 request, that traffic exits the normal network interface rather than the VPN tunnel. IPv6 addresses are globally unique and tied to your ISP account, so they’re more identifying than a leaked IPv4 address. The fix is either to tunnel IPv6 through the VPN or to disable IPv6 on the system while the VPN is active. Check by verifying that your visible IPv6 address matches the VPN server’s, not your ISP-assigned one.
Kill Switches: How They Work and Where They Fall Short
A kill switch blocks all non-VPN traffic when the tunnel drops. The implementation is usually a set of firewall rules allowing traffic only through the VPN network interface. If that interface disappears, the rules block everything else until the tunnel re-establishes.
The limitation is a timing window. Between the moment the tunnel drops and the moment the firewall rules engage, there’s a brief period where unprotected traffic can escape. Research from late 2025 found this gap in multiple commercial VPN clients. For most use cases, including avoiding ISP tracking and bypassing geographic restrictions, the window is too brief to matter. For high-risk use cases, it’s worth knowing about and choosing a client that implements the firewall rules persistently rather than reactively.
No-Log Policies and What Verification Looks Like
A no-log policy is a commitment not to store browsing history, IP addresses, connection timestamps, or DNS queries. The strongest implementations back this with RAM-only server infrastructure. Because data is never written to disk, a server seizure yields nothing. Complying with a data retention order would require a fundamental redesign of the infrastructure.
Verification requires more than reading a privacy policy. Independent audits by security firms, published with enough technical detail to assess the methodology, are the closest thing to useful verification. Jurisdiction also matters: providers incorporated in countries without mandatory data retention laws (Panama, British Virgin Islands) face fewer legal constraints on their no-log commitments than providers in EU member states or the US, where courts can compel prospective logging under secret orders.
Recent Vulnerabilities in VPN Products
The track record for VPN appliances is poor. Ivanti Connect Secure (CVE-2025-22457, CVSS 9.8) was exploited by UNC5221 before a patch was widely deployed, with approximately 5,000 exposed appliances at disclosure. Cisco ASA/FTD saw zero-day exploitation attributed to suspected Chinese state actors in 2025. Then Check Point’s IKEv1 authentication bypass (documented by watchTowr Labs as the “marking your own homework” flaw) allowed unauthenticated attackers to establish VPN sessions without valid credentials.
The exploitation trend is significant. According to Zscaler’s ThreatLabz research, exploitation of perimeter devices including VPNs increased 34% year-over-year in the Verizon 2025 Data Breach Report, with edge device breaches growing roughly 8x as a category. The attack model is consistent: compromise the VPN appliance, which sits on the perimeter with broad access to internal systems, then use it as a pivot point.
This is the practical argument for Zero Trust Network Access. ZTNA grants per-application access authenticated at each connection, rather than handing an authenticated user broad network access once the tunnel is up. Gartner projected that 70% of new enterprise remote-access deployments would choose ZTNA over traditional VPN by 2025. Whether that projection materialised, the architectural direction is sound. For a deeper look at the ransomware campaigns driving this trend, see how ransomware actually works.
What VPNs Don’t Protect Against
Privacy is not anonymity. A VPN hides your IP address and encrypts your traffic to the tunnel endpoint. But it does not prevent browser fingerprinting, cookie tracking, logged-in account identification, or timing correlation attacks. You can use a VPN and still be trivially identified by a site you’ve visited before.
Encryption is not security against malicious content. A VPN encrypts the connection but doesn’t inspect what flows through it. So malware, phishing pages, and drive-by exploits arrive the same way on a VPN as off one.
A VPN does not protect against the VPN provider. The provider decrypts your traffic at the tunnel endpoint. A provider that logs or sells data can expose your activity. Shifting trust to the provider is the core trade-off, and it’s only worth making if you trust the provider more than your ISP.
FAQ
Does a VPN protect traffic on public Wi-Fi?
Yes, substantially. Your traffic is encrypted before it leaves your device, so passive eavesdropping on the Wi-Fi network gets nothing useful. An attacker who controls the access point and performs a man-in-the-middle attack faces a much harder problem. Combine with verified HTTPS for defense in depth.
Can a VPN be detected?
WireGuard (UDP) and IKEv2 (specific ports and protocols) can be identified by deep packet inspection. OpenVPN on TCP/443 is harder to distinguish from HTTPS. VPN-blocking systems used by streaming services typically operate on IP-based blocklists of known VPN server addresses rather than protocol fingerprinting.
Self-hosted versus commercial VPN: which is better for privacy?
A self-hosted VPN on a cloud server shifts trust from a VPN provider to a cloud provider. You control the software and logs, but your real IP is associated with the cloud account. For privacy from your ISP, it works. For privacy from a motivated adversary who can compel cloud providers, it’s not obviously better than a reputable commercial VPN with verified no-log infrastructure.
Is WireGuard safe?
The cryptographic design is considered sound. WireGuard by default assigns a static IP to each client, which means the server logs could correlate connection timestamps to identities. Commercial VPN providers running WireGuard typically implement this differently. For raw protocol security, WireGuard is the current best option; for privacy properties, implementation matters.
