What a Pre-Shared Key Does in IPsec, OpenVPN and WireGuard

The words pre-shared key appear in IPsec, OpenVPN and WireGuard documentation, and they describe three different objects. One is an authentication secret, one protects a control channel, and one adds material to a handshake that already has identities. Treating them as interchangeable produces a connection that fails at a stage nobody expected. Read what the field does in that protocol before copying a value into it.

Three Protocols, Three Meanings

Each protocol defines the key's job in its own specification, and the jobs do not overlap. An authentication secret proves that two peers know the same value. A control-channel key protects the negotiation that follows. A handshake add-on changes the key schedule without changing who the peers are.

None of those roles authenticates a human user, which is the confusion that costs the most time. A pre-shared key is provisioned to devices or gateways before the exchange, so every holder looks identical to the other end. That property is a feature for a site-to-site link between two routers and a liability for a remote-access service with named employees. Keep the account credential and the cryptographic secret in separate columns of whatever document describes the deployment.

IPsec and OpenVPN Use the Word Differently

IKEv2 can authenticate a peer with a pre-shared secret instead of certificates, and the value must match on both ends. Because the same secret is usually configured for a group of peers, any holder can impersonate the others, and the exchange gains no forward secrecy from identity keys it never had.

OpenVPN's tls-auth and tls-crypt options attach a static key to the control channel, adding an HMAC signature or encrypting the negotiation itself. That key is not a user password and does not replace the client certificate. Distinguishing the two matters at renewal time, when a password change leaves the control-channel key untouched.

WireGuard's PSK Adds, It Does Not Identify

WireGuard peers already have Curve25519 public and private keys, and the handshake authenticates those identities. An optional pre-shared key is mixed into the chaining key, contributing symmetric material on top of the public-key exchange.

It supplies no identity of its own and no user account, so an operator cannot tell two holders apart by their PSK. Both ends must carry the same value or the handshake fails without a helpful error. That is why rotation has to be planned for both sides at once rather than as a single-file edit.

Check Distribution, Rotation and Removal

Distribution is the weak point in every design that uses one secret in many places. A value pasted into a chat window, stored in a repository, or reused across environments acquires copies nobody can enumerate, and each copy quietly extends the blast radius.

Base64 text is not encryption. A secret stored next to a public certificate in the same directory is still a secret in the clear.

openssl rand -base64 32
sudo wg show wg0 preshared-keys
sudo grep -R -n 'psk' /etc/ipsec.d/ 2>/dev/null

Rotate on a schedule and after any suspected exposure, updating every intended peer before revoking the old value. Then test the link from both ends, because a mismatched key fails at the handshake and looks exactly like a firewall problem.

Document which secret protects which stage, so a password reset is never mistaken for renewing a cryptographic key. That one line saves an hour every time somebody audits the deployment.