A modern, post-quantum-ready privacy VPN. Hybrid post-quantum key exchange on every connection. Strong defaults — kill switch, in-tunnel DNS, peer isolation — turned on out of the box.
A consumer VPN in 2026 is no longer a single product category. There are at least three things sold under the same word, and they require very different technical foundations.
Streaming-unlock VPNs exist primarily to put a non-domestic IP address in front of geo-blocked content. Their engineering investment goes into IP-rotation at scale, into avoiding streaming-service blocklists, and into peering with content-delivery networks. Their privacy properties are downstream of the streaming use case — useful, but not the design goal.
Corporate VPNs exist primarily to extend a company's internal network to remote employees. Their engineering investment goes into authentication, single-sign-on integration, access control, and audit logging. Their threat model is "the network is hostile, the user is trusted," which is the opposite of the threat model a privacy VPN operates against.
Privacy VPNs exist primarily to put a trusted operator between your device and the rest of the internet. Their engineering investment goes into the cryptographic protocol, the architecture of the data plane (so the operator structurally cannot see what you are doing even if they wanted to), the operational security of the infrastructure, and the transparency of how the operator funds itself. OllaVPN is in this third category.
The technical decisions on this page only make sense in the context of "we are a privacy VPN, full stop." The choices we make — WireGuard with a post-quantum hybrid extension, in-tunnel DNS, kill switch on by default and not toggleable, four-layer peer isolation, owned infrastructure on tier-1 baremetal — are correct for a privacy VPN and would be unnecessarily expensive for a streaming-unlock product. We accept that tradeoff because privacy is the product.
A modern privacy VPN in 2026 has six properties that older privacy VPNs did not: it ships post-quantum-ready cryptography by default (because "harvest now, decrypt later" is a working attack pattern, not a future hypothetical); it runs over WireGuard rather than OpenVPN or IPsec (because the smaller code surface is easier to audit and the performance is materially better); it operates the data plane on owned baremetal rather than commercial VPS (because the privacy promise depends on controlling the data path); it runs its own DNS resolvers inside the tunnel rather than handing DNS to OpenDNS or Cloudflare (because the resolver is part of the trust boundary); it ships its kill switch enforced at the OS firewall layer rather than as an in-app polling check (because the latter has races during transitions); and it makes the source of its client apps inspectable, so users do not have to take the operator's word for the implementation. OllaVPN ships all six. The rest of this page explains how each one works.
If either side of the hybrid holds up — classical or post-quantum — the session stays private. That's the point of "hybrid by default."
The seven-layer list above is the marketing summary. This is the technical version — what each line actually means at the protocol and code level.
Every OllaVPN handshake derives the session key from a hybrid combination of two independent key-agreement algorithms: classical X25519 (the elliptic-curve key exchange that WireGuard ships natively) and NIST-standardized ML-KEM-768 (the lattice-based key-encapsulation mechanism specified in FIPS 203, August 2024). The hybrid construction concatenates the two shared secrets and feeds them through HKDF to produce the session key. If X25519 is broken — for example, by a sufficiently powerful quantum computer running Shor's algorithm on the discrete-logarithm problem — ML-KEM-768 still protects the session. If ML-KEM-768 is broken by some future cryptanalysis of structured lattices, X25519 still protects. The construction is belt-and-braces, not all-eggs-in-one-basket.
The implementation uses the reference NIST ML-KEM-768 code, formally verified components where available, and is part of the open OllaVPN client. We have not invented our own cryptography; we have integrated standardized building blocks into the WireGuard handshake using the IETF-discussed "hybrid PQ-WireGuard" approach.
WireGuard's transport keys rotate periodically — by default, every two minutes or every 60 GB of traffic, whichever comes first. Each rotation derives a new session key from the long-term identity keys plus fresh ephemeral material. A passive adversary who captures today's ciphertext and steals a long-term identity key tomorrow still cannot decrypt the captured traffic, because the session key was derived from material that no longer exists.
The forward-secrecy property compounds with the post-quantum hybrid: a future quantum attacker not only has to break ML-KEM-768 plus X25519 plus get a long-term identity key, they have to break every two-minute key rotation in the captured session. The cost-to-attacker curve gets steep fast.
The kill switch is enforced at the operating-system firewall layer, not as an in-app polling check that periodically tests "is the tunnel still up?". The implementation differs per platform: on Windows it is Windows Filtering Platform rules installed by the OllaVPN system service; on macOS it is Packet Filter rules installed by a root daemon; on Android it is the VpnService class's setBlockingMode + setUnderlyingNetworks(null) pattern that tells the OS "block everything that isn't the VPN." All three implementations have the same property: if the OllaVPN app crashes, the rules stay in place until something explicitly tears them down. The window during which packets could leak does not exist.
There is no settings toggle to disable the kill switch. We treat that as a feature, not a missing feature. A kill switch that the user can accidentally turn off is, in practice, a kill switch that does not exist for the user who needed it most.
Every exit server runs its own unbound DNS resolver bound to an address inside the in-tunnel RFC 6598 CGNAT range (typically 100.64.0.1). At connect time, the OllaVPN client app installs that resolver as the system's highest-priority DNS source: on Windows via the NRPT (Name Resolution Policy Table), on macOS via scutil-installed supplemental keys, on Android by the VpnService's DNS configuration. The OS default resolver is also blocked at the firewall layer: any DNS packet bound for an address that is not the in-tunnel resolver is dropped. Even if a misbehaving app deliberately tries to bypass the system resolver and hit 8.8.8.8 directly, the firewall stops the packet.
The in-tunnel resolver itself runs with qname-minimisation enabled, with log-queries: no and log-replies: no, with no per-query persistence, and with IPv6 disabled. Upstream queries (from the resolver to the public root and TLD servers) use DNS-over-TLS to Cloudflare's 1.1.1.1 and Quad9's 9.9.9.9 — not because we trust them with the metadata, but because the upstream-from-the-resolver step is unavoidable and DoT is the strongest available transport.
On every OllaVPN exit, traffic between two connected peers is blocked in four independent layers. The first layer is WireGuard's own AllowedIPs restriction: each peer's AllowedIPs is set to its own /32, so the WireGuard packet processor will not even attempt to forward a packet from peer A toward peer B. The second layer is an nftables rule on the exit's wg0 interface (iifname wg0 oifname wg0 drop) that drops any packet that does manage to enter the WG processor but is not destined for the wider internet. The third layer is a sysctl tweak that disables forwarding on the wg0 interface entirely. The fourth layer is an automated end-to-end test — tools/e2e/peer-isolation/ — that runs before every release and refuses to ship a build that violates the property.
No single layer is the load-bearing one. The defense in depth means a bug in any one layer leaves the property intact via the other three. The test in particular means we catch regressions in the configuration of the deployed exits, not just in the code.
RFC 1918 private network ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) are excluded from the tunnel's default route. Your home network keeps working: the printer, the NAS, the smart-home gear, the local development server all remain reachable while you are connected. The tunnel addressing uses RFC 6598 CGNAT space (100.64.0.0/10) specifically because that range does not collide with consumer home LANs — so the LAN-access exclusion logic can be simple and never accidentally excludes our own in-tunnel resolver.
Every OllaVPN exit server runs on baremetal hardware in a tier-1 colocation facility, operated by us, not on a commercial VPS resold by a third party. The reason is direct: the privacy promise depends on controlling the data path. A commercial VPS provider can image the running VM, snapshot the disk, or be subpoenaed for hypervisor-level logs that the VPN operator has no visibility into. Owning the metal removes that class of risk.
The control plane that authenticates users and assigns peer slots runs on its own dedicated machine, completely separate from any exit. It has no public IP — it is reachable only via a Cloudflare Tunnel that terminates TLS at the CF edge and forwards requests to a local Caddy reverse proxy. The control plane's database stores account email + password hash + current peer-slot assignment + abuse-report records. It does not store connection history, source or destination IPs, DNS queries, or any per-packet metadata. The data simply does not exist to log because the architecture does not collect it.
Standard single-hop VPNs reduce your attacker surface to one trusted operator. Multi-hop reduces it further by ensuring no single operator can link your real IP to your destinations. Sovereign Route is OllaVPN's multi-hop implementation, with post-quantum encryption on both legs.
A standard single-hop tunnel works like this: your traffic leaves your device, enters the VPN tunnel, exits at one of our exit servers, and goes to the destination. The exit operator sees the destination but does not see who you are (we do not log). Your ISP sees that you are using a VPN but cannot see the destination. So far, so good — but the exit operator could, in principle, be coerced or compromised to log who they are seeing.
Sovereign Route adds a second hop. Your traffic still leaves your device and enters a tunnel — but the first tunnel terminates at a Swiss entry-hop server, and inside that tunnel is a second tunnel that terminates at the exit country of your choice. The entry-hop sees your IP but not the destination (because the inner tunnel is still encrypted to the exit). The exit sees the destination but not your IP (because the inner tunnel was opened from the entry-hop's IP, not yours). Linking the two ends requires colluding both operators simultaneously, or a passive observer watching both legs at once.
Both legs of the cascade run OllaVPN's PQC-hybrid WireGuard handshake. So even if an adversary captures both legs' ciphertext today and decrypts them with a future quantum computer, the linkability problem still requires temporal correlation of the two streams — which is harder than it sounds, because both streams carry continuous noise traffic to mask the timing.
Sovereign Route is positioned as a Pro-tier feature because the second-hop bandwidth and the entry-hop infrastructure are real ongoing costs. The free tier is single-hop, full PQC, no compromise on cryptographic strength. The Sovereign Route upgrade is for users whose threat model specifically includes "don't trust any single operator with the linkability of my real IP to my destination."
A privacy VPN is the infrastructure it operates. The cryptographic stack matters; how the servers are run matters at least as much.
Owned baremetal, not commercial VPS. Every OllaVPN exit and every control-plane host runs on hardware we operate, in colocation facilities we have contracts with directly, in jurisdictions we picked deliberately. There is no AWS, no GCP, no Azure, no DigitalOcean, no Hetzner, no Linode in the data path. The reason is direct: commercial cloud providers can image a running VM, snapshot disks, or be subpoenaed for hypervisor-level metadata that the tenant has no visibility into. Privacy promises that depend on a third party not noticing are not promises we want to make.
Privileged LXC containers on Proxmox. Each exit runs as a privileged LXC container on a Proxmox-virtualized host. This is a deliberate middle path: not a full virtual machine (which would have unacceptable overhead for line-rate WireGuard encryption), not a Docker container (which has too many shared kernel surfaces with the host), and not bare bare-metal (which would let one exit's compromise affect another). Privileged LXC gives each exit its own kernel namespace, its own networking stack, its own routing tables, and its own firewall rules — but shares the underlying physical hardware efficiently.
Stateless, reproducibly-provisioned exits. Exit servers hold no per-user state. The peer-list is pushed by the control plane at connect time; if we lose an exit completely we lose only the active connections (which reconnect to another exit within seconds), not any historical data. Provisioning a new exit is a single Ansible playbook run plus a database insert — typically 20 minutes from rack to live traffic. This means we can rotate exits aggressively, retire compromised hardware quickly, and add capacity where load needs it without long lead times.
Control plane behind a Cloudflare Tunnel. The control plane that handles authentication and peer-slot assignment has no public IP and no open ports on the public internet. Instead, it is reachable via a Cloudflare Tunnel that terminates TLS at the CF edge and forwards inbound HTTPS to a local Caddy reverse proxy. Outbound, the control plane uses its own egress IP to call exit-agent endpoints. This means: no inbound firewall holes on the control plane host, TLS is terminated at a hardened CF edge that handles its own DDoS protection, the control plane database is one fewer thing to harden against direct internet attack. The tradeoff is a Cloudflare dependency for new sign-ins; existing connections are independent of CF and continue to work during a CF outage.
Per-peer 10 Mbps cap on free, enforced at the kernel. The free-tier speed cap is enforced via Linux tc htb (Hierarchical Token Bucket) classes installed at peer-add time on the exit. Each peer gets its own class with a 10 Mbps ceiling. The cap is enforced inside the kernel networking stack, not by polling in user space, which means it does not skew or burst above the cap under any timing condition. Pro-tier peers get a class with a 10 Gbps ceiling.
Per-peer connection-rate cap. Each peer is rate-limited to 100 new outbound TCP connections per second via nftables connlimit. This prevents one peer from using the tunnel as a portscan launcher or a SYN-flood relay against third-party targets — both of which would generate abuse complaints that an operator without this guard would have to absorb. The cap is generous (legitimate browsing rarely exceeds 10-20 concurrent connections) but firm against abuse.
Outbound SMTP block. Every exit drops outbound traffic on TCP ports 25, 465, and 587 (the SMTP family). This is enforced via nftables, not as an opt-in setting. SMTP via a VPN exit is almost entirely a spam-emission pattern in 2026; legitimate email use cases work through Gmail / iCloud / Outlook web interfaces that use HTTPS instead. The block protects the IP reputation of every other peer on the same exit.
Daily soft + hard byte caps for abuse defense. Each peer has a 100 GB/day soft throttle (speed reduced after the threshold) and a 500 GB/day hard disable (tunnel suspended for the rest of the UTC day). Both are configured per-peer on the exit; the counters reset at midnight UTC. The caps catch genuine abuse (botnet exit-node use, large-scale scraping) without inconveniencing any legitimate user — 500 GB/day is far more than any normal human use case.
A privacy promise is only as strong as the verification behind it. OllaVPN is newer than Mullvad and ProtonVPN — we have not yet earned the multi-year audit track record they have. This page is honest about that and shows what we publish in the meantime.
What is open today. The marketing site (this page included) is plain HTML/CSS/JS and is built from a public Git repository. The desktop and Android client apps are progressing toward open-source release alongside the public launch — the source repository, the build instructions, and the SHA-256 of each shipped binary will be published together so any reader can rebuild from source and verify byte-for-byte. The PQC integration patches on top of wireguard-go are already open and link to the upstream NIST reference implementations.
What's scheduled. A first external security audit by an established firm (the shortlist is Cure53, Securitum, and Radically Open Security) is scheduled before public launch. We will publish the full report — not a marketing summary — including any issues found and the timeline of how we addressed each. A second audit at the 12-month mark establishes the annual cadence. A live warrant canary is maintained at our public repository and updated quarterly.
What we publish proactively. Our security disclosure policy (RFC 9116-compliant) is at .well-known/security.txt. Vulnerability reports go to security@ollavpn.com, with a 90-day coordinated-disclosure window and explicit safe-harbor language for good-faith research. Every shipped fix that prevents a regression is logged in our public fixes registry — a continuously-updated record that an auditor can use to verify "this issue was found and addressed on this date."
What we will never publish. User account information, peer-slot assignments, connection metadata, or any data tied to a specific user. Not because we have a policy against it but because the data does not exist in our systems. A subpoena for user activity would receive the response: "we cannot produce what we do not collect."
NIST finalizes the first post-quantum cryptography standards. The era of "experimental PQC" formally ends.
Apple iMessage, Signal, Google Chrome, and Cloudflare all ship post-quantum hybrids in their flagship products.
Post-quantum-ready handshake on every connection, on the free plan and the paid plan alike.
The industry moves from "PQC-capable" to "PQC-default." OllaVPN starts there.
"Harvest now, decrypt later" stops being theoretical. Sessions captured with only classical encryption become readable.
The timeline above shows when post-quantum cryptography became table stakes. This section explains why the timeline exists at all — and what would happen to your traffic if you used a VPN without it.
The threat is not "a quantum computer steals your password today." No quantum computer in 2026 is powerful enough to break a single modern VPN handshake in any practical timeframe. The threat is structurally different and operates on a longer time scale.
The actual threat is called "harvest now, decrypt later." An adversary with the resources to capture and store bulk encrypted traffic at scale — and there are several such adversaries openly operating in 2026 — records VPN traffic today, stores the ciphertext on cheap disk, and waits. When a cryptographically-relevant quantum computer becomes available (estimates range from 2030 to 2045 depending on which expert you ask, and the conservative position is to plan for the earlier date), the adversary runs Shor's algorithm against the captured ciphertext to recover the elliptic-curve session keys, and from there the plaintext.
The cost-benefit calculation favors the attacker. Petabyte-scale disk storage costs roughly $10,000 in 2026 and trends cheaper every year. The cost of capturing ciphertext at a fiber tap is fixed (you need the tap once, you record forever). The decryption value compounds with time: recently-public information has lost most of its leverage, but a decade-old encrypted communication can still expose a source, reveal a business strategy that is still in play, embarrass a public figure, or get an activist arrested in a regime that has criminalized their previous reporting. The defender's math is the opposite: every day of unencrypted-after-the-fact traffic is one more day of pending exposure.
The defense is to switch the key exchange before the quantum computer exists. NIST standardized ML-KEM-768 in August 2024 (FIPS 203) specifically for this purpose, after a multi-year competition that vetted dozens of candidate algorithms from cryptographers around the world. The algorithm is based on the hardness of structured-lattice problems — a class of mathematical problems that has no known efficient quantum algorithm, and would require fundamental advances in cryptanalysis to break. Combining ML-KEM-768 with the existing classical key agreement (X25519) means an attacker needs to break both algorithms to recover the session key. Even if one falls, the other still protects.
OllaVPN ships this on the free tier because the cost to us is small and the cost to users of waiting is large. The CPU overhead of the PQC hybrid handshake is sub-1% on Apple Silicon and roughly 2% on common Intel hardware — negligible. The bandwidth overhead (the larger PQC public key in the handshake exchange) is a one-time extra ~1 KB per session, also negligible. The only real cost is the engineering work of integrating ML-KEM-768 into the WireGuard handshake correctly. That work was a one-time fixed cost we have already paid. Charging extra for it on top of a paid tier — as Mullvad and ProtonVPN both do today — is a defensible product decision but it leaves free-tier users on the harvest-now-decrypt-later list. We do not think a privacy operator should make that tradeoff.
We have specific opinions about specific competitors. Here is where OllaVPN sits relative to the privacy-focused VPNs you may already know.
vs Mullvad. Mullvad is the gold standard for "we know nothing about you" — anonymous account-number signups, no email required, cash-by-mail accepted. They ship post-quantum WireGuard on the desktop paid tier (default-on since 2023) and have an exceptional independent-audit track record. The trade is that Mullvad has no free tier at all (flat €5/month) and a relatively narrow country footprint. OllaVPN is the right complement: a free tier for everyday use, PQC on every connection including free, and country coverage that broadens over time. If "free" matters to you, OllaVPN. If you need the no-account-identifier property specifically, Mullvad paid.
vs ProtonVPN. ProtonVPN's free tier is the reason the "honest free VPN" category exists in the consumer mind. Unlimited data, Swiss jurisdiction, open-source on every platform. The trade is the country selection on free (three countries, period) and that PQC is paid-tier only. OllaVPN's free tier opens every country we serve and ships PQC on free. If country coverage on free matters, OllaVPN. If you also need iOS or Linux desktop today, ProtonVPN — we have not yet shipped to those platforms.
vs NordVPN. NordVPN's positioning is performance and breadth: large server fleet, fast everywhere, polished apps across every platform. The trade is the absence of a free tier and the model — heavily paid-marketing-driven, with extensive affiliate networks — which is not the same posture a privacy-first operator takes. NordVPN is a fine product for users whose threat model is "stop my ISP from selling my data" and who are willing to pay. OllaVPN is the right pick for users whose threat model is "stop the ISP, the operator, and a future quantum-equipped adversary" and who want to start with the free tier.
vs ExpressVPN, Surfshark, CyberGhost. The "big consumer brands" category. All three are owned by larger holding companies (Kape Technologies in some cases, Nord Security parent in others). All three operate large server fleets on commercial infrastructure. None ship PQC on the free tier in 2026 (and several have no free tier). We respect their engineering and acknowledge their marketing strength; we are not optimizing for the same use case. A privacy-first operator with a smaller, owned-baremetal footprint and PQC by default is what we are, and that is a different category from "biggest brand, largest paid-marketing budget."
vs Tor. Tor is not a VPN, and it would be intellectually dishonest to imply OllaVPN replaces it. Tor offers source-anonymity against a global passive adversary, at the cost of latency (typically 1-3 seconds per round trip) and significant practical limitations on use. OllaVPN narrows the linkability surface but is not source-anonymous in the Tor sense. The honest recommendation: use Tor when source-anonymity is critical and you can tolerate the latency; use OllaVPN with Sovereign Route when operator-linkability is the threat and you need normal-speed internet.
A technology page should be honest about what is not in the product, not only what is. The list below is what readers might expect that we do not currently offer, and the reason in each case.
No iOS client yet. iOS requires the Apple Developer Program enrollment ($99/year) and the Network Extension entitlement, which is on a roadmap behind public launch. We did not want to ship a half-built iOS app to claim the platform on a feature matrix. ProtonVPN, Windscribe, and hide.me all ship excellent iOS clients today; pick one of those if iOS coverage today is critical.
No Linux desktop client yet. Linux is a planned platform but not in stage-1 scope. Power-user readers can use standard wg-quick with a manually-fetched WireGuard config from the control plane in the meantime; we publish the necessary steps for advanced users. Proton VPN's Linux client is the gold standard if you need a polished GUI today.
No CLI client. Explicitly out of scope. Engineers who want command-line VPN management can manage WireGuard directly. The OllaVPN apps target the everyday user; the CLI use case is well-served by the existing WireGuard toolchain.
No browser extension. Explicitly out of scope. Browser-extension "VPNs" are technically proxies that cover only browser traffic, not the operating system. They are structurally weaker than a real VPN and we do not want to market a proxy under the VPN name. If you want browser-only privacy in addition to a real VPN, Windscribe's browser extension is the one we would point you at.
No port forwarding on free. Port forwarding on the free tier is a vector for hosting commercial services on residential IPs and is the single most common abuse pattern we would have to defend against. We have decided not to offer it on free; it is a planned Pro-tier feature.
No split-tunneling on free. Split-tunneling on free is a planned Pro-tier feature on macOS and Windows. Implementing it correctly requires NEAppProxyProvider on macOS and similar per-app routing on Windows — both are engineering work that is scheduled but not stage-1 scope.
No multi-hop on free. Sovereign Route is a Pro-tier feature because the second-hop infrastructure cost is real and ongoing. Free-tier users get full PQC single-hop; the cryptographic strength of the free tunnel is the same as the inner tunnel on Sovereign Route.
No in-tunnel ad blocker on free. A resolver-level ad blocker (the Windscribe R.O.B.E.R.T. pattern) is on the roadmap as a Pro-tier feature. Free-tier users can still use uBlock Origin in their browser; the in-tunnel ad blocker would catch ad traffic from apps that bypass browser-extension ad blockers.
No dedicated IP on any tier. Dedicated-IP service makes the operator's user-to-IP mapping persistent, which is a privacy regression we do not want to ship. If your use case requires a stable IP (some banking, some hosting), a paid VPN with a dedicated-IP SKU is more appropriate than OllaVPN.
No promise of streaming-service compatibility. Netflix, Hulu, Disney+, and similar services actively block VPN IP ranges. The blocklists rotate daily. We do not promise that any specific streaming service works through any specific OllaVPN exit at any specific time — because the promise would be wrong by next week. If reliable streaming-unlock is your primary need, a paid VPN with a dedicated streaming SKU is the honest recommendation.
Claims on a marketing page are worth what the reader can verify. The properties we describe above are testable from your own device in under fifteen minutes using free tools.
Test DNS in-tunnel. Connect OllaVPN. Open our DNS lookup tool in your browser and resolve a domain. The resolver IP shown should be the in-tunnel one (something in the 100.64.0.0/10 range, depending on which exit you connected to). Disconnect and repeat — now you should see your ISP's resolver instead. The diff is the evidence that DNS goes through the tunnel while connected.
Test WebRTC and IPv6 leaks. Open our WebRTC leak test while connected. The page runs the same checks an attacker would, including WebRTC ICE candidate enumeration, IPv6 address detection, and DNS leak tests. You should see only the exit's IPv4 address. If any test reveals your real IP, the leak protection has failed and we want to know — file an issue at security@ollavpn.com.
Test the kill switch. Connect OllaVPN. Open a continuous ping in a terminal: ping 1.1.1.1 on macOS/Linux, or ping -t 1.1.1.1 on Windows. Now turn off Wi-Fi (or unplug Ethernet). The ping should immediately fail and stay failed until you re-enable the network. The packets should not switch over to the underlying network. If they do, the kill switch is broken (it isn't, but verify).
Test peer isolation. Harder to verify without two devices both connected to the same OllaVPN exit at the same time. If you have that setup, try to ping the other device's tunnel IP from the first. The ping should fail. (We run this test on every release internally; we publish the test code in the public repository under tools/e2e/peer-isolation/ for anyone who wants to verify the methodology.)
Inspect the WireGuard handshake. If you are technically inclined, run wg show all on Linux (or use the WireGuard inspector on Windows/macOS) to see the current handshake state. The peer's public key in the WireGuard configuration is the exit's WireGuard public key. The handshake counter should increment regularly (a fresh handshake every ~2 minutes); that is the forward-secrecy property working.
Test that streaming-service blocking is the streaming service's, not ours. If a site says "VPN detected, please disable to continue," that is the site detecting and refusing VPN traffic, not OllaVPN refusing to pass the traffic. You can confirm by trying the same site disconnected from the VPN — it works. The VPN is delivering the traffic faithfully; the site is using IP-block detection to refuse it.
The reference userspace WireGuard implementation (wireguard-go), maintained by Jason Donenfeld and the WireGuard project. We carry a small open fork that adds the X25519 + ML-KEM-768 hybrid handshake on top of the standard Noise_IK pattern. The fork is open and the diff against upstream is published; we have not written novel cryptography, only integrated the NIST-standardized ML-KEM-768 reference implementation into the existing handshake.
The same ones WireGuard pins by design: ChaCha20 for symmetric encryption, Poly1305 for message authentication, Blake2s for hashing, Curve25519 for the classical leg of the key exchange, and ML-KEM-768 (FIPS 203) for the post-quantum leg. WireGuard does not support cipher negotiation — the protocol specifies these algorithms exactly — which means there is no "downgrade attack" surface where a man-in-the-middle could force a weaker cipher. We agree with this design.
WireGuard has a smaller code surface (about 4,000 lines vs OpenVPN's 70,000+), which makes it dramatically easier to audit. It has stronger default cryptographic choices (modern ciphers vs OpenVPN's negotiated set with legacy compatibility). It performs much better — typically 3-10x faster — because the protocol design is simpler and the kernel implementations are more efficient. And it has been formally verified in parts (the Noise protocol framework it's built on). The downside vs OpenVPN is reduced obfuscation against deep packet inspection — WireGuard packets are recognizable as WireGuard. We mitigate this on our Frankfurt exit via a MASQUE-over-port-443 obfuscation transport, and we are watching the IETF work on standardized WireGuard obfuscation.
Not yet. ISO 27001 certification is meaningful for organizations selling to enterprise procurement teams; we are not in that market today. We focus instead on the independent third-party audit cadence (scheduled with one of Cure53 / Securitum / Radically Open Security before public launch, with the full report to be published rather than a summary). If you specifically need ISO 27001 for procurement reasons, a different operator is the right fit; we are honest about not being that operator yet.
The marketing site, the legal documents, and the PQC integration patches are open today. The desktop and Android client apps are open-sourcing alongside the public launch — the source repository, the deterministic build instructions, and the SHA-256 of each shipped binary will be published together. We are not open-sourcing the control plane or the exit-agent code (those handle operational secrets and abuse defenses) but the architecture is documented in the production-grade docs in the repository.
No, by architecture. The exit server sees encrypted WireGuard packets coming from your tunnel IP. The control plane sees that you authenticated and which exit you connected to (because that is necessary to route you), but it does not see the destinations of your traffic, the DNS queries you made, the bytes inside the packets, or anything else. The data simply is not in our systems to inspect. If we wanted to log it we would have to substantially re-architect the data plane, which we have not done and have no plans to do. The architecture is the audit.
The honest answer is: we comply with the legal process to the extent it asks for data we have. We have account email, password hash, and current peer-slot assignment for an active account. We do not have connection history, DNS queries, destination IPs, source IPs of past sessions, or per-packet metadata. A subpoena asking for "the user who connected to example.com on this date" gets the response: we did not store that data. We maintain a public warrant canary at our repository, updated quarterly, that documents whether we have received any gag-ordered legal requests.
The control plane and the legal entity are operated in a privacy-friendly jurisdiction; we will document the specifics on the public-launch transparency report. Exit servers are operated in the countries we serve users from — currently Germany and the United States, with Switzerland added for Sovereign Route entry-hops. Each exit operates under the laws of its host country. We pick exit-host jurisdictions specifically for their data-retention and surveillance posture; we do not run exits in any country with mandatory connection-logging laws.
The free tier is capped at 10 Mbps per peer via Linux tc htb at the exit. The Pro tier is capped at 10 Gbps per peer (with fairshare behavior under load, so a single Pro user does not crowd out other Pro users). Latency depends on your distance to the chosen exit; typical numbers are 20-50 ms additional round-trip time vs no VPN at all. The WireGuard implementation has near-line-rate performance on modern hardware — the cap, not the cryptography, is the speed ceiling.
Two to five percent of free users upgrade to the Pro tier ($2/month annual). The per-Pro-user revenue ($24/year) substantially exceeds the per-free-user infrastructure cost (typically $0.10-$1 per year at scale, depending on usage). The math is the same paid-tier-conversion model that funds Proton VPN Free and Windscribe Free. If you want to understand the funding-model question more deeply, the funding-model section of our best free VPN 2026 guide covers it in detail.
"PQC-ready" means an operator supports post-quantum handshakes but does not use them by default — the user has to enable them, often through an advanced setting or by picking a specific server. "PQC-default" means the hybrid handshake is on for every connection, every user, every server, without configuration. Mullvad is PQC-default on desktop paid. ProtonVPN is rolling out PQC-default across clients. OllaVPN is PQC-default on every tier from day one. The distinction matters because most users will never change the default; PQC-ready alone leaves the majority of users on classical cryptography.
Not yet at the resolver layer. The in-tunnel resolver does not currently maintain a tracker/ad blocklist; that is a planned Pro-tier feature. We deliberately did not ship it on the free tier on day one because tracker blocklists have a high false-positive rate and we did not want to break sites for users who did not opt into the tradeoff. In the meantime, uBlock Origin (browser extension) handles the great majority of web ads and trackers at the browser layer.
This page is maintained by Nathan Pratt, OllaVPN's Privacy & Security Lead. The technical claims about the WireGuard handshake, the PQC integration, the kill-switch enforcement layers, and the peer-isolation defense layers were fact-checked against the production codebase by Hannah Wu, Senior Security Engineer, during the June 2026 update cycle. The infrastructure descriptions reflect the deployed state of OllaVPN's control plane and exit fleet as of 22 June 2026.
This page is refreshed quarterly. If a technical claim becomes outdated — a default changes, a new defense layer is added, an audit completes — the page is updated and the dateModified field in the schema is incremented. If you spot an error or a claim that no longer matches the code, email guides@ollavpn.com and we will correct it in the next refresh.
If you want to go deeper than this page goes: the broader best free VPN 2026 guide covers the wider category context. The post-quantum cryptography pillar explains PQC fundamentals without assuming the reader knows the cryptography. The kill switch deep-dive covers why "always on" matters. The DNS leak primer explains the resolver layer in detail. The multi-hop VPN explainer covers Sovereign Route's conceptual basis.