Internet-wide scanning counted 9.8 million VPN servers running OpenVPN, SSTP, PPTP, and IPsec around the world. Each of those machines is the far end of somebody’s encrypted tunnel, and the exact point where that encryption stops and ordinary routing takes over. The answer to how do VPNs work in practice sits at that termination point rather than in the cipher suite on the box, and almost every privacy question a reader has resolves there.
What follows traces how VPNs work on a single packet, from encapsulation through encryption to delivery. The mechanism below comes from NIST, the Internet Engineering Task Force, and the WireGuard design paper rather than from vendor copy.
Key Takeaways
- Internet-wide active measurement counted 9.8 million VPN servers using OpenVPN, SSTP, PPTP, and IPsec, spread across the global internet.
- SSTP fared worst in that scan, with more than 90% of detected servers vulnerable to TLS downgrade attacks.
- WireGuard ships a full tunnel in less than 4,000 lines of code for Linux, built on Curve25519 keys and ChaCha20Poly1305 encryption.
- Browser fingerprints in the Panopticlick study carried at least 18.1 bits of entropy, so only one in 286,777 browsers was expected to share a fingerprint.
- Academic analysis of Android VPN apps found 18% implemented tunneling protocols without encryption, despite advertising privacy.
- In the same app sample, approximately 84% did not tunnel IPv6 traffic and 66% did not tunnel DNS traffic through the tunnel interface.
- VPN traffic accounted for 2.6% of all traffic at a large European ISP in the researchers’ flow analysis.
How Do VPNs Work at the Packet Level?
NIST’s Guide to IPsec VPNs sets out the sequence precisely. In tunnel mode, a new packet is constructed containing the original IP packet by placing an ESP header and trailer around the original IP header and its payload, encrypting the original header, payload, and ESP trailer, computing an integrity check value, and adding a new IP header to the beginning.
Read that order carefully, because it explains why a VPN behaves the way it does. Encapsulation happens first: your real packet, destination address and all, becomes cargo inside a second packet. Encryption then closes over the cargo, leaving the new outer header readable so the network can still route it.
The integrity check value computation does not include the new IP header. Anyone watching the wire therefore sees a packet addressed to a VPN server, of a certain size, at a certain moment, and nothing about the request folded inside it.
Encapsulation is not encryption: Encapsulation puts one packet inside another so it can be routed somewhere it could not otherwise go. Encryption makes the inner packet unreadable. A tunnel that encapsulates without encrypting still moves your traffic, and still exposes every byte of it to anyone on the path.
WireGuard reaches the same outcome with a different envelope. Its design paper describes ChaCha20Poly1305 authenticated-encryption for encapsulation of packets in UDP, so WireGuard sessions look like generic UDP flows from the outside. The same paper puts the whole Linux implementation at less than 4,000 lines of code.
Where the Tunnel Ends, and Why That Decides Everything
NIST calls it remote access, or host-to-gateway: an architecture that protects communications between one or more individual hosts and a specific network belonging to an organization. The usual purpose is letting hosts on unsecured networks reach internal services. That phrasing contains the whole story, because protection runs between two named points and stops there.
Everything past the exit point travels as it would have anyway. A VPN moves the boundary of who can observe you; it does not extend encryption across the whole path to a website. The operator running the exit node occupies the position your home internet provider occupied a moment earlier, with the same view of where your traffic is headed.
That is a genuine change and sometimes a valuable one. A traveler on a hotel network swaps an unknown local operator for a chosen one, and a remote employee reaches an internal service that is not exposed to the public internet at all.
Both gains are real, and both are gains about who watches rather than whether anyone does. The reachability case is where the remote work security data concentrates, and it is the use case an organization can actually verify.
VPN Protocols Compared: IPsec, OpenVPN, and WireGuard
Three protocol families carry most VPN traffic, and the published specifications differ more than the marketing does. WireGuard’s paper claims a single round trip key exchange, based on NoiseIK and short pre-shared static keys, Curve25519 points, used for mutual authentication in the style of OpenSSH, a much narrower design surface than IPsec’s negotiated suites.
| Protocol | What the cited specification or study establishes |
|---|---|
| IPsec ESP, tunnel mode | Builds a new packet: ESP header and trailer around the original IP header and payload, original header and payload encrypted, integrity check value computed, new outer IP header added |
| WireGuard | Layer 3 tunnel using Curve25519 static keys and ChaCha20Poly1305 authenticated encryption over UDP, implemented for Linux in less than 4,000 lines of code |
| SSTP | Most vulnerable protocol in the 2023 Internet-wide scan, with more than 90% of detected servers vulnerable to TLS downgrade attacks |
| TLS 1.3, used by TLS-based VPNs and by ordinary HTTPS | All handshake messages after the ServerHello encrypted, and all public-key key exchange mechanisms provide forward secrecy |
Sources: NIST SP 800-77 Revision 1 (2020), WireGuard whitepaper (2020), PAM 2023 measurement study, RFC 8446 (2018)
The WireGuard paper also claims strong perfect forward secrecy in addition to a high degree of identity hiding, and treats code size as a security property rather than a convenience: a smaller implementation is a smaller thing to audit.
By the numbers: The 2023 Passive and Active Measurement study scanned the internet for VPN endpoints and found 9.8 million servers running four protocol families. SSTP was the most vulnerable protocol, with more than 90% of detected servers vulnerable to TLS downgrade attacks, which places protocol choice ahead of provider branding.
Which VPN protocol is the most secure?
No specification carries a security guarantee, and the honest answer is comparative. Measurement data puts SSTP last of the families scanned, on the TLS downgrade exposure recorded above. WireGuard’s small audited codebase and mandatory forward secrecy leave a smaller implementation to audit than IPsec’s negotiated cipher suites.
What a VPN Hides From Whom
The Internet Engineering Task Force records that TLS 1.3 encrypts most of the handshake, including the server certificate, so a VPN adds a second wrapper around traffic that is usually encrypted already. The specification also requires that all handshake messages after the ServerHello are now encrypted.
What the outer tunnel genuinely removes is the local observer’s view. Your home or hotel network sees one encrypted flow to one address, with the inner destination sealed inside it. The destination website, meanwhile, sees a connection arriving from the VPN server’s address rather than yours.
The substitution is the whole product. A VPN does not delete a record of your browsing; it relocates that record from one operator’s logs to another’s, and lets you pick which operator. Whether that trade favors you depends entirely on which of the two you would rather trust, which is a judgment about business models and jurisdiction rather than about cryptography.
Does a VPN hide my browsing from my internet provider?
Your provider stops seeing which sites you request and sees an encrypted flow to the VPN endpoint instead. The requests themselves do not disappear. They surface at the VPN server, whose operator can observe the same destination information your provider previously could, subject to whatever logging policy that operator runs.
What a VPN Does Not Hide
A VPN does not hide the destination domain, the identity of any account you log into, or your browser fingerprint. The tunnel wraps the transport, and those three signals ride above it.
The IETF’s Encrypted Client Hello draft is blunt about the residue. It states that the plaintext Server Name Indication extension in ClientHello messages leaks the target domain for a given connection, and calls it perhaps the most sensitive information left unencrypted in TLS 1.3. A tunnel moves that disclosure from your local network to the VPN operator; it does not remove it.
Identity survives the tunnel intact as well. Logging into an account hands the site a name no network-layer wrapper can strip, and the browser itself carries a durable signature. The Panopticlick measurement found at least 18.1 bits of entropy in browser fingerprints, meaning only one in 286,777 other browsers was expected to share a fingerprint, with 94.2% of browsers with Flash or Java unique in the sample.
| Signal | Local network and ISP | VPN operator | Destination website |
|---|---|---|---|
| Destination domain | Hidden by the tunnel | Visible at the exit point | Visible by definition |
| Page contents over HTTPS | Hidden | Hidden by TLS | Visible |
| Your real IP address | Visible | Visible | Replaced by the exit address |
| Logged-in account identity | Hidden | Hidden by TLS | Visible |
| Browser fingerprint | Hidden | Hidden by TLS | Visible |
Source: RFC 8446 (2018), IETF Encrypted Client Hello draft (2025), Panopticlick browser-uniqueness study (2010)
Why it matters: The working group building Encrypted Client Hello designed it because TLS 1.3 encrypts most of the handshake, including the server certificate, while the domain name stays readable. Until that extension is universal, the destination of every connection remains legible to whoever carries it, VPN or no VPN.
Public Wi-Fi Is a Narrower Case Than the Marketing Suggests
Cafe Wi-Fi is the scenario every VPN advertisement uses, and the underlying threat has narrowed since TLS 1.3 arrived. RFC 8446 removed static RSA and Diffie-Hellman suites so that all public-key based key exchange mechanisms now provide forward secrecy, so a passive recorder on the same network cannot later unlock captured sessions by stealing a server key.
What a hostile local network can still do is watch metadata. It reads the domain in each ClientHello, times the requests, and sizes them. A tunnel removes that specific visibility, which is a defensible reason to use one on an untrusted network.
Broader cybersecurity attack data is dominated by credential theft and malware. The public Wi-Fi threat picture is more mixed than either the warnings or the reassurances suggest.
A tunnel is not a patch: An encrypted tunnel does nothing about malware, phishing pages, credential reuse, or an out-of-date browser. Treating a VPN as general-purpose protection on a hostile network overestimates what the tunnel does. Layered controls and current software still carry the load.
The VPN Itself Is Attack Surface
CISA and partner agencies issued a joint advisory on two remote access products. It warns that cyber threat actors are actively exploiting multiple previously identified vulnerabilities, CVE-2023-46805, CVE-2024-21887, and CVE-2024-21893, affecting Ivanti Connect Secure and Ivanti Policy Secure gateways. The gateway itself was the target.
The detail that should unsettle any administrator sits one line further down. CISA determined that cyber threat actors are able to deceive Ivanti’s internal and external Integrity Checker Tool, resulting in a failure to detect compromise. A gateway can report itself healthy while an intruder holds it.
Scale compounds the problem. The advisory notes that the vulnerabilities impact all supported versions (9.x and 22.x) and can be used in a chain of exploits to enable malicious cyber threat actors to bypass authentication, craft malicious requests, and execute arbitrary commands with elevated privileges.
Edge appliances now appear as a standing feature of exploitation campaigns. The wider cybersecurity threat data has tracked that pattern across successive reporting periods.
Worth noting: The 2023 Internet-wide scan found that out of all the servers that respond to VPN probes, 2% also respond to HTTP probes and are therefore classified as Web servers. A VPN endpoint running a web stack on the same box widens what an attacker can reach from a single foothold.
Can a VPN be hacked?
Cryptography is rarely the weak point in how VPNs work in practice. Exploitation targets the software terminating the tunnel, which is why CISA’s advisory covers three chained gateway vulnerabilities rather than a broken cipher. Patch cadence on the appliance, and the operator’s own security practice, decide the outcome far more than the protocol does.
What Measurement Studies Found in Consumer VPN Apps
Researchers presenting at the 2016 ACM Internet Measurement Conference analyzed 283 Android VPN apps extracted from a population of 1.4 million Google Play apps, pairing static source-code analysis with active network tests. Their measured behavior diverged sharply from the privacy the apps advertised.
The headline gap is encryption itself. The study reported that 18% of the VPN apps implement tunneling protocols without encryption despite promising online anonymity and security to their users, even though 67% of the identified VPN Android apps offer services to enhance online privacy.
Leaks were more widespread than the missing encryption. The same tests found approximately 84% and 66% of the analyzed VPN apps do not tunnel IPv6 and DNS traffic through the tunnel interface respectively, due to lack of IPv6 support, misconfigurations or developer-induced errors.
Where the DNS queries actually went is its own finding. The researchers observed that 55% of the free apps and 60% of premium apps redirect the user’s DNS queries to Google DNS, whereas 7% of free and 10% of premium VPN apps forward DNS traffic to their own DNS resolvers.
Read together, those two measurements describe an app category where the privacy claim and the packet behavior were separate artifacts. The sample is a decade old and the market has consolidated since, so treat it as evidence that the failure mode exists rather than as a current rate.
Academic measurement work of this kind is periodic rather than continuous, so independent testing groups fill the gap between studies. The VPNpro.com VPN testing team is one such group publishing hands-on results across consumer providers.
Corporate VPNs and Consumer VPN Apps Solve Different Problems
How VPNs work inside a company differs from the consumer pitch, because a corporate VPN exists for reachability. NIST defines the remote access architecture as one that protects communications between one or more individual hosts and a specific network belonging to an organization, typically so traveling employees and telecommuters can reach internal services. Success there is measured by access control rather than by anonymity.
Smaller organizations carry the same gateway exposure with thinner patching capacity, a gap the small business breach statistics keep surfacing.
Consumer VPN apps are sold on a different promise, and the measured record above is uneven enough that the burden of diligence falls on the buyer. Longer-run VPN adoption and usage data shows the category growing regardless of that record.
The distinction matters when picking infrastructure too. Self-hosting a tunnel on a virtual private server removes the third-party operator from the trust chain, at the cost of running the endpoint yourself and becoming the single identifiable user of that address.
Does a VPN Make You Anonymous?
A VPN substitutes an IP address; it does not deliver anonymity. Logged-in accounts, browser fingerprints, and the destination domain visible in each ClientHello all survive the tunnel, and the Panopticlick study measured at least 18.1 bits of entropy in browser fingerprints alone.
Anonymity systems are built differently, layering multiple relays so no single operator sees both ends of a connection. A single-hop commercial tunnel has no such property. Fingerprint uniqueness also tracks how concentrated browser market share is, because a rare engine stands out against a thin crowd.
The honest framing is that a VPN changes which party holds the record of your browsing rather than whether such a record exists.
Is a VPN Still Worth Using on Public Wi-Fi?
The case is narrower than it was and still real. The IETF records that TLS 1.3 encrypts most of the handshake, including the server certificate, so page contents on HTTPS sites are already protected without a tunnel. What remains exposed to a hostile local network is metadata: the domain in each ClientHello, request timing, and request sizes.
A tunnel removes that metadata from the local network’s view and hands it to the VPN operator instead. Whether that helps depends on which of the two you have more reason to trust on that particular network.
Can Your Employer See Your Traffic on a Corporate VPN?
On a company-managed VPN, the employer operates the gateway where the tunnel terminates, so it holds the same visibility position any exit operator holds. Managed devices frequently add endpoint agents and certificate trust that extend visibility further, into traffic the tunnel alone would not expose.
Separating work and personal activity onto separate devices remains the only reliable way to keep them apart. No tunnel setting achieves that separation, because the issue is the ownership of the endpoints rather than the strength of the encryption between them.
Conclusion
Internet-wide scanning counted 9.8 million VPN servers, and the mechanism at each is the same: encapsulate the packet, encrypt the cargo, leave a routable outer header, then undo all of it at a machine somebody else operates. That last clause is where protocol choice and operator choice start to matter. SSTP’s record, with more than 90% of detected servers vulnerable to TLS downgrade attacks, shows how wide the spread between families runs.
The people best served by a tunnel are those with a specific, bounded problem: reaching an internal service from an untrusted network, or removing a hostile local operator’s view of which domains they request. Readers hoping a VPN will make them unidentifiable are buying the wrong tool, and the IETF’s work on Encrypted Client Hello suggests the residual metadata problem is being addressed at the protocol layer instead.
