The VPN session timer and the auth token expire separately
A gateway session limit, an idle timer and a reusable authentication token expire under different rules. The error line at the drop tells you which one.
A VPN drop can happen for reasons that look identical from the client and share nothing underneath: the tunnel session ended, an idle timer fired, or a credential the client was reusing went stale. Each has a different owner and a different fix. The error sequence at the moment of the drop is what separates them, and it is usually one line.
Three clocks run against one tunnel, and only one of them is the tunnel.
Three different clocks on one tunnel
The session clock belongs to the gateway: a maximum connection duration, an idle timeout, or both, and it terminates the tunnel when either is reached. The token clock belongs to the authentication system, and it decides how long a credential can be presented again without a human. The path clock belongs to whatever NAT or firewall sits between client and gateway, and it expires mappings for flows it considers finished. All three produce a disconnect, and none of them produce the same log line.
Only the first is a VPN concept. The other two are borrowed from identity and networking, and they are routinely mistaken for it.
How the token is actually reused
OpenVPN servers can issue an authentication token after the initial login, so a control-channel renegotiation does not ask the user for credentials again. The client keeps presenting that token and the server decides how long it stays acceptable. When the token lifetime is shorter than the renegotiation interval, the next renegotiation fails and the client reports an authentication error instead of a timeout. That is why the same profile works for an hour and then fails at a fixed point.
The renegotiation interval is a separate setting. Changing it moves when the token is presented, not how long it lives.
What each expiry looks like from the client
A session timeout usually arrives as a clean disconnect with a server-side reason, often after a predictable duration and with no authentication error attached. An idle timeout looks like silence: the tunnel stops carrying traffic, then the keepalive gives up. A token expiry arrives as AUTH_FAILED in the middle of a session that was working a second earlier.
Read the line, then look at the clock. A duration that matches a configured value is not a coincidence.
Why a saved password does not help
A cached password answers a challenge for a password. It does not extend a token lifetime, and it does not satisfy a challenge for a second factor or a device posture check. Raising retry frequency, lowering connection timeouts or reimporting the profile changes nothing about how long the identity system will accept the credential.
The durable fixes are the right lifetime on the right object, or a client flow that can complete the required challenge without a human.
What to document and test
Write down all three values: the gateway session and idle limits, the token lifetime, and the shortest relevant mapping timeout on the path. Then test each expiry deliberately by shortening one value, watching what the client reports, and restoring it. Confirm what the user must do at each boundary, because requiring a full login every hour is a policy decision somebody should have made on purpose.
A drop that arrives with no authentication event at all belongs to the path or the idle timer, which is a different investigation with different evidence.