How to Set Up Remote Access VPNs on Cisco ASA Firewalls: AnyConnect and Client VPN Configuration

Remote access VPN is the front door for every remote employee, contractor, and admin who needs to reach internal resources from outside the office — which means it’s also one of the highest-value targets on your network. This guide covers how remote access VPN actually works on Cisco ASA, and how to build it correctly using AnyConnect (SSL-based) and traditional IPsec client options, with security baked in from the start rather than bolted on afterward.

Remote Access VPN Fundamentals

A remote access VPN creates an encrypted tunnel from an individual client device to the ASA, after which the client is treated (via policy) as if it were plugged into a defined segment of the internal network. Two technology families matter here:

• SSL VPN (via Cisco AnyConnect Secure Mobility Client) — tunnels over TLS, works through almost any firewall/NAT/proxy since it typically rides over 443, and is the modern default recommendation.
• IPsec IKEv2 Client VPN — a client-based IPsec tunnel, often used where native OS IPsec clients or specific compliance requirements call for it, also supported by AnyConnect as a transport option.

Legacy IPsec IKEv1 remote access (the old “EZVPN”/legacy Cisco VPN Client model) still exists in older deployments but AnyConnect over SSL or IKEv2 is the current standard — new deployments should default to AnyConnect.

Core Components of an ASA Remote Access VPN

1. AnyConnect Client Image — uploaded to ASA flash, pushed to endpoints automatically on first connection.
2. Connection Profile (Tunnel Group) — defines how a user connects (authentication method, group policy assignment, DNS).
3. Group Policy — defines what the user gets once connected (split tunneling rules, DNS/WINS, session timeouts, ACL restrictions).
4. Authentication Backend — local database, RADIUS, LDAP/AD, or ideally RADIUS with MFA (Duo, ISE, etc.) in production.
5. Address Pool — the internal IP range assigned to connecting clients.
6. Certificate — for the ASA’s own identity (so clients trust the VPN gateway) — a properly CA-signed cert avoids constant browser/client trust warnings.

Step-by-Step Configuration

Step 1: Enable the Outside Interface for AnyConnect (SSL)

enable
configure terminal

webvpn
 enable outside
 anyconnect image disk0:/anyconnect-win-4.10.07061-webdeploy-k9.pkg 1
 anyconnect enable
 tunnel-group-list enable

Step 2: Install/Trust an Identity Certificate

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

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

ssl trust-point ASA-CERT outside

In production, this trustpoint should be enrolled against a real public or enterprise CA — a self-signed cert will work functionally but generates trust warnings on every client, training users to click through security prompts, which is a bad habit to build.

Step 3: Create the Address Pool

ip local pool ANYCONNECT-POOL 10.50.0.10-10.50.0.254 mask 255.255.255.0

Step 4: Configure Authentication (AD via RADIUS, Recommended)

aaa-server ISE-RADIUS protocol radius
aaa-server ISE-RADIUS (inside) host 10.1.1.50
 key MyRadiusSharedKey123
 authentication-port 1812
 accounting-port 1813

For MFA-integrated deployments, RADIUS typically points at Cisco ISE or Duo’s RADIUS proxy in front of AD, so multi-factor is enforced before the tunnel is granted, not layered on afterward.

Step 5: Create the Group Policy

group-policy ANYCONNECT-GP internal
group-policy ANYCONNECT-GP attributes
 vpn-tunnel-protocol ssl-client
 split-tunnel-policy tunnelspecified
 split-tunnel-network-list value SPLIT-TUNNEL-ACL
 dns-server value 10.1.1.10 10.1.1.11
 default-domain value company.local
 address-pools value ANYCONNECT-POOL

Define the split-tunnel ACL (only internal-bound traffic goes through the tunnel — everything else, like general internet browsing, exits locally at the user’s own connection, which is both a performance and security-scoping decision):

access-list SPLIT-TUNNEL-ACL standard permit 10.0.0.0 255.0.0.0

Full-tunnel (all traffic through the VPN) is the more security-conservative option for higher-risk user populations — it’s a policy tradeoff, not a technical limitation either way.

Step 6: Create the Connection Profile (Tunnel Group)

tunnel-group REMOTE-USERS type remote-access
tunnel-group REMOTE-USERS general-attributes
 address-pool ANYCONNECT-POOL
 authentication-server-group ISE-RADIUS
 default-group-policy ANYCONNECT-GP

tunnel-group REMOTE-USERS webvpn-attributes
 group-alias RemoteUsers enable

Step 7: Verify the Configuration

show run webvpn
show run tunnel-group
show vpn-sessiondb summary

Test with a real AnyConnect client connecting to vpn.company.com, confirm the connection profile appears in the dropdown, authenticate, and verify assigned IP and split-tunnel behavior:

show vpn-sessiondb anyconnect

Expected output includes username, assigned IP, encryption used, and bytes transmitted/received — confirming the tunnel is actually passing traffic, not just establishing a handshake.

IKEv2 Client-Based IPsec Option

For environments requiring native IPsec (e.g., specific compliance or third-party client integration), configure IKEv2 remote access alongside or instead of SSL:

crypto ikev2 enable outside
crypto ikev2 policy 10
 encryption aes-256
 integrity sha256
 group 14
 prf sha256
 lifetime seconds 86400

crypto ipsec ikev2 ipsec-proposal AES256-SHA256
 protocol esp encryption aes-256
 protocol esp integrity sha-256

crypto dynamic-map DYN-MAP 10 set ikev2 ipsec-proposal AES256-SHA256
crypto map OUTSIDE-MAP 65535 ipsec-isakmp dynamic DYN-MAP
crypto map OUTSIDE-MAP interface outside

Bind this to the same tunnel-group/group-policy structure, adding vpn-tunnel-protocol ikev2 to the group policy so the same user population can connect via either SSL or IKEv2 depending on client capability.

Real-World Deployment Scenario

Scenario: A professional services firm with 300 remote/hybrid employees needs secure access to internal file shares and internal apps, with contractors restricted to a narrower resource set than full-time staff.

Design:

• Two connection profiles: Employees and Contractors, each with its own group policy.
• Employees group policy: split-tunnel to full internal 10.0.0.0/8, session timeout 12 hours, DNS pointed at internal AD-integrated DNS.
• Contractors group policy: split-tunnel scoped to a single /24 hosting only the project file share and ticketing system, session timeout 4 hours, no access to broader internal ranges — enforced by a combination of the split-tunnel ACL and a downstream ASA/inside-firewall ACL, since split-tunnel alone is a routing convenience, not a hard security boundary.
• RADIUS authentication against ISE, ISE enforcing AD group membership plus Duo push MFA before granting the session.
• Posture consideration: AnyConnect’s HostScan/Secure Firewall Posture module (where licensed) checks for updated AV/OS patch level before granting full access — worth evaluating for higher-risk endpoint populations.

Security Best Practices

• Always require MFA on remote access VPN — password-only remote access is one of the most consistently exploited entry points in real-world breaches.
• Use split-tunneling deliberately, not by default — understand that split-tunneled clients can bridge an attacker on the user’s local network directly toward your internal resources if the endpoint itself is compromised; full-tunnel with a corporate proxy is the more conservative choice for sensitive user populations.
• Segment access by group policy, not one-size-fits-all — contractors, admins, and standard employees should never share identical VPN access scope.
• Layer internal ACLs behind the VPN, don’t rely on split-tunnel ACLs alone as your only access boundary.
• Patch AnyConnect and ASA software regularly — remote access VPN client and gateway vulnerabilities have been high-value real-world attack vectors industry-wide; staying current is not optional.
• Log and monitor VPN sessions — unusual login times, impossible-travel geolocation patterns, or unusual data volume through the tunnel are all detectable if you’re actually reviewing vpn-sessiondb data and AAA logs, ideally piped into a SIEM.
• Set reasonable idle and session timeouts so abandoned or forgotten sessions don’t stay open indefinitely.

group-policy ANYCONNECT-GP attributes
 vpn-idle-timeout 30
 vpn-session-timeout 720

Common Configuration Mistakes

• Self-signed certificates in production, training users to click through browser warnings — an easily-exploited social engineering vector once users are conditioned to ignore that warning.
• No split-tunnel ACL defined, silently defaulting to full-tunnel and overwhelming internet-bound traffic through the VPN unnecessarily, or the opposite: an ACL that’s too broad and grants more internal access than intended.
• Shared/generic tunnel-group aliases across very different user populations, making policy differentiation impossible.
• Local database authentication left enabled in production instead of centralized AD/RADIUS — this creates orphaned local accounts that don’t get disabled when an employee leaves.
• No MFA enforcement, relying purely on AD password authentication.
• Overly long or unlimited session timeouts, leaving VPN sessions open far longer than the actual work session that justified them.

Troubleshooting Remote Access VPN

debug webvpn anyconnect 255
show vpn-sessiondb anyconnect filter name <username>
show crypto ikev2 sa

Performance Tuning

• Adjust the AnyConnect MTU setting for networks with known fragmentation issues (common on certain cellular/hotel Wi-Fi paths):

group-policy ANYCONNECT-GP attributes
 anyconnect mtu 1300

• Enable DTLS (in addition to TLS) for AnyConnect where supported — DTLS over UDP generally performs better for latency-sensitive traffic than pure TLS/TCP tunneling, since it avoids TCP-over-TCP performance degradation when the underlying network already has loss.
• Size the address pool and ASA licensing for realistic peak concurrent-session counts, not just headcount — most organizations never see 100% simultaneous VPN usage, but undersizing during a real spike (e.g., a snow day or major outage forcing full remote work) causes exactly the outage you built the VPN to prevent.

Frequently Asked Questions

Should I use SSL (AnyConnect) or IKEv2 IPsec for remote access? AnyConnect over SSL/DTLS is the more broadly compatible default (traverses almost any network path, works well through NAT/proxies) and is Cisco’s primary recommended path for modern deployments. IKEv2 remains relevant for specific compliance or native-client integration needs.

Is split-tunneling a security risk? It can be, if the endpoint itself is compromised — an attacker on the split-tunneled local network segment could potentially pivot toward internal resources reachable through the tunnel. It’s a legitimate design tradeoff (performance/scalability vs. containment), not an automatic mistake, but it should be a deliberate choice per user population, not a default.

Do I need a separate license for AnyConnect? Yes — AnyConnect requires appropriate licensing tiers (Plus/Apex historically, current naming may differ by release) beyond the base ASA platform license; verify current licensing requirements against Cisco’s current AnyConnect licensing documentation before deployment.

Can remote access VPN survive an ASA failover event? With stateful failover configured, many RA VPN sessions can be preserved during failover, though historically there have been version-dependent nuances to exactly what state replicates — check current release notes for your ASA software version.

How do I enforce MFA on ASA remote access VPN? Typically via RADIUS proxy to a solution like Cisco ISE with Duo, or Duo’s own RADIUS proxy in front of AD — the ASA itself authenticates against RADIUS, and the MFA challenge happens at that backend layer before the ASA grants the tunnel.

Summary

A properly configured ASA remote access VPN is more than “turn on AnyConnect and hand out a URL” — it’s a layered system of certificate trust, differentiated group policies per user population, centralized MFA-backed authentication, deliberate split-tunnel design, and ongoing session monitoring. Every shortcut taken here (self-signed certs, no MFA, flat access for all users) tends to show up later as either a support burden or, worse, a breach entry point. Build it deliberately, test it under real client conditions, and treat it with the same security discipline as any other internet-facing authentication system — because that’s exactly what it is.

References

• Cisco ASA Series VPN Configuration Guide: https://www.cisco.com/c/en/us/td/docs/security/asa/index.html
• Cisco AnyConnect Secure Mobility Client Administrator Guide
• Cisco ASA AAA and RADIUS Configuration Guide
• Cisco Identity Services Engine (ISE) Integration Guides