Why We Run a Single Modern Protocol
Key points
- Our VPN protocol's core is about 4,000 lines of code, small enough for real audits and formal verification.
- It measures faster than older protocols: higher throughput, lower latency, and near instant connections.
- One fixed set of modern cryptography removes the misconfiguration risk of older configurable protocols.
- It connects reliably even on restrictive firewalls and a wide range of platforms.
On this page
- Why one protocol, not a menu
- Small code, smaller attack surface
- Speed you can measure
- Modern cryptography, no foot-guns
- What this means for you day to day
- How our protocol compares to older ones
- How we run it at vpn.now
- The honest downside of one protocol, and how we handle it
- Summary
- Frequently asked questions
Every vpn.now app runs a single modern VPN protocol. Most of our users never touch a protocol setting at all, which means this one choice shapes the security and speed of nearly every connection we carry. A decision with that much weight deserves a public explanation.
This post lays out why we run one well-built protocol instead of a long menu: the engineering reasons, the measured results, and the honest trade-offs. None of this is secret knowledge. Everything here can be checked against the protocol's public design and your own tests.
Why one protocol, not a menu
A VPN protocol is the set of rules a device and server use to build an encrypted tunnel. Older protocols accumulated decades of options and extensions. The protocol we run made a different bet: do one thing, with current cryptography, in as little code as possible. We follow the same philosophy at the product level by running that one protocol well rather than offering a pile of options most people would never understand.
That focus pays off. A single, modern protocol gives every user the same fast, well-studied tunnel, with no chance of landing on a weak legacy setting by accident. Fewer choices means fewer ways for a connection to go wrong.
Small code, smaller attack surface
The protocol we use has a core implemented in roughly four thousand lines of code. Older designs, together with the libraries they depend on, run into the hundreds of thousands. Code size is not a vanity metric. Every line is a place where a bug can hide, and security bugs in VPN software sit in the worst possible location, right in the path of all your traffic.
A codebase this small can be read in full by one auditor in days. That property has practical consequences: more eyes have meaningfully reviewed it, formal verification work has covered its core, and patches are easier to reason about. We consider this the strongest single argument for it.
Compare the histories. Large VPN and TLS codebases have produced serious vulnerabilities over the years, not because their authors were careless but because no human can hold hundreds of thousands of lines in their head. Shrinking the problem is the only fix that scales.
Speed you can measure
Our protocol runs inside the operating system kernel and uses the ChaCha20 cipher, which is fast even on hardware without dedicated encryption support. In our own testing across the network, the pattern is consistent: high throughput, low latency, and quick connection times, well ahead of older protocols on the same servers.
| Trait | The protocol we run | Older protocols |
|---|---|---|
| Core code size | About 4,000 lines | Hundreds of thousands with dependencies |
| Typical speed overhead | Low, often under ten percent | Moderate to high |
| Connection setup | Near instant | Several seconds |
| Network switching | Seamless roaming built in | Usually requires reconnect |
| Cryptography | Fixed modern set | Configurable, including old options |
Run the comparison yourself rather than taking our table on faith. Our VPN speed guide shows how to test fairly, with a baseline and repeated runs.
Tip: If you switch between Wi-Fi and mobile data a lot, the roaming is the feature you will feel most. The tunnel survives network changes without dropping, which means fewer reconnect gaps for a kill switch to catch.
Modern cryptography, no foot-guns
Older protocols let administrators choose among dozens of cipher and handshake combinations, including outdated ones kept for compatibility. Every choice is a chance to choose badly. The protocol we run removes the menu: one current, well-studied set of primitives, the same for everyone. If a weakness is ever found, the protocol version changes rather than offering a downgrade path. Fewer options means fewer misconfigurations, which in practice prevents more real-world failures than any exotic feature.
The specific choices are conservative and public: ChaCha20 for encryption, Poly1305 for authentication, Curve25519 for key exchange, BLAKE2s for hashing. None of these are novel or experimental. They are the primitives the cryptographic community has spent years studying, assembled with no room for a weaker fallback.
What this means for you day to day
Protocol talk gets abstract, so here is the concrete version. Your connection comes up in a blink instead of after several seconds of negotiation. Walking out of Wi-Fi range and onto mobile data does not drop your video call, because the tunnel follows you across networks. Your phone battery lasts longer, because the protocol does less work per packet and sits quiet when idle. And the speed cost of staying protected is small enough that most people stop thinking about it, which is the entire point.
How our protocol compares to older ones
Honesty requires the other side of the ledger. Older protocols like OpenVPN carry a two decade audit history that newer code cannot match by definition, and OpenVPN over TCP port 443 can slip past restrictive firewalls that block unfamiliar traffic. We weighed those trade-offs carefully before settling on a single modern protocol. You can see what we run on our protocols page, and our deeper comparison of our protocol against OpenVPN goes through the trade-offs case by case.
For the large majority of people, on the large majority of networks, the modern protocol is simply the better choice. We would rather build that one path well than spread our attention across several.
How we run it at vpn.now
A protocol is only as good as its deployment. On our side, every server in our network runs the protocol in the kernel for performance, key rotation is automated, and each user session is isolated with its own key pair. Address assignment is handled so that sessions are not written to persistent storage on the VPN servers. We described the principles behind these choices in our launch announcement: collect the minimum, document the practice, and let the design carry the burden instead of promises.
One operational detail worth calling out: this protocol's simplicity extends to monitoring and incident response. When a server misbehaves, a four thousand line protocol is something our engineers can actually reason about under pressure. Boring, debuggable infrastructure is a security feature that never appears on a comparison chart.
The honest downside of one protocol, and how we handle it
Running a single modern protocol has one real drawback worth naming out loud. The protocol we run sends its traffic over UDP, which is fast and lightweight. Most networks pass it without trouble. But a small number of strict networks, like some workplaces, schools, and hotels, block or interfere with that kind of traffic. On those rare networks, a plain connection may not establish. We would rather tell you that up front than pretend it never happens.
Here is how we deal with it, honestly. We work to help connections blend in over common ports, so the traffic looks ordinary and gets through more often. When a network is openly hostile, we point you to a simple workaround, like switching to a personal hotspot from your phone, which sidesteps the blocking network entirely. And if enough of our users start hitting walls that need more, we would add an option to address it, such as a TCP-based or obfuscated fallback that is harder for a network to spot.
We have not added that fallback yet because, for the large majority of networks, the single modern protocol simply works, and keeping one clean path is part of why it stays fast. Bolting on extra modes for edge cases would slow the common case for everyone. We watch real usage so the choice stays grounded in what people actually run into, not in fear.
Admitting a trade-off is part of being an honest VPN. No single design is perfect on every network, and any company that claims otherwise is selling you something. We picked the path that is faster and simpler for nearly everyone, and we are clear about the narrow case where it asks more of you.
Summary
We run a single modern protocol because the case for it is checkable, not because it is fashionable.
- A tiny codebase means a smaller attack surface and real, repeated review.
- Measured speed and instant connections beat older protocols on the same hardware.
- One modern cryptographic set removes misconfiguration risk.
- Focusing on one well-built path serves more people than a long menu of options.
- Deployment details matter as much as the protocol, and ours are documented.
