Access Server's Session Tokens⁠

Default values at a glance⁠

To adjust these values, refer to Tutorial: How to Change Access Server's Session Tokens.

Why session tokens matter⁠

Session tokens make VPN connections more resilient and secure without requiring users to re-authenticate constantly.

• Seamless reconnection — When a connection is briefly interrupted, due to network instability or a cluster node failure, the VPN client can resume the session using its token rather than starting a new authentication flow. In a cluster setup, the HMAC key is shared between nodes, so a session started on one node can resume on another. This makes session tokens essential for high availability.

• MFA and certificate handling — When multi-factor authentication is enabled, session tokens mean users aren't prompted for their MFA code during routing TLS key renegotiations or brief reconnections. Server-locked profiles also benefit: without session tokens, these profiles would require authenticating twice in sequence.

• Credential security — Because the session token handles re-authentication, Access Server doesn't need to hold user credentials in memory between authentications. This reduces the credential exposure surface during an active session.

How session token validation works⁠

When the VPN client presents a session token, Access Server runs three checks before accepting it:

1. HMAC signature — The server verifies the token's HMAC signature to confirm it was issued by a trusted Access Server and hasn't been tampered with.

2. Session age — The session start timestamp in the token must be no older than the value of vpn.server.session_expire. If not explicitly configured, this defaults to approximately 24 hours.

3. Token age — the token creation timestamp must be no older than twice the TTLS key renegotiation interval. With default settings, this means a token is valid for up to 2 hours (2 × 60 minutes).

If all three checks pass, the server and client negotiate new encryption keys, and the session resumes. Access Server issues a new token to the client that keeps the original session-start timestamp but carries an updated creation timestamp.

If any check fails, the session ends, and the user needs to authenticate again.

Session lifetime and how it works⁠

An active VPN session stays alive as long as the current TLS encryption key is valid. A new TLS key can be obtained either through full authentication or through a successful session token exchange.

With default settings, a single VPN session works like this:

• Access Server forces a TLS key refresh every 60 minutes.

• A session token is valid for 120 minutes (2 × the TLS interval), so it can cover at least two renegotiations.

• The overall session expires after approximately 24 hours, after which the session token can no longer be used to obtain a new TLS key.

• A typical uninterrupted session uses four TLS keys before the session expires.

Automatic client inactivity disconnect threshold⁠

Access Server can instruct a connected VPN client to gracefully disconnect when the connection is idle. Idle state is determined by a byte-transfer threshold over a specified time frame. When traffic falls below this threshold, the client disconnects automatically.

To configure the inactivity threshold, refer to Tutorial: Set the Threshold to Disconnect Inactive Clients.

See also⁠

• Tutorial: How to Adjust Access Server's Session Tokens — CLI commands for configuring VPN session token settings.

• Tutorial: How to Change the Web Session Timeout — configure web UI session inactivity timeout and maximum renewal time.

• Tutorial: Set the Threshold to Disconnect Inactive Clients — configure automatic disconnect for idle VPN sessions.