WireGuard vs OpenVPN for a privacy VPN.
State of things on 18 October 2026: Pevnost is in private beta. The first server, in Hluboká nad Vltavou, is live with our DNS resolver inside the tunnel at 10.8.0.1. Accounts are paid by bank transfer; Bitcoin and Lightning open as soon as our node finishes syncing, Monero and cash by post later. Windows app 0.2.2 beta and Android app 0.1.0 beta (APK) are on the Apps page; iOS and macOS use the official WireGuard app. Last reviewed 18 October 2026.
Pevnost speaks one protocol: WireGuard. No OpenVPN, no IPsec, no proprietary tunnel. People sometimes read that as a limitation. It is a choice, and this post explains it from the point of view that matters to us: what a protocol forces a no‑log operator to know about you, and how much of the code between your device and the exit you can realistically trust.
Size is a privacy property
OpenVPN is a user‑space program built on top of a full TLS library. The tunnel itself is small, but it drags the whole TLS stack with it: certificate parsing, cipher negotiation, renegotiation, compression options, dozens of configuration knobs that interact in ways few operators understand. Every one of those knobs has been the site of a vulnerability at some point, and the configuration that is secure this year is not the same as the one that was secure five years ago.
WireGuard's kernel implementation is a few thousand lines of code. There is no negotiation: one key exchange based on the Noise protocol framework, one set of primitives (Curve25519, ChaCha20‑Poly1305, BLAKE2s, HKDF), no cipher suites to misconfigure. If one of those primitives is ever broken, the protocol gets a new version and everyone upgrades; there is no downgrade path to exploit in the meantime. A protocol that small can be read in a weekend by a competent engineer, and it has been, many times. For an operator who asks you to trust that the server does what the published configuration says, the ability to read the whole thing is not a nicety. It is most of the argument.
In the kernel, not next to it
Since Linux 5.6 WireGuard ships in the mainline kernel. On our nodes packets go from the network card into the kernel, get decrypted and forwarded, and go back out, without ever crossing into a user‑space process. That has two consequences we care about. Performance: a single rented server forwards traffic at close to its line rate, so we do not need to throttle. Our first node delivered around 300 Mbit/s to a single client in a short test, and we will publish longer measurements on the status page. Attack surface: there is no long‑running daemon with root privileges parsing input from the internet; the parsing happens in code maintained by the kernel community and shipped by every distribution.
What the server has to know
This is the part most comparisons skip. A VPN server must hold some state about you, or it cannot send packets back. The question is how much, and for how long.
An OpenVPN server keeps a TLS session per client, with a session ID, the negotiated parameters, the client certificate or the username it authenticated with, and typically a status file on disk that lists connected clients with their real address, virtual address and byte counters. That file is written by default. Authentication usually means a username and password or a certificate tied to an account, so the server knows which account each connection belongs to, by design, every second it is up.
A WireGuard interface keeps, per peer, a public key, the allowed tunnel address, the most recent endpoint (your current real address and port) and the time of the last handshake. Nothing else. There is no session, no login, no username; the public key is the identity, and it says nothing about who paid. The endpoint is overwritten on every handshake and disappears when the interface goes down. We describe exactly this in our privacy policy and in the post on what a seized node yields: while you are connected the node holds your address in RAM, and that is the complete list. There is no status file, because there is nothing that writes one, and our nodes have no writable disk to write it to.
Always UDP, always one port
WireGuard runs over UDP only, on a port the operator picks. It does not try to look like HTTPS and it cannot run over TCP. This is a real limitation: on a network that blocks UDP, or that throttles everything that is not recognisable web traffic, WireGuard does not connect, where an OpenVPN tunnel on TCP 443 might. We do not disguise the protocol, and we do not claim to work from inside networks that are actively trying to block VPNs. If you need to get out of such a network, you need an obfuscation layer, and that is a different product with different trade‑offs.
A static key per device
Each device you register with Pevnost has its own key pair, generated on the device; the private key never leaves it, and we see only the public half. That key is static for the life of the device entry. OpenVPN's TLS layer renegotiates and can rotate the symmetric keys on its own schedule; WireGuard rotates session keys every couple of minutes by protocol, but the identity key stays. For privacy this means: if someone obtains your device's private key, they can impersonate that device until you delete it in your account. Deleting a device and adding a new one takes a minute and costs nothing. Do it if you lose a phone.
What you give up
- TCP fallback. None. On UDP‑hostile networks, WireGuard does not connect.
- Looking like something else. WireGuard is easy to identify on the wire. Where that is a problem, you need a different tool.
- Dynamic addressing. WireGuard has no built‑in way to hand out addresses, so every device gets a fixed tunnel address from us. The address is private (10.8.x.x) and tells the outside world nothing, but it does mean the configuration is per device, which is why you download a file or scan a QR code instead of logging in.
- Legacy clients. Some routers and appliances speak OpenVPN and nothing else. Most current ones also speak WireGuard; the ones that do not, we do not support.
Why we think the trade is right
A privacy VPN sells one thing: the operator's claim about what it does not keep. That claim is only worth something if it can be checked against the protocol's actual behaviour, the server's actual configuration and the code that runs it. With WireGuard that chain is short enough to follow end to end: the protocol is tiny and public, our node configuration is published, the server keeps the minimum state the protocol needs and nothing it could later be asked to hand over. We would rather tell you honestly that we do not work from inside a hostile corporate network than add a second protocol that carries a login, a session and a status file into the design. See the setup guide for installing the official clients, and the leak test guide for checking that the tunnel carries everything.