How to Configure AnyConnect VPN on Cisco ASA Firewalls: SSL VPN Setup and Deployment Guide

AnyConnect is Cisco’s flagship SSL VPN client, and while it shares foundations with general remote access VPN concepts, deploying it well as an enterprise-wide client — with software distribution, connection profiles for different device types, always-on behavior, and lifecycle management — is its own discipline. This guide focuses specifically on the AnyConnect client deployment lifecycle: getting the client onto endpoints, tuning the SSL/DTLS transport itself, and running it reliably at scale.

SSL VPN and DTLS: The Protocol Fundamentals

AnyConnect’s SSL VPN tunnel operates over two possible transports simultaneously negotiated during connection setup:

• TLS (TCP 443) — always available as the baseline, reliable but subject to TCP-over-TCP performance penalties on lossy networks, since retransmission happens at both the outer TLS/TCP layer and the inner application TCP layer.
• DTLS (UDP 443 by default) — a datagram-based TLS variant that avoids the TCP-over-TCP problem, generally preferred for latency-sensitive or lossy-network scenarios (video calls, VoIP, general responsiveness over Wi-Fi/cellular).

AnyConnect automatically negotiates DTLS when available and falls back to TLS-only if UDP 443 is blocked somewhere in the path — which is exactly why many corporate/hotel/airport networks that block outbound UDP force AnyConnect users into a TLS-only, noticeably slower experience without an obvious cause unless you know to check for it.

Step 1: Prepare the ASA for AnyConnect

Enable WebVPN on the Outside Interface

enable
configure terminal

webvpn
 enable outside
 dtls port 443

Upload the AnyConnect Client Package(s)

Multiple OS images can be loaded simultaneously; the ASA auto-detects the connecting client’s OS and serves the correct package:

webvpn
 anyconnect image disk0:/anyconnect-win-4.10.07061-webdeploy-k9.pkg 1
 anyconnect image disk0:/anyconnect-macos-4.10.07061-webdeploy-k9.pkg 2
 anyconnect image disk0:/anyconnect-linux64-4.10.07061-webdeploy-k9.pkg 3
 anyconnect enable

Verify Images Loaded Correctly

show run webvpn
show webvpn anyconnect

Step 2: Certificate Trust for a Clean Client Experience

Reiterating from a security fundamentals standpoint (and worth its own dedicated attention here): the SSL certificate presented by the ASA is what the AnyConnect client validates before establishing trust. A cert chain that doesn’t validate cleanly generates a scary warning dialog that trains users to click “connect anyway” — undermining the entire point of certificate validation.

crypto ca trustpoint ASA-VPN-CERT
 enrollment terminal
 subject-name CN=vpn.company.com
 keypair ASA-VPN-KEY
 fqdn vpn.company.com

crypto ca authenticate ASA-VPN-CERT
crypto ca enroll ASA-VPN-CERT

ssl trust-point ASA-VPN-CERT outside

Import the resulting CSR response from your CA and verify:

show crypto ca certificates ASA-VPN-CERT

Step 3: Connection Profiles for Different User/Device Populations

A mature AnyConnect deployment typically has more than one connection profile (tunnel group), each surfaced via group-alias in the login dropdown or via a dedicated group-URL for automated client provisioning:

tunnel-group Corp-Managed type remote-access
tunnel-group Corp-Managed general-attributes
 address-pool CORP-POOL
 authentication-server-group ISE-RADIUS
 default-group-policy CORP-GP
tunnel-group Corp-Managed webvpn-attributes
 group-alias "Corporate Devices" enable
 group-url https://vpn.company.com/corp enable

tunnel-group BYOD type remote-access
tunnel-group BYOD general-attributes
 address-pool BYOD-POOL
 authentication-server-group ISE-RADIUS
 default-group-policy BYOD-GP
tunnel-group BYOD webvpn-attributes
 group-alias "Personal Devices" enable
 group-url https://vpn.company.com/byod enable

group-url matters operationally: distributing a direct link (rather than relying on users to pick the right item from a dropdown) dramatically reduces help-desk tickets from users connecting to the wrong profile.

Step 4: Client Provisioning — Web Deploy vs. Pre-Deployed

Two deployment models exist, and most enterprises use both depending on population:

• WebDeploy (clientless first connection) — user browses to https://vpn.company.com, authenticates via the WebVPN portal, and the ASA automatically pushes and installs the AnyConnect client, then reconnects through it. Zero-touch for end users, ideal for BYOD/contractors.
• Pre-deployed (via SCCM/Intune/Jamf/etc.) — the AnyConnect MSI/PKG is pushed to managed corporate devices ahead of time through existing endpoint management tooling, with the connection profile pre-configured in the client’s local policy XML. Preferred for managed fleets since it avoids relying on WebDeploy’s ActiveX/plugin mechanisms and gives IT full control over client version rollout timing.

For pre-deployed managed devices, a local AnyConnectProfile.xml under the client’s profile directory specifies the host/group URL so users just open the app and click Connect — no manual entry required.

Step 5: Always-On VPN (for Managed Corporate Devices)

For laptops that should be perpetually protected regardless of network location — a strong pattern for zero-trust-adjacent security postures — configure Always-On:

This is set via the client profile (managed through ASDM’s AnyConnect Profile Editor or the standalone Profile Editor tool, then pushed to the ASA):

webvpn
 anyconnect profiles CORP-PROFILE disk0:/corp_profile.xml

Within the profile XML (edited via Profile Editor, conceptually):

<AlwaysOn>true</AlwaysOn>
<ConnectFailurePolicy>Closed</ConnectFailurePolicy>

ConnectFailurePolicy: Closed blocks all network access if the VPN can’t establish — an aggressive but sometimes necessary posture for highly regulated environments; Open allows local network access to continue if VPN can’t connect, trading some security rigor for user experience and avoiding “no internet at all” support tickets.

Step 6: Group Policy Tuning for AnyConnect Sessions

group-policy CORP-GP internal
group-policy CORP-GP attributes
 vpn-tunnel-protocol ssl-client ssl-clientless
 split-tunnel-policy tunnelspecified
 split-tunnel-network-list value CORP-SPLIT-ACL
 dns-server value 10.1.1.10 10.1.1.11
 anyconnect ssl dtls enable
 anyconnect mtu 1400
 anyconnect ask none default anyconnect

anyconnect ask none default anyconnect skips the “WebVPN or AnyConnect client?” prompt and goes straight to the full client experience — a small but meaningful UX improvement for non-technical users.

Verification and Testing

show vpn-sessiondb summary
show vpn-sessiondb anyconnect
show vpn-sessiondb detail anyconnect filter name jdoe

Confirm during a live test connection that:

• DTLS is actually negotiated (not silently falling back to TLS-only) — visible in the AnyConnect client’s own connection statistics window (Advanced > Statistics tab shows “Transport Protocol: DTLS” when active).
• Split-tunnel routes are correctly pushed (route print on Windows or netstat -rn on macOS/Linux post-connection).
• DNS resolution for internal names works correctly through the tunnel.

Real-World Deployment Workflow

Scenario: A 2,000-employee enterprise migrating from a legacy clientless-only portal to full AnyConnect with Always-On for managed laptops and standard on-demand VPN for BYOD/contractor devices.

1. Pilot phase — deploy to IT department first via pre-deployed MSI through SCCM, validate Always-On behavior across office, home, and public Wi-Fi scenarios.
2. Certificate and DNS readiness — confirm the public CA-signed cert and vpn.company.com DNS record are production-ready before wider rollout.
3. Phased rollout by department — push pre-deployed client + profile via SCCM in waves, monitoring show vpn-sessiondb session counts and help-desk ticket volume between waves.
4. BYOD/contractor enablement — separate group-url with WebDeploy self-service onboarding and a more restrictive group policy/split-tunnel scope.
5. Decommission the legacy clientless-only tunnel group once migration is confirmed complete, reducing attack surface from an old, less-monitored access path.

Security Best Practices

• Prefer pre-deployed client + Always-On for managed devices — reduces reliance on browser plugin mechanisms and keeps corporate endpoints protected by default.
• Enforce client version minimums — outdated AnyConnect clients can carry known vulnerabilities; use anyconnect-essentials/client update policies or endpoint management tooling to keep versions current.
• Use DTLS where possible for both performance and to reduce load concentrated on a single TCP-based transport path.
• Segregate connection profiles and group policies by device trust level (managed vs. BYOD vs. contractor), each with appropriately scoped split-tunnel ACLs.
• Pair with posture assessment (HostScan/Secure Firewall Posture, or ISE posture checks) so non-compliant endpoints (missing patches, disabled AV) get quarantined to a remediation network rather than full access.
• Rotate and monitor certificates — set calendar reminders well before expiration; an expired VPN gateway cert is a classic self-inflicted outage.

Common Configuration Mistakes

• Only uploading one OS’s client image, breaking WebDeploy auto-install for mixed-OS environments (Mac users hitting a Windows-only ASA image).
• Blocking UDP 443 somewhere in the corporate egress path (common with overly strict outbound firewall rules) and then wondering why AnyConnect “feels slow” — it’s silently falling back to TLS-only.
• No group-url set, forcing every user to correctly pick from a dropdown — a small thing that generates a disproportionate volume of help-desk tickets.
• Always-On with ConnectFailurePolicy: Closed rolled out without adequate testing, stranding users with zero connectivity the moment the VPN gateway has any hiccup.
• Ignoring client version sprawl — years of WebDeploy auto-installs without a version enforcement policy leaves a fleet running a wide, unmanaged range of AnyConnect versions, complicating both security posture and support.

Troubleshooting

debug webvpn anyconnect 255
show vpn-sessiondb detail anyconnect
show crypto ca certificates

Performance Tuning

• Confirm DTLS is enabled cluster/gateway-wide (anyconnect ssl dtls enable in group policy) and not accidentally disabled.
• Tune MTU downward (commonly 1300–1400) for populations frequently on cellular or hotel networks with smaller path MTUs, to avoid fragmentation-related retransmits.
• Size ASA licensing and hardware for realistic peak concurrent AnyConnect sessions, factoring in DTLS’s typically lower per-session CPU overhead compared to TLS-only fallback at scale.

Frequently Asked Questions

Why does my AnyConnect connection sometimes feel slower on certain networks? Most commonly, that network blocks outbound UDP 443, forcing a fallback to TLS-only transport, which suffers more under any packet loss due to TCP-over-TCP behavior. Check the client’s connection statistics to confirm which transport is active.

What’s the difference between WebDeploy and pre-deployed AnyConnect installation? WebDeploy installs the client automatically on first browser-based connection — convenient for BYOD/unmanaged devices. Pre-deployed installation pushes the client via existing endpoint management tooling ahead of time — preferred for managed corporate fleets for better version control and Always-On support.

Is Always-On VPN right for every user population? Not necessarily — it’s a strong fit for managed corporate laptops handling sensitive data, but the ConnectFailurePolicy (Open vs. Closed) needs careful testing, and BYOD/contractor devices are often better served by on-demand, profile-selected connections instead.

Can one ASA serve multiple AnyConnect profiles for different departments? Yes — multiple tunnel groups, each with distinct group-url, group policy, split-tunnel ACL, and even different address pools, are a completely normal and common design on a single ASA.

How do I keep AnyConnect client versions current across the fleet? For pre-deployed managed devices, push updates through your endpoint management platform (SCCM/Intune/Jamf) alongside other software updates. WebDeploy can also auto-upgrade clients on reconnect if configured, but centralized management gives more predictable rollout control.

Summary

Deploying AnyConnect well is less about the core VPN handshake — which is fairly standard SSL VPN mechanics — and more about the operational details: getting the right client image to the right OS, choosing WebDeploy vs. pre-deployment intentionally per user population, tuning DTLS/MTU for real-world network conditions, and deciding deliberately whether Always-On with a Closed failure policy fits your risk tolerance. Combined with clean certificate trust, differentiated connection profiles, and ongoing version/session monitoring, AnyConnect becomes a dependable, largely invisible part of daily work life for remote and hybrid users — which is exactly the goal.

References

• Cisco AnyConnect Secure Mobility Client Administrator Guide: https://www.cisco.com/c/en/us/support/security/anyconnect-secure-mobility-client/series.html
• Cisco ASA Series VPN Configuration Guide — WebVPN and AnyConnect
• Cisco AnyConnect Profile Editor documentation
• Cisco ASA Command Reference (webvpn, tunnel-group, group-policy commands)