Cisco ASA limits the number of concurrent remote-access VPN sessions a user can maintain. The default is three. When a user hits the limit, a new connection can fail or an existing idle session can be removed, depending on the configured limit and session state.
The CLI knob is still vpn-simultaneous-logins, but treat it as a session policy, not a workaround for shared credentials. Individual identities with MFA, auditable authorization, and a deliberate session limit are the normal design. Raising the limit for a whole group because several people share one account turns an operational inconvenience into an accountability problem.
Find the Actual Problem First
Before changing a limit, confirm that the user is actually exhausting concurrent sessions. Look for a client error and inspect active sessions and the applicable group policy. The exact operational commands differ by ASA release and VPN type, but the key questions are consistent:
- Is this one person reconnecting after a network failure or sleep/wake cycle?
- Is there a stale AnyConnect, IPsec, or clientless session?
- Does the user legitimately need more than one active device?
- Is a shared account hiding the real problem?
- Is the configured group policy the one applied by the connection profile and identity attributes?
Fix stale sessions and identity mapping before increasing a limit. Otherwise the limit merely makes the next failure take longer to notice.
Set a Limit for a Group Policy
To set the limit for every user governed by a specific group policy, enter group-policy attributes mode:
ciscoasa# configure terminal
ciscoasa(config)# group-policy REMOTE_ENGINEERING attributes
ciscoasa(config-group-policy)# vpn-simultaneous-logins 2
ciscoasa(config-group-policy)# end
ciscoasa# write memory
This example allows two concurrent sessions for users of REMOTE_ENGINEERING. Pick the smallest number that supports the real work. A laptop plus a phone or a legitimate reconnect pattern might justify two; a much larger number deserves a clearer business and security reason.
Cisco documents a default of three and accepts an integer value. 0 disables login for the policy, so do not use it as a shorthand for "unlimited." Use the no form to remove an explicit value and return to inherited/default behavior:
ciscoasa# configure terminal
ciscoasa(config)# group-policy REMOTE_ENGINEERING attributes
ciscoasa(config-group-policy)# no vpn-simultaneous-logins
Use a Per-User Exception Sparingly
If one person has a justified exception, scope it to that identity instead of changing every user in the group policy:
ciscoasa# configure terminal
ciscoasa(config)# username alice attributes
ciscoasa(config-username)# vpn-simultaneous-logins 2
ciscoasa(config-username)# end
ciscoasa# write memory
This is the safer operational choice when a small set of support engineers, service owners, or test users need a second session. Document why the exception exists and review it. Per-user exceptions have a habit of becoming permanent configuration fossils.
Understand What Happens at the Limit
The behavior is not simply "the fourth login is rejected." Cisco notes that stale sessions can remain after an abnormal client termination. With a limit of one, a new login can replace a stale session; with a higher limit, the ASA may remove the longest-idle session when the maximum is reached. The teardown can take time, so a new connection may need to retry.
That means a higher limit can hide a client or network problem, while a very low limit can inconvenience a user who moves between Wi-Fi networks, sleeps a laptop, or uses a phone as a backup connection. The correct policy depends on the operational scenario, not a universal best practice.
The ASA also supports vpn-simultaneous-login-delete-no-delay for group policies. Do not add it by reflex. Immediate deletion changes the user experience and should be tested against the authentication flow and support expectations before deployment.
Verify Scope Before and After the Change
The configuration line is short; proving that it affects the intended users is the real work. Before a change, collect the matching connection profile, group-policy configuration, and a sample of current remote-access sessions. Afterward, test with a non-privileged account that represents the affected population and confirm both the expected second-login behavior and the behavior at the limit.
Useful inspection commands vary by release and deployment, but these are common starting points:
ciscoasa# show running-config group-policy REMOTE_ENGINEERING
ciscoasa# show running-config username alice
ciscoasa# show vpn-sessiondb summary
Use them to answer concrete questions: does the named policy contain an explicit value, does the user have an override, and did active-session counts change as expected? Do not make a bulk policy change because a single client reported an error string. The same error can arise from authentication failures, authorization changes, network interruptions, or stale state.
If your identity provider maps users into ASA policies dynamically, include that mapping in the test plan. A correct-looking group-policy stanza is useless if the connection profile or authorization rule assigns the user elsewhere. In mature environments, the approved test account and rollback procedure should be part of the change ticket, not discovered at 2 a.m.
Capacity and Licensing Are Separate Questions
vpn-simultaneous-logins governs how many sessions one identity can hold; it does not increase the appliance's overall remote-access capacity, bandwidth, authentication throughput, or entitlement. If many legitimate users are being denied at the same time, investigate platform capacity and the broader remote-access design rather than giving every account a larger per-user allowance.
That distinction matters during an outage. Raising a user-level limit can temporarily mask reconnect storms after an upstream network event, but it may also leave more sessions consuming resources while the real issue persists. Observe the connection pattern, preserve enough logs for the postmortem, and remove temporary exceptions when the incident is resolved.
Avoid the Shared-Credential Trap
Older VPN deployments sometimes used a shared account for a vendor, a temporary project, or a small team. Do not increase simultaneous-login limits to preserve that model unless there is a documented short-lived exception with compensating controls.
Shared credentials make it difficult to answer basic questions after an incident: who connected, who downloaded a file, and whose MFA factor approved the session? Prefer named accounts backed by the identity provider, group-based authorization, expiration dates for external access, and MFA. If the issue is licensing or capacity, solve that explicitly rather than using one account as an unofficial connection pool.
A Change Checklist
- Identify the affected user, connection profile, group policy, and authentication source.
- Capture the existing relevant configuration and active-session evidence.
- Decide whether the policy belongs on one named user or the group policy.
- Apply the smallest justified value in the approved change window.
- Test a new connection and confirm that normal disconnect/reconnect behavior remains acceptable.
- Save the configuration and record the reason, scope, and review date.
If the symptom is failed authentication rather than session count, start with troubleshooting Cisco TACACS+ "no address for get_server". For the broader habit of making network behavior observable before tuning it, see Cisco load-interval 30: When to Use It and When to Leave It Alone.
Cisco's current ASA VPN configuration guide and command reference document the supported syntax and session behavior. Verify the release-specific guide for the firewall you operate. Return to Slaptijack for more practical infrastructure guidance.
