The DPI Question Both VPN Protocols Fail to Answer, and Where the First Handshake Packet Hides the Cost

WireGuard is not the correct default if your adversary runs deep packet inspection. Hear me out.

The conventional answer to this question — which protocol you should use if you are being serious about your threat model — goes WireGuard, end of discussion. The kernel codebase is roughly four thousand lines. Jason Donenfeld published a formal whitepaper at NDSS in 2017 and the protocol has been in mainline Linux since kernel 5.6 in March 2020. Cure53 audited Mullvad's WireGuard implementation and published findings in 2020 that were largely cosmetic. The cryptography is modern — ChaCha20-Poly1305 for the data channel, Curve25519 for key exchange, BLAKE2s for hashing — and the attack surface is not comparable to the several hundred thousand lines of OpenVPN and OpenSSL you are trusting every time an OpenVPN packet leaves your laptop. On the question of code quality and protocol hygiene, the WireGuard argument is settled, and we are not here to relitigate it.

Code quality is not the question when the adversary runs DPI. The question is whether the first packet your VPN client sends gets classified as a VPN handshake before it reaches the other end. On that question — the question that actually matters if you are reading this from Tehran, Beijing, or Moscow — the conventional answer is wrong, the real answer is considerably more nuanced, and both protocols are more fingerprintable than their advocates want to admit.

WireGuard's First Handshake Packet Is a Tell, and the Tell Was Deliberate

Read the WireGuard whitepaper Donenfeld presented at NDSS in 2017, section 5.4.2. The handshake initiation message is specified at exactly 148 bytes, with a fixed structure: one byte of message type with value 0x01, three reserved bytes of zero, then the sender index, the ephemeral public key, an encrypted static key, and the encrypted timestamp and MACs, following the Noise_IK pattern from the Noise Protocol Framework. This is deterministic, documented, and trivially recognisable to anything doing flow-level classification. You do not need a machine learning classifier to fingerprint a 148-byte UDP packet that begins with the bytes 0x01 0x00 0x00 0x00. You need a regular expression.

This was not an accident and it was not an oversight. Donenfeld has stated on the record, repeatedly, on the WireGuard mailing list that obfuscation and steganography are explicitly out of scope for the protocol. The architectural position is that the tunnelling layer should be small, auditable, and correct, and that obfuscation belongs above it as a separate replaceable concern. That is a defensible engineering decision. It is also a decision that leaves raw WireGuard on UDP port 51820 as a VPN your ISP can identify in a single packet and your nation-state-capable adversary can identify in less.

The operational consequences have been visible for years. The Great Firewall has been observed dropping WireGuard handshake packets since at least 2020. Iranian ISPs implementing SmartFilter rules block UDP flows matching the handshake signature. Russia's TSPU equipment, rolled out aggressively after 2022, fingerprints WireGuard reliably enough that Russian users treat raw WireGuard deployments as functionally dead. None of this is a cryptographic weakness. The sessions are not being decrypted. They are being dropped before they complete, because being identifiable as a VPN handshake is a sufficient condition for the censor to act. In the threat model where the adversary is a DPI-capable censor, being identifiable is the failure, and the WireGuard handshake fails that test by design.

OpenVPN's Bigger Codebase Is a Standing Tax You Pay Every CVE Cycle

Here is the strongest version of the opposing argument, stated fairly. OpenVPN over TCP port 443, with tls-crypt enabled, is harder to casually fingerprint than raw WireGuard. The flow looks more TLS-shaped at the metadata level, the port is the port every browser uses, and a lazy DPI policy that drops anything matching the WireGuard handshake signature does not trigger on it. If your threat model is a home ISP running flow-classification rules licensed from a middlebox vendor, OpenVPN-over-443 genuinely does buy you something raw WireGuard does not. Concede that. It is the one defensive property OpenVPN has that unwrapped WireGuard cannot match.

The concession is where OpenVPN's case ends. Xue, Ramesh, Jain and collaborators at the University of Michigan published *OpenVPN is Open to VPN Fingerprinting* at USENIX Security 2022, and the paper's central result is that OpenVPN — even wrapped in tls-crypt, even running on port 443, even with the flow-level properties the "looks like TLS" argument depends on — is identifiable with over 85 percent true-positive rate and negligible false positives in real ISP-scale traffic from a large commercial operator. Their classifier exploited the opcode byte in the control channel, the reconnection behaviour of clients after a forced drop, and ACK timing properties that tls-crypt does not hide. The argument that OpenVPN hides better than WireGuard survives exactly until you read that paper, and then it does not.

Then there is the standing cost of the codebase itself. OpenVPN is several hundred thousand lines of C that link against OpenSSL or mbedTLS for every cryptographic primitive. Every OpenSSL CVE lands in every OpenVPN deployment running that OpenSSL version, and the OpenVPN project has its own CVE cadence on top. CVE-2020-15078 is the instructive example: disclosed 2021-04-20, affecting OpenVPN server 2.4.0 through 2.4.11 and 2.5.0 through 2.5.1, an authentication bypass via improper handling of deferred authentication that allowed a remote attacker to obtain access in specific server configurations where deferred-auth was enabled. CVE-2022-0547, disclosed 2022-03, affected OpenVPN 2.1 through 2.5.5 and was a plugin-based authentication bypass in the same class. These are not exotic cryptographic flaws. They are the kind of boring authorisation bugs a large complex codebase will produce on a schedule, and they are the class of bug that WireGuard's four-thousand-line kernel module has not produced because the lines of code to produce them do not exist.

The cost of running OpenVPN in 2026 is not CPU cycles. It is the maintenance tax you pay every OpenSSL CVE cycle on a codebase an order of magnitude larger than the one you are actually using.

The Only Honest Answer Is Which Default You Bolt Obfuscation Onto

The argument the VPN review sites are having — WireGuard scored against OpenVPN on throughput, server count, kill-switch features, number of simultaneous devices — has nothing to do with the question a serious threat model forces you to answer. If your adversary is a DPI-capable censor, the question is not which raw protocol wins on paper. The question is which protocol you bolt your obfuscation layer on top of, and what that obfuscation layer is actually doing.

Raw WireGuard plus AmneziaWG — a fork that randomises the first packet signature and breaks the 148-byte-starting-with-0x01 fingerprint the GFW keys on — is a smaller total attack surface than OpenVPN plus any equivalent wrapper, because the inner protocol is smaller, the codebase is smaller, and the failure modes are smaller. WireGuard inside wstunnel, inside Cloak, inside shadowsocks-2022, or behind a Tor pluggable transport like obfs4 are all live options, each with a different fingerprint profile against a different adversary. The cost of the wrapper is the maintenance and review burden of the wrapper. The cost of the inner protocol is the maintenance and review burden of the inner protocol. On both counts the WireGuard-based stack is cheaper than the OpenVPN-based stack.

The honest positions, stated plainly. For a user whose adversary is a nation-state-grade DPI censor, neither raw WireGuard nor OpenVPN-over-443 is the right default; the right default is WireGuard plus an obfuscation layer chosen to match the specific fingerprinting technique the specific adversary is known to deploy, and the choice of obfuscation layer is where the actual analysis happens. For a user whose adversary is a home ISP running off-the-shelf flow classification, raw WireGuard on a non-default port is probably sufficient, and the question was never interesting in the first place. For a user whose adversary is running nation-state signal-intelligence-grade active probing, neither of these is the conversation you should be having at all, and you should be reading the Tor Project's pluggable transports documentation instead.

The question is what fingerprint your handshake leaves, what capability the adversary you actually have is willing to spend against that fingerprint, and whether the obfuscation layer you bolt on top closes the specific gap the specific adversary exploits. That is the question. No VPN comparison page will answer it, because the VPN comparison page has to sell you a single product.

This started as a protocol comparison and turned into a rejection of the comparison frame. The question the reader came in with — WireGuard or OpenVPN, pick one — cannot be answered honestly without first asking who the adversary is, and once that question is on the table the scored-comparison frame collapses. What is left is an obfuscation layer selection problem wrapped around a much smaller protocol choice, and the obfuscation problem is where the cost lives.

Xue, Ramesh, Jain et al., *OpenVPN is Open to VPN Fingerprinting*, USENIX Security 2022: over 85 percent OpenVPN-flow identification rate at ISP scale, with tls-crypt enabled, against traffic from a large commercial operator. That is the number. It is published. It speaks for itself.