OpenVPN tunnel session management options

Upgrade to Latest Version

Session tokens in Access Server

OpenVPN 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.

A session token contains a unique session ID as well as timestamps for the beginning of the VPN session and when the session token was issued. The session token 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 that started his VPN session on one Access Server cluster node to resume his session on another Access Server cluster node. This is useful for high-availability.

These are use-cases for the session token in Access Server:

  • 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.

Validation of session tokens

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 not be 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 12 hours (2x6 hours).

Once validation passes on all points, the server and client agree on new encryption keys and allow the session to resume. The server provides a new session token to the VPN client that retains the same original session-start timestamp. The new session token 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 in order to establish a VPN connection.

Session lifetime and expiration settings

An active VPN session can continue as long as the current TLS encryption key is valid. Normal successful authentication or a successful session token authentication is required to obtain a TLS encryption key. This is important to understand and configure the session timeout correctly.

By default Access Server will force a TLS key refresh every six hours. 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 time 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, this results in a total of four TLS keys being used in a single VPN session. The first TLS key is provided after normal successful authentication, 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 six hours, 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 then that with default settings, a VPN session may last up to 24-30 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.

The commands below show how to change the default values for the settings and define new behavior. All commands are expected to be run as root user in the /usr/local/openvpn_as/scripts/ directory.

Set session token timeout in seconds (default 86100 seconds or approximately 24 hours):

./sacli --key "vpn.server.session_expire" --value <SECONDS> ConfigPut
./sacli start

Remove this value to reset it to default:

./sacli --key "vpn.server.session_expire" ConfigDel
./sacli start

Change the mid-session TLS renegotiation period (default 360 minutes or six hours):

./sacli --key "vpn.tls_refresh.interval" --value <MINUTES> ConfigPut
./sacli start

Restore this value to default by deleting it:

./sacli --key "vpn.tls_refresh.interval" ConfigDel
./sacli start

Note: If you set the value to an extremely high setting such as 99999999999, it effectively disables the session token expiration. We advise against this. If you need a session to never require authentication please use auto-login type profiles as they do not use session tokens at all.

Automatic client inactivity disconnect threshold

Access Server can push a command to a connecting 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. This setting can be set on the __DEFAULT__ meta user to apply it to all users and groups, or it can be set on a group or a user. Since even when you do nothing, some traffic may still be transferred, determining your specific thresholds depends on your normal background bandwidth use. For a best guess at this, sign in to your Admin Web UI, and click on Current Users. This displays the bytes sent by active VPN connections, which you could use to get an idea of what normal background bandwidth use is, and set the threshold just above that. The data is added up for both transmit/receive so if you upload 10 kilobytes and download 20 kilobytes the total is 30 kilobytes of traffic. As an example, if the connection is not actively used, and you see 50 kilobytes over a period of five minutes, then consider setting the threshold to 100 kilobytes over a period of five minutes. Then the connection will be dropped automatically if the connection is transferring less than 100 kilobytes in a five minute period. You will obviously need to experiment with this a bit to suit your situation.

Use the commands below to set these thresholds, using these values:

  • prop_isec: number of seconds over which to sample bytes in/out
  • prop_ibytes: minimum number of bytes over prop_isec to allow connection to continue

Disconnect when transmit/receive is below 100000 bytes over a period of five minutes:

./sacli --user <USER_OR_GROUP> --key "prop_isec" --value 300 UserPropPut
./sacli --user <USER_OR_GROUP> --key "prop_ibytes" --value 100000 UserPropPut
./sacli start

Note: This setting does not override session token expiration. The overall session timeout takes priority over this activity threshold. Furthermore, it is up to the VPN client to respect the disconnect — it may be ignored. And if you redirect all client internet traffic through the VPN, it will be harder to define the exact threshold to disconnect a user compared to simply using a split-tunnel setup where only specific traffic goes through the OpenVPN tunnel.