What a VPN Nonce Is, and Why Reuse Breaks the Tunnel

Most people meet the word nonce in a VPN profile and assume it is another shared secret to copy between peers. It is not. A nonce is a value that must never repeat under the same key, and in most nonce-based encryption it travels in the clear. The confusion stays harmless until someone edits it by hand, which is where real breakage begins.

Where the nonce actually comes from

Authenticated encryption needs a different nonce for every message encrypted under a key. Protocols satisfy that requirement in different ways: a monotonically increasing counter, a salt combined with a packet identifier, or a sufficiently long random value. IKEv2 exchanges nonces during the initial exchange, and they are public inputs to key derivation rather than secrets.

Uniqueness can be structural or probabilistic. A counter cannot repeat until it wraps, which is why the protocol defines a rekey point long before that. A random value relies on enough bits that a collision is implausible within the message limit, which is a different argument with a different failure mode. The protocol documentation names which method applies, and both are safe only while the stated limit is respected.

What reuse actually costs

Reusing a nonce under one key is not a minor efficiency question. With GCM, two messages sharing an IV let an observer recover the authentication key and compute the exclusive-or of the two plaintexts. Stream-based constructions reuse keystream in the same way, which turns ciphertext into a puzzle instead of a secret.

That is why implementations rekey before a counter wraps, and why they stop rather than continue when their state is uncertain. A reboot that resets a counter while the peer still holds the old key, or a virtual machine restored from a snapshot taken mid-session, is exactly the situation the limits exist to prevent. No attacker is required; ordinary operations are enough.

Why hand-editing is the wrong fix

Counters, salts and packet identifiers are state machines shared by both ends. Changing one side desynchronises the other, and the tunnel fails in ways that look like a routing problem. The supported lever is a fresh key exchange, which resets the state on both ends at once.

Passwords and nonces also play different roles. A password is secret input to key derivation; a nonce is public per-message input. A profile field labelled nonce that asks for a long secret is usually a static key or a pre-shared secret under a different name, so read the documentation for that field instead of assuming.

When an advisory concerns nonce handling, the repair is the maintainer's fixed version, not a different cipher or a shorter key. Changing the cipher to avoid the word nonce moves the problem rather than solving it.

Reading a warning without guessing

A log line about counters or nonces usually describes lost state rather than an attack. Check whether one peer restarted, whether a cloned virtual machine reused the same identity, and whether the two ends agree on rekey settings. Then establish a new session and watch whether the message returns.

Keep the diagnosis separate from unrelated failures. A page that will not load, or a credential prompt that loops, is not evidence of nonce reuse, and treating it as one sends you into the cryptographic layer when the problem is above it.

For ordinary use, the safe rule is short: let the implementation manage the nonce, keep both ends on supported versions, and treat any state reset as a reason to rekey rather than to edit a value. If a profile field is not in the vendor's documentation, do not invent a value for it. Fixing the tunnel starts with knowing which layer you are looking at.