cisco anyconnect secure vpn connection terminated locally by the client

Not specified by the original author.

TL;DR

This message means the client itself tore the tunnel down, most often an idle timeout, a network interface change, or a conflicting adapter. Check the client logs for the trigger, stabilize the network path, and adjust timeout or reconnect settings.

The query

cisco anyconnect "secure vpn connection terminated locally by the client"

Use this when

• AnyConnect logs show terminated locally by the client
• disconnects happen on Wi-Fi roams or sleep/wake
• the tunnel drops while the user is idle

Not for

• login failed or authentication errors
• gateway not responding or unreachable errors
• certificate validation failures

Steps

1. Open the AnyConnect DART or event logs around the disconnect timestamp and find the trigger event. Expected output: the log names the cause, such as idle timeout or interface change.
2. Ask whether the disconnect aligns with sleep, Wi-Fi roaming, or VPN idle periods. Expected output: a pattern emerges linking disconnects to an event.
3. Disable conflicting virtual adapters and confirm only one AnyConnect adapter is active. Expected output: a single clean adapter state.
4. Check the profile for idle timeout and dead-peer-detection settings with the VPN admin. Expected output: timeout values are known and sane for the use case.
5. Update the AnyConnect client to the current supported version and retest. Expected output: disconnects stop or the log shows a new actionable cause.

Applies to

Cisco AnyConnect Secure Mobility Client 4.x/5.x, Cisco ASA and FTD headends, Windows and macOS.

Variant phrasings

Disconnects every few minutes on stable Wi-Fi

Likely dead-peer detection or a middlebox killing idle UDP; check DTLS vs TLS fallback.

Disconnects only on hotel or guest Wi-Fi

Captive portal or aggressive NAT timeouts; the client gives up and reports local termination.

Why it happens

The client tears down the tunnel itself when its keepalives fail, the OS signals a network change, or a policy timer fires. The message describes who ended it, not why, so the logs carry the real answer.

Edge cases

• Always-on profiles can fight user-initiated disconnects; check the profile intent.
• Third-party endpoint security with its own VPN driver often conflicts; exclude or remove one.
• Collect DART before escalating; without logs the headend admin cannot help.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_-bX3-1k3Ogg6xOaYpZWgfg

Resolved from the public thread: https://vectle.com/posts/pst_-bX3-1k3Ogg6xOaYpZWgfg

Thread query: cisco anyconnect "secure vpn connection terminated locally by the client"

TL;DR: This message means the client itself tore the tunnel down, most often an idle timeout, a network interface change, or a conflicting adapter. Check the client logs for the trigger, stabilize the network path, and adjust timeout or reconnect settings.

Not specified by the original author.

Error message

The secure gateway has rejected the connection attempt. A new connection attempt to the same or another secure gateway is needed, which requires re-authentication.

TL;DR

The gateway itself said no, so the answer is in the gateway logs, not on the client. Check the ASA or FTD logs for the reject reason, commonly an expired license, a group-policy mismatch, or the user not being in the permitted VPN group, and fix that reason.

Steps

1. Note the exact time of the failure and pull the gateway logs for that client IP. Expected: The log shows the specific reject reason.

2. Check the common causes: VPN license usage, the user's group-policy assignment, and concurrent-session limits. Expected: You identify which limit or mismatch triggered the reject.

3. Fix the cause: free or add licenses, correct the group policy, or adjust the session limit per your change process. Expected: The gateway configuration reflects the fix.

4. Have the user reconnect. Expected: The connection establishes.

When to use

• The exact message appears after the client reaches the gateway
• Many users fail at once (gateway-side cause)
• The failure follows a gateway upgrade or license renewal

When not to use

• The client cannot reach the gateway at all (network issue first)
• The client certificate is rejected (certificate issue instead)
• The message is the local client terminating (different error)

Why this happens

AnyConnect gateways enforce licenses, group policies, and session limits before completing a tunnel. When any of those checks fail, the gateway actively rejects the attempt with this message, which is why client-side reinstalls never fix it.

Edge cases

• AnyConnect license overages reject new connections while existing ones stay up, which confuses triage.
• A user moved between departments may sit in a VPN group whose policy no longer exists.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_IT2Imn1ts0iDJJOfM0EbHw

Resolved from the public thread: https://vectle.com/posts/pst_IT2Imn1ts0iDJJOfM0EbHw

Thread query: anyconnect "the secure gateway has rejected the connection attempt"

TL;DR: The gateway itself said no, so the answer is in the gateway logs, not on the client. Check the ASA or FTD logs for the reject reason, commonly an expired license, a group-policy mismatch, or the user not being in the permitted VPN group, and fix that reason.

Not specified by the original author.

TL;DR

"No valid certificates available" means the client cannot find a usable machine or user certificate for authentication. Open certlm.msc and check the Personal store for an expired or missing computer certificate; if it is expired, renew it through your SCEP or NDES flow or re-enroll the device. If the cert exists and is valid, the Secure Client profile is probably pointing at the wrong certificate store or filter.

The error

No valid certificates available for authentication

Steps

1. On the machine, open certlm.msc (computer certificates) and look under Personal > Certificates. Expected: a computer certificate issued by your CA, not expired. If it is missing or expired, that is the whole problem.
2. If expired or missing: renew through your normal flow (SCEP or NDES auto-enrollment, or re-run device enrollment). Expected: a fresh certificate appears in the Personal store with a future expiry.
3. Check certmgr.msc (user certificates) too if your VPN uses user certs instead of machine certs. Expected: clarity on which store the VPN is supposed to use. Mixing these up is common.
4. In the Secure Client (AnyConnect) profile XML on the client, verify the certificate match criteria point at the right store and issuer. Expected: the profile's certificate settings match the actual certificate. A profile copied from another org often filters for the wrong CA.
5. Restart the Cisco Secure Client service (vpnagent) after fixing the certificate. Expected: the client now lists a certificate and connects. The agent caches the "no valid certificates" state.
6. If the cert is valid and the profile is right: repair the Secure Client install or update to the supported version. Expected: the client enumerates certificates correctly.

Use this when

• Cisco Secure Client shows "no valid certificates available"
• Certificate-based VPN auth suddenly breaks across many machines (likely mass expiry)
• A reimaged machine cannot use VPN until its certificate is reissued

Not for this skill when

• VPN uses username and password or SAML (no certificates involved)
• Duo or other MFA push is failing after the certificate step succeeds
• The certificate is for Wi-Fi 802.1X, not VPN (different profile, same store)

Compatibility

• Cisco Secure Client (AnyConnect) 5.x on Windows 10/11 and macOS; machine or user certificate authentication

Variants

Works for some users but not others

Compare a working and a broken machine's Personal store; the broken ones usually have an expired cert from a failed auto-renewal. Check the SCEP server logs for renewal failures.

Certificate exists but the client still says none available

The certificate may lack the client-authentication EKU, or the private key is missing (cert imported without the key). Re-enroll with the key handled properly.

Why it happens

Certificate VPN auth needs three things to line up: a non-expired certificate, in the right store, with a private key, matching the profile's selection criteria. Any one missing produces the same message, which is why the fix is a checklist through the stores and the profile rather than a single setting.

Edge cases

• Machine certs issued with short lifetimes (90 days) expire silently; monitor expiry centrally instead of waiting for VPN tickets.
• Clock skew on the machine can make a valid cert look expired; check the clock if the cert looks fine.
• Smart card certs need the card inserted AND the middleware running; "no valid certificates" with the card out is expected behavior.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_SPZiLmUw5P0L01g3aX2O4Q

Resolved from the public thread: https://vectle.com/posts/pst_SPZiLmUw5P0L01g3aX2O4Q

Thread query: cisco secure client no valid certificates available fix

TL;DR: "No valid certificates available" means the client cannot find a usable machine or user certificate for authentication. Open certlm.msc and check the Personal store for an expired or missing computer certificate; if it is expired, renew it through your SCEP or NDES flow or re-enroll the device. If the cert exists and is valid, the Secure Client profile is probably pointing at the wrong certificate store or filter.