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
- AnyConnect Client Image — uploaded to ASA flash, pushed to endpoints automatically on first connection.
- Connection Profile (Tunnel Group) — defines how a user connects (authentication method, group policy assignment, DNS).
- Group Policy — defines what the user gets once connected (split tunneling rules, DNS/WINS, session timeouts, ACL restrictions).
- Authentication Backend — local database, RADIUS, LDAP/AD, or ideally RADIUS with MFA (Duo, ISE, etc.) in production.
- Address Pool — the internal IP range assigned to connecting clients.
- 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:
EmployeesandContractors, each with its own group policy. Employeesgroup policy: split-tunnel to full internal10.0.0.0/8, session timeout 12 hours, DNS pointed at internal AD-integrated DNS.Contractorsgroup policy: split-tunnel scoped to a single/24hosting 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-sessiondbdata 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
| Symptom | Likely Cause | Diagnostic Commands |
|---|---|---|
| Client can’t reach the portal at all | Outside interface not enabled for webvpn, or firewall/NAT blocking 443 upstream | show run webvpn, confirm enable outside, test port reachability externally |
| Certificate warning on every connection | Self-signed or expired cert, or SNI/hostname mismatch | show crypto ca certificates, verify CN/SAN matches the connection hostname |
| Authentication fails for valid AD users | RADIUS/LDAP misconfiguration or shared secret mismatch | debug radius, show aaa-server, verify connectivity to auth server and matching shared key |
| Connects but no internal access | Split-tunnel ACL too narrow, or missing route back to VPN pool on internal routers | show route, verify internal routing knows how to reach the VPN pool subnet |
| Session drops randomly | Idle/session timeout too aggressive, or unstable client-side network (common with SSL over unreliable Wi-Fi/cellular) | show vpn-sessiondb detail anyconnect, review configured timeouts vs. observed disconnect pattern |
| Slow throughput over VPN | MTU/fragmentation issues common with SSL VPN over certain ISPs, or full-tunnel routing all traffic through a congested path | Test smaller MTU (anyconnect mtu), review whether split-tunnel design fits actual usage pattern |
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