The first surprising thing about WireGuard is the size. OpenVPN and IPsec are sprawling; WireGuard’s kernel implementation is a few thousand lines. The reason is a series of “we just won’t support that” decisions.
No crypto agility
There is exactly one cipher suite: ChaCha20-Poly1305 for data, Curve25519 for key exchange, BLAKE2s for hashing. No negotiation, no downgrade dance, no 2003-era ciphers to keep around. If the suite ever needs to change, that’s a new version of the protocol, not a runtime option. A huge amount of complexity (and vulnerability surface) in older VPNs is the negotiation machinery.
Peers are just public keys
Configuration is almost offensively simple:
[Interface]
PrivateKey = <ours>
Address = 10.0.0.1/24
ListenPort = 51820
[Peer]
PublicKey = <theirs>
AllowedIPs = 10.0.0.2/32
Endpoint = peer.example:51820
AllowedIPs does double duty: it’s both the routing table (“send these prefixes into the tunnel”) and the access control list (“only accept packets from this peer if their source is in this set”). One field, cryptographically enforced.
Silence on the wire
WireGuard doesn’t reply to unauthenticated packets. If you don’t hold a valid key, the port looks closed — there’s no handshake to probe, no banner to fingerprint. That’s a deliberate anti-scanning property, and it’s why a WireGuard endpoint is genuinely hard to discover by poking at it.
The trade-off is that it’s recognisably WireGuard to a censor doing deep inspection of the handshake, which is a different problem from being scannable. Different threat model, different tool.