Troubleshooting AnyConnect
This section maps common symptoms to root causes and concrete actions. Use it as a decision tree: start with the error you see, confirm with logs, and apply the smallest change that proves or disproves a hypothesis.
Handshake and tunnel establishment
TLS/DTLS negotiation fails
Check reachability to TCP/443 and UDP/443 on the gateway. If TLS inspection is present, bypass the gateway FQDN and CA issuer. Export client logs: look for certificate chain errors, SNI mismatches, or MTU‑related resets. On the headend, confirm the cert matches the hostname and includes the SAN entries users connect to.
Authentication errors
Password failures are obvious; SAML loops are trickier. Validate IdP metadata, time synchronization, and that the redirect URI is allowed. For RADIUS, test with a known account; confirm the group‑policy mapping attributes are received.
Connected, but no access
Inspect routes and DNS. In split‑tunnel mode, are internal subnets included? Are DNS suffixes applied? Try to resolve an internal FQDN. If ping by IP works but names do not, focus on DNS; if names resolve but apps timeout, inspect ACLs and security policies.
Diagnostics workflow
- Reproduce the issue with logging enabled. Note timestamp and user.
- Confirm IP assignment and group‑policy. Compare to a working user.
- Trace DNS: verify which resolver is used and the search domain order.
- Check MTU. If web pages partly load, try smaller packets and adjust MSS clamping on the headend.
- Look for overlapping routes with local adapters (Wi‑Fi, docks, VMs).
When collecting packet captures, capture both the physical adapter and the tunnel interface to see encapsulation boundaries.
Operational pitfalls and fixes
Expired certificates, changed IdP metadata, and DNS changes are responsible for most widespread incidents. Track certificate expiry with alerts and rotate early. When changing identity providers, stage the new metadata on a pilot gateway and validate logout/SSO flows. For DNS, avoid relying on a single resolver; deploy redundant resolvers reachable through the tunnel and advertise them consistently via group‑policy.
Client‑side conflicts also matter. Endpoint firewalls and content filters may block DTLS or intercept TLS. Device sleep states can break the tunnel after wake; enable auto‑reconnect and consider idle timeouts that fit real usage. If users report that only some SaaS apps fail on VPN, check whether split‑tunnel excludes those prefixes or whether public DNS responses resolve to geo‑localized CDNs unreachable through corporate egress.
Quick links: Guides · Download · Troubleshooting