Why a bigger OpenVPN key does not remove the rekey timer

Choosing AES-256 or a longer key says nothing about how long that key may be used. Key strength describes the algorithm; the rekey policy decides when the session derives new key material. A deployment can pick the strongest available cipher and still be wrong about renewal, because the two decisions are made in different places. Confusing them produces either an unnecessary cipher change or a session that silently outlives its policy.

Read the rekey settings before touching the cipher, and read both peers when you do.

Key strength and key lifetime answer different questions

The cipher and key size bound how expensive an attack on captured traffic would be. The rekey interval bounds how much traffic one key protects and how long a compromised key stays useful. Those are independent knobs, and a stronger cipher does not extend the safe lifetime of a session. Most guidance that says 'use AES-256' stays silent about renewal, because renewal is a policy question rather than an algorithm choice.

Record both in the deployment notes: what protects the data channel, and what triggers replacement of its keys.

Rekey has three triggers, and either peer can fire

OpenVPN 2.6 documents separate triggers for renegotiation based on bytes, packets and elapsed time. The time trigger is the one most deployments leave at its default, which means a quiet tunnel still rekeys on schedule. Either peer can start the exchange, and the peer that did not initiate it follows. Changing the timer on one side therefore does not set the behaviour of the session; the effective value is whichever side initiates first.

Byte and packet triggers matter for high-throughput or small-packet workloads, where a time-only policy would let one key protect far more data than intended. If those counters stay disabled, say so deliberately in the notes rather than leaving the default unexamined.

A rekey exposes the authentication workflow

A renegotiation is a fresh TLS handshake, which means the authentication path runs again. Deployments using one-time codes, hardware tokens or a RADIUS challenge discover this the hard way: the first connection works and the session dies an hour later when the second handshake asks for a code that has already been used. auth-gen-token exists to bridge that gap by letting the server issue a short-lived token for renegotiation instead of demanding a new interactive login.

Treat that as a workflow problem to solve with the operator, not as evidence that renewal should be switched off.

Test renewal under load, not in a one-minute session

An acceptance test that connects, pings once and disconnects never reaches the rekey. Run a session long enough to cross the configured trigger, keep a transfer running through it, and watch both peers' logs for the new handshake. Then test the failure path: what the client does if the renegotiation cannot complete. A tunnel that drops cleanly is easier to diagnose than one that keeps sending into a dead session.

Do not read a successful large transfer as proof of a cryptographic threshold. It only shows that the path and the counters survived that much traffic.

Document both choices

The record needs two lines: how packets are protected, and when that protection is replaced. Add the authority for each value, because the cipher may come from a distribution default while the timer comes from an internal policy. A future operator should not have to infer either from a config file.

If compatibility forces an exception, scope it to a version and an end date. An exception that outlives its reason becomes the policy nobody remembers choosing.