Skip to main content

Access Server's Session Tokens

Abstract

How do session tokens work in Access Server, and what are your OpenVPN tunnel session management options? Find answers here.

Access Server implements session-token-based authentication. After a normal successful authentication, the server sends a session token to the VPN client. Each time the VPN client must authenticate again, it offers this session token to the server. If the session token passes validation checks on the server side, the client is allowed to resume the VPN session.

Session token use cases

A session token contains a unique session ID, timestamps for the beginning of the VPN session, and when the token was issued. It is authenticated and signed with HMAC. For a cluster setup of Access Servers, the HMAC key is shared between member nodes. This allows a user who started his VPN session on one Access Server cluster node to resume his session on another Access Server cluster node, which is useful for high availability.

Use case examples for Access Server's session tokens:

  • TLS encryption key renegotiations can succeed without the user having to enter credentials mid-session.

  • After a transient connection interruption the session can resume gracefully.

  • When an Access Server cluster node fails, its users can migrate gracefully to another node.

  • When multi-factor authentication is enabled there is no need to interrupt the user in the above cases.

  • Server-locked profiles don’t need to repeat authentication twice in a row.

  • It can enhance security by not having to remember user credentials in memory.

    Note

    Auto-login profiles do not need or use session tokens, they authenticate by their certificates only.

Session token validation

Access Server validates the session token when it is offered by the VPN client. It must pass the following checks to be accepted as a valid authentication method:

  1. The server verifies the HMAC signature on the session token.

  2. The session start timestamp in the session token must be no older than the vpn.server.session_expire configuration key’s value in seconds. If not explicitly set, this defaults to about 24 hours.

  3. The session token creation timestamp must not be older than two times the length of the TLS key renegotiation value. If not explicitly set, this defaults to a period of two hours (2x1 hour).

Once validation passes on all points, the server and client agree on new encryption keys and allow the session to resume. The server provides the VPN client with a new session token that retains the same original session-start timestamp but has an updated creation timestamp.

If validation fails on any of these points, the session is ended, and the user must go through the authentication phase again to establish a VPN connection.

Session lifetime and expiration settings

An active VPN session can continue if the current TLS encryption key is valid. To obtain a TLS encryption key, you must either successfully complete normal authentication or a successful session token authentication. It is important to understand and configure the session timeout correctly.

Access Server will force a TLS key refresh every hour by default (as of Access Server 2.9.3). The lifetime of a session token is twice the TLS key refresh value. The overall session expiration is set to nearly 24 hours — after that, a new TLS key can’t be obtained using the session token, and the VPN session ends when the TLS key’s usefulness expires. Assuming an uninterrupted VPN session results in four TLS keys being used in a single VPN session. After successful authentication, the first TLS key is provided, and the second, third, and fourth ones are obtained using the session token.

Take the following example to help understand session tokens. A VPN session is interrupted due to a transient connectivity issue and resumes at the 23 hours and 50 minutes mark. The VPN client reconnects and uses the session token. The VPN server accepts the token as it falls within the 24-hour overall session timeout. A TLS key is negotiated with the VPN client. After one hour, the server forces TLS key renegotiation. Now, the session token can’t be used for authentication to obtain a new one as the 24-hour overall session has timed out. It follows that with default settings, a VPN session may last up to 24-25 hours approximately before the last obtained TLS key is forced into renegotiation, and the VPN session ends because a new TLS key can’t be obtained with the available session token. The user must enter their credentials again to establish a VPN connection.

Automatic client inactivity disconnect threshold

Access Server can push a command to a connected OpenVPN client with the instruction to gracefully disconnect when the connection is in a very low-use state (idling). This is determined by a threshold of the number of bytes transferred over a span of time. When the OpenVPN tunnel is not being actively used, the OpenVPN client automatically disconnects itself.

To adjust the threshold setting, refer to Tutorial: Set the Threshold to Disconnect Inactive Clients.

In this section: