Managing and understanding sessions

About the sessions, connections, and reconnect seed that the gateway maintains

To optimize the parameter settings for your network environment, it's important to understand the types of sessions and connections that the Blue Cedar Connect Gateway maintains and the role of the reconnect seed that the gateway sends to the secured app.

Tunnel sessions and federation sessions

For tracking purposes, the gateway maintains two types of sessions:

A session for each active app within a federation.
The gateway uses this tunnel session to track whether an app has an active tunnel connection. If an app is inactive for a specified amount of time, the gateway closes the connection and deletes the data associated with the active tunnel session.

The gateway supports two types of tunnels—app tunnels for traffic for individual apps, and full tunnels for all traffic from a device.
Note: Use the dpd parameter to optimize how long the gateway keeps a connection alive if no activity has occurred. Setting this parameter helps improve the performance of the gateway in managing all of its concurrent connections. Inactive connections are cleaned up, which frees up resources for the gateway to maintain the connections that are active. This is especially important when scaling up the number of concurrent per-app connections.
A session shared by all of the apps in the federation of apps on the user's device. (Unfederated apps are considered to be in their own groups of a single app each.)
The gateway uses this federation session to track whether at least one app in an app federation is connected to the gateway or not. This session goes "dormant" when no app in the app federation is connected to the gateway, or when there is no network activity within the federated apps. If the federation session remains dormant and reaches the configured timeout limit, the gateway destroys the federation session.
When this occurs, the Blue Cedar-secured client must re-authenticate itself to the gateway to re-establish the connection. Upon successful re-authentication, the gateway re-creates the federation session for that group of apps.

You can check the status of the sessions with this command:

BASH

> show status operational context default aaa-operational session-diagnostics

Reconnect seed

After the two types of sessions are created, the gateway sends a "reconnect seed" to the secured app. The reconnect seed is shared by each app belonging to the same app federation. The seed serves as a substitute for a user's credentials so that the app can automatically and securely reconnect to the gateway without requiring the user to re-enter their credentials.

The secured app converts the seed into a "token" that is sent back to the gateway when the app wants to reconnect. The gateway receives this token and upon verifying its authenticity, the gateway re-establishes the connection ("tunnel session") to the app.

This results in the user not having to re-submit their credentials every time they want to reconnect.

By default, the reconnect seed is enabled on the gateway. The only time you would disable the seed is for troubleshooting purposes. To disable the seed, use this CLI command:

BASH

% set aaa auth-group groupname reconnect-enable false

The following figure illustrates how the gateway tracks the tunnel and federation sessions in relationship to how long a connection has been inactive.

How the gateway tracks a session's connectivity

Session states

The session-diagnostics status shows info for these session states:

BASH

> show status operational context default aaa-operational session-diagnostics

Session state	Description
short-lived	A tunnel session is considered short lived, from the initial transaction until the client either fully establishes the IPSec tunnel following a successful authentication, or the tunnel session is destroyed due to reasons like invalid authentication or timeout.
cached	After the tunnel session is successfully authenticated, it is associated with a federation session (either a new or existing one). A cached session is a federation session. It's created when the first tunnel in a federation has successfully authenticated, and is terminated when the last tunnel session in a federation is deleted.
dormant	A federation session is considered dormant when the last tunnel session in the federation session is disconnected. If a tunnel session is established which is a part of a dormant federation session, the federation session transitions back to a cached session.