Hourly OpenVPN Drop: Renegotiation or a Real Reconnect?

Sixty minutes, or thirty, or a hundred and twenty: a drop that lands on a round interval is almost never the network. OpenVPN refreshes the key material that protects the data channel on a timer, and a timer shorter than the one you assumed looks exactly like a link that keeps failing. Users report a broken connection while the log reports a successful key exchange. The runbook below separates that refresh from a genuine restart, reads the value actually in force, and changes it only after the cost is on the table.

Work the steps in order, because the first one decides whether the rest of the page applies to you at all. Skip ahead and you will spend an evening tuning a timer for a fault that has nothing to do with it.

Tell a soft reset from a restart

The log line is the whole diagnosis. A renegotiation writes a soft reset and then a fresh key exchange inside the same tunnel: the interface keeps its address, routes are not re-added, and established TCP sessions usually survive with a pause. A real restart tears the session down, rebuilds the interface, may hand out a different client address, and kills every long-lived connection. Both events are ordinary; only one of them explains a dropped call.

journalctl -u openvpn-client@office -b --no-pager | grep -nE 'soft reset|Connection reset|reneg|TLS Error'
openvpn --version | head -n 1

The version line matters because log wording drifts between releases, and a message you remember from 2.3 may be phrased differently in 2.6. Read your own log rather than a forum excerpt of someone else's. Quote the exact line when you ask for help, because a paraphrase loses the detail that identifies the event. If the interface address is unchanged across the event and the session list survives, you are looking at a refresh and the remaining sections apply.

Read the effective timer, not your file

reneg-sec is the number of seconds between data-channel renegotiations and its default is 3600. Each peer carries its own value, and the smaller of the two is what actually triggers the refresh. That single rule explains most of the reports: a client profile that sets a large number still resets hourly while the server keeps the default.

grep -Rn --include='*.conf' -E 'reneg-sec|reneg-bytes' /etc/openvpn
# server side, including included files
grep -Rn -E '^reneg-sec' /etc/openvpn/server/

Read the server's effective configuration too, including anything it pushes, before drawing a conclusion from the client file. Then raise verbosity and watch one interval end to end: level 3 already shows the renegotiation lines, and the timestamps tell you whether the event repeats every 3600 seconds or follows activity instead.

Change it where it is actually pushed

The circulating cure is a single line in the client profile, and it is the wrong place about half the time. Because the lower peer value wins, a client that sets the timer to zero can still be renegotiated by a server that did not change.

# on both ends, or on the side that owns the pushed configuration
reneg-sec 0

Where profiles are generated centrally, edit the template rather than the deployed copy, or the next provisioning run will restore the value you just removed. Verify by watching two intervals, not one: a single quiet hour is consistent with a timer that was set to 7200.

Also decide what happens on a mixed deployment. Rolling the change out to clients first leaves a window in which the server still triggers the refresh, which is harmless but confusing if you are watching the logs for confirmation. Change the side that holds the smaller value first and the symptom disappears at the point you expect.

What disabling renegotiation gives up

Regular renegotiation limits how long a single set of data-channel keys protects traffic. Turning the timer off does not break the tunnel, and on a home router or a small office gateway the practical exposure is modest. It is still a trade, and the trade is worth stating before you make it. What changes is how long one key set protects a session, not whether the tunnel works at all.

The reasonable case for disabling it is a reset that breaks something which cannot resume: a call that drops, a remote desktop session that has to be re-established, a backup that restarts from the beginning. If the pause is invisible to users, leaving the default costs nothing and keeps the key rotation you were given.

Prefer fixing the cause when the pattern allows it. A refresh that fails partway while the first handshake succeeded points at the path rather than the timer: Look for a packet-size problem in the bigger control-channel exchange, a stateful firewall that drops the flow, or a proposal that only succeeds on the first attempt. Each of those leaves a trace in the same log you just read. Disabling the timer hides that evidence.

When the interval points somewhere else

Two neighbours in the configuration produce similar symptoms and different fixes. ping-restart restarts the tunnel when nothing arrives for a configured period, while ping-exit takes the client down entirely. An idle drop with no renegotiation anywhere in the log belongs to these, or to a NAT device that expired the UDP mapping on its own schedule.

Consumer routers, mobile hotspots and carrier-grade NAT all expire idle UDP sessions without telling anyone. That failure follows idleness rather than the clock, which is the tell: a session that drops after ten quiet minutes and survives an hour of steady traffic is not renegotiating.

Write down three things before you change a fourth: the interval you measured, the effective value you found, and the command that showed it. If the interval moves when the timer moves, the mechanism is identified and the fix is a decision about the trade above. If it does not move, put the setting back and keep looking at keepalives, NAT state and packet loss.