How OpenVPN and WireGuard Differ by Design
OpenVPN was written to be flexible: a tunnel you can configure almost any way you need, built on the same handshake machinery as encrypted web traffic. WireGuard was written to be small: a tunnel with most of the options removed, few enough lines of code that one person can read all of them, and no notion of a session to keep alive. Those two briefs explain nearly every difference between them.
This comparison stays on design and behaviour. If you want the roaming and platform-integration question instead, that is WireGuard against IKEv2 when you move between networks, and the layer model both designs sit inside is which part of your VPN is the protocol.
Codebase size, and why anyone should care
Small enough to audit is a security property, not a tidiness preference.
OpenVPN is a mature userspace daemon with a long feature list, a plug-in interface, and support for a broad range of ciphers, transports, and deployment shapes. That surface is the price of flexibility, and it is large enough that reviewing the whole thing is a serious undertaking rather than an afternoon.
WireGuard’s design goal was the opposite: a code footprint small enough for a competent reviewer to read end to end. It achieves that partly by refusing to negotiate. There is no cipher list, no fallback modes, no plug-ins. The cryptographic choices are fixed by the specification, which removes an entire category of implementation bug — the misconfigured or downgraded option — by removing the options.
The honest caveat is that a small protocol core does not make the whole system small. WireGuard on a consumer VPN service is wrapped in provider software that handles account authentication, key distribution, address assignment, and everything in the client’s list of jobs. The auditable part is the tunnel, not the product.
Negotiation versus fixed choices
One asks the other end what it supports; the other assumes.
An OpenVPN connection begins with a TLS-style exchange in which the two ends establish identities and settle on parameters. This is what allows one server to serve clients of different ages and capabilities, and it is what allows an administrator to require a particular configuration. It also means the connection is a negotiation, with the ordinary risks of negotiated protocols: an option that should have been disabled, a legacy mode left enabled for compatibility.
A WireGuard peer has nothing to ask. The handshake authenticates two static public keys against each other and derives session keys, and that is the extent of the conversation. Compatibility means both ends implementing the same specification rather than finding common ground at runtime. For you as a user, that means far fewer settings can be wrong — and correspondingly fewer can be adjusted when something in the network path dislikes the tunnel.
Session versus stateless, and what changes when the network moves
OpenVPN maintains a connection; WireGuard maintains a set of peers.
OpenVPN’s tunnel is a session with state on both ends, and it notices when that session breaks. Depending on configuration and transport it will detect the failure, tear down, and re-establish — which involves a fresh handshake. The client is aware of connection status in a way that maps neatly onto a status indicator and onto reconnect logic.
WireGuard has no connect or disconnect. An interface either has peers configured or it does not. When a packet arrives that authenticates correctly, the receiving end notes the address it came from and replies there; when nothing is being sent, nothing is on the wire at all. The tunnel is not “up” or “down” so much as recently used or not.
Two practical consequences follow. First, a silent WireGuard tunnel gives the app nothing to report, which is why clients synthesise a status from recent handshake times and why a keepalive option exists to make the tunnel speak periodically. Second, WireGuard only ever uses UDP. OpenVPN can be told to run over TCP, which is slower and stranger from a network engineering standpoint but sometimes the only thing a restrictive network will pass. If you have ever had a tunnel work only on one particular setting, this is usually why.
Configuration surface, from a user’s seat
One is a file with many directives; the other is a file with a handful.
An OpenVPN profile can specify transport, port, cipher, authentication method, certificate chain, compression, route pushing, resolver pushing, and a long tail of behaviour switches. Providers distribute ready-made profiles precisely because assembling one by hand requires knowing what all of it means.
A WireGuard configuration is short enough to read at a glance: your own key, the interface address, the peer’s key, the peer’s endpoint, and which destinations route to that peer. That brevity is genuinely useful when checking what a provider has given you, since there is nowhere for a surprising directive to hide.
Where it bites is that behaviour OpenVPN can push from the server has to be arranged some other way. Route and resolver assignment in particular is not part of the WireGuard protocol; the client software does it. That is one more reason DNS handling on a WireGuard-based service is a property of the app, examined in what your VPN’s DNS setting actually changes.
How each one identifies you to the server
This is the difference with the most privacy in it, and the least discussed.
An OpenVPN server hands the client an address from a pool, in the manner of a local network handing out addresses. Reconnect and you may well get a different one. Your identity to the server is a credential presented at handshake time, and the tunnel address is transient bookkeeping.
WireGuard binds a public key to a fixed tunnel address in the server’s configuration. That is what makes routing decidable without a session — the server knows which key owns which address — and it also means that, in the naive deployment, a device holds a stable identifier inside the tunnel across reconnections and across days. A server that records anything at all is recording it against a persistent handle.
Providers are aware of this and work around it: issuing short-lived keys, reassigning addresses on each connection, keeping the mapping only in memory. Those are provider engineering decisions rather than protocol features, so the mitigation is only as good as the operator’s implementation and honesty about it — which returns the question to their logging policy and the shared-exit arrangement described in shared versus dedicated VPN IP addresses.
Deciding
If your provider offers both and you have no specific constraint, the minimal design is the reasonable default. Fewer options means fewer ways for the tunnel to be quietly misconfigured, and the fixed-choice approach removes the negotiation risks entirely.
Choose the flexible one when the network is the problem. A tunnel that must survive a network passing only web-like traffic, or a setup that needs server-pushed routes and unusual transports, is what OpenVPN’s configurability is for.
And notice where the two briefs converge. Neither specification takes a position on which of your packets should be offered to the tunnel, which resolver should answer your lookups, or what should happen the moment the tunnel stops carrying anything. WireGuard leaves those out deliberately, as part of staying small; OpenVPN pushes them from the server as directives, which is to say it also treats them as configuration rather than as protocol. That shared omission is the design fact worth remembering, because it tells you which questions no comparison of the two can settle.