OpenVPN or WireGuard? Decide From Identity and Transport

Comparing these two protocols is only useful if it compares what you will actually operate. WireGuard identifies peers by public key and carries its protocol over UDP, while OpenVPN offers a wider set of authentication arrangements and can run over UDP or TCP when the server provides both. Those differences shape provisioning and fallback long before they shape throughput. Run the four checks below in order; the first two usually decide the choice, and the last two tell you whether the decision was right.

Start with identity, not with the cipher list

A WireGuard peer stores one private key and lists the public keys it may reach. A provider can wrap an account portal around that, but the protocol itself has no username-and-password exchange, so account lifecycle lives in whatever distributes the keys. OpenVPN can use certificates, a plugin against an existing directory, or a verification script, which is why organisations with an identity system often prefer it. Neither design removes the question of how a lost device is removed.

A short configuration is not the same as simple provisioning. Handing one private key to several people makes later removal ambiguous, because revoking it removes everyone at once. Write the mapping from person to key or certificate before choosing, and the protocol decision gets considerably easier.

Then look at what the transport allows

WireGuard's protocol uses UDP. OpenVPN services can offer both UDP and TCP profiles, and on a network that blocks or degrades UDP that second option is a practical fallback rather than a theoretical one. The server has to support the profile you pick, and changing a port number does not turn the tunnel into HTTPS or persuade a firewall to permit it.

Carrying TCP inside TCP also changes behaviour under loss, because both layers retry and reorder independently. A TCP profile that works on a restrictive network can still perform poorly on a lossy one, which is a reason to keep both profiles available rather than declaring one superior.

Then check routing and name resolution

WireGuard's AllowedIPs maps address ranges to peers and acts as a routing decision inside the protocol, and the surrounding tools use those ranges when they install routes. OpenVPN pushes routes and DNS options from the server. In both cases the client can come up while the intended policy is only half applied.

ip route show
ip -6 route show
resolvectl status
wg show

Read the output before you trust the connected indicator. ip route show lists what the client installed for IPv4, and the IPv6 variant catches a tunnel that carries only one family. resolvectl status shows which resolver the client will actually query, and wg show prints the AllowedIPs that WireGuard believes it owns. If the resolver still points at the local network while the routes claim full coverage, DNS leaves outside the tunnel.

Then measure the task you care about

Hold the device, the network and the destination steady, and record the clients and endpoints you used. If the two services exit in different cities or run on different hardware, say so, because the result then describes those services rather than the protocols.

iperf3 -c 203.0.113.20 -t 30
mtr -rwzbc 50 203.0.113.20

Run both commands twice, once per profile pair, on the same network and device. iperf3 gives a throughput figure, and mtr gives the path and where loss appears, which a single download number cannot show. A download figure also misses what a call notices: added latency, jitter and how long a reconnect takes. Record those separately, because a protocol that wins on throughput can still lose on the task you actually run.

For a managed connection, compatibility, support and renewal effort can outweigh a small benchmark difference. For a personal exit, the operator's logging and jurisdiction matter more than the protocol label. Both protocols can carry a good connection; the service and its configuration decide what you get.

Write down the profile pair before you test

Choose one profile per protocol before measuring, and write down what each is supposed to do: private subnets only, or all traffic with a specific exit. A test that compares a split-tunnel profile with a full-tunnel one measures the profiles, not the protocols. Put the client name, the client version and the exit location in the same note.

Then run the same task on both, on the same network, in the same session. If one fails to connect at all, that failure is the result and belongs in the record with the reason. Keep the record with the service documentation so the next person compares the same pair rather than starting over.