Cisco ASA Remote Access VPN Explained — Part 2: Secure Client, SSL VPN, IKEv2 and Licensing

Prerequisites: VPN Fundamentals, TCP/IP, User Authentication, Certificates and Firewall Policy Basics

Imagine an employee working from home who needs access to an internal business application.

The employee’s laptop is connected to a home internet connection.

The application is available only on the corporate network and must not be exposed directly to the public internet.

How can the employee connect securely?

One solution is Remote Access VPN.

Cisco Secure Firewall ASA supports remote-access VPN services that establish protected connectivity between an authorized device and the organization’s VPN gateway.

Cisco’s current endpoint VPN application is called Cisco Secure Client, formerly known as AnyConnect.

However, administrators must understand the differences between TLS-based VPN, IPsec IKEv2 VPN, browser-based legacy VPN access, authentication and licensing.

In this article, you will learn:

• How Cisco ASA Remote Access VPN works
• What Cisco Secure Client is
• How TLS-based and IPsec IKEv2 remote-access tunnels differ
• Why Clientless SSL VPN is no longer supported in modern ASA releases
• How authentication, MFA and authorization work
• What VPN group policies control
• How split tunneling affects traffic
• What current Cisco Secure Client licenses provide
• How to monitor and troubleshoot VPN sessions
• Which security best practices should be followed

What Is Remote Access VPN?

A Remote Access VPN allows an authorized user or device to establish a protected connection to a central VPN gateway.

For Cisco ASA, the gateway is the firewall.

The user’s device runs a compatible VPN client or uses another supported connection method.

Example Remote Access Network

The VPN establishes an encrypted communication path between the client and ASA.

The user’s access to corporate resources still depends on routing, authorization and security policy.

1. Cisco Secure Client — The Modern AnyConnect

Cisco’s earlier remote-access software was widely known as Cisco AnyConnect Secure Mobility Client.

With version 5, Cisco renamed the product Cisco Secure Client.

The VPN module continues to provide supported remote-access capabilities.

What Cisco Secure Client Does

Depending on the selected version and configuration, it can:

• Connect to supported ASA VPN headends
• Establish TLS-based or IPsec IKEv2 VPN connections
• Authenticate users through supported identity mechanisms
• Apply VPN profile settings
• Support reconnect and roaming-related capabilities
• Integrate with supported posture and other modules

Why AnyConnect Still Appears in Documentation

Some ASA and ASDM commands and interface labels continue to use the name anyconnect.

Cisco explicitly documents that these older labels can remain even when Secure Client 5 is used.

2. SSL/TLS-Based Remote Access VPN

Cisco ASA can use supported TLS-based tunneling for client-based Remote Access VPN.

TLS protects communication between the VPN client and gateway.

How It Works

1. The employee launches Cisco Secure Client.
2. The client connects to the configured ASA VPN address.
3. The gateway and client establish the applicable protected communication.
4. The user completes the configured authentication.
5. The ASA applies the relevant VPN group policy and authorization.
6. The client receives the necessary VPN network configuration.
7. Approved traffic passes through the established tunnel.

When TLS-Based VPN Is Useful

TLS-based VPN can be appropriate where:

• Users connect from a variety of networks.
• The organization requires managed client-based access.
• Applicable TLS connectivity is available.
• The ASA software and client versions are compatible.

Cisco Secure Client can use TLS and, where supported, DTLS to improve the performance of certain VPN traffic.

3. IPsec IKEv2 Remote Access VPN

Cisco Secure Client also supports IPsec IKEv2 Remote Access VPN with compatible ASA configurations.

How It Works

IKEv2 negotiates the relevant security associations.

IPsec protects matching packets between the remote device and the ASA.

The employee can then access approved corporate resources according to the VPN policy.

Typical Advantages

• Standards-based IPsec protection
• Supported modern cryptographic algorithms
• Appropriate mobility and reconnect capabilities
• VPN connectivity across supported operating systems

Understanding MOBIKE

MOBIKE is an IKEv2 extension that supports mobility and multihoming behavior.

It can help a compatible client maintain a VPN relationship when network addressing changes.

For example, an employee may switch from home Wi-Fi to mobile data.

This does not mean that every transition is guaranteed to occur without interruption.

TLS VPN vs IKEv2 IPsec VPN

Neither method should be considered universally superior for every network.

4. What Happened to Clientless SSL VPN?

Older Cisco ASA releases supported Clientless SSL VPN, also called browser-based WebVPN.

It allowed users to access certain internal resources through a browser-based portal without installing a full VPN client.

However, this is a historical ASA feature.

Critical Support Change

Cisco removed Clientless SSL VPN beginning with ASA 9.17.

It is not supported in modern ASA 9.24 deployments.

What This Means

An older article might instruct administrators to:

1. Enable a clientless WebVPN portal.
2. Configure portal bookmarks.
3. Publish internal applications.
4. Give users browser-only access.

Those instructions must not be presented as a supported ASA 9.24 deployment workflow.

Historical vs Current Support

5. Remote Access VPN Authentication and Authorization

Establishing an encrypted tunnel is only one part of secure remote access.

The ASA must identify and authorize the user according to the intended deployment.

Authentication

Supported authentication mechanisms may involve:

• Local user accounts
• RADIUS servers
• LDAP integration
• Certificate authentication
• SAML-based authentication where supported
• Multi-factor authentication through the appropriate identity service

Authorization

After authentication, the system must determine which resources and settings apply.

VPN authorization can involve:

• Group policies
• Address pools
• Split-tunnel settings
• VPN filters
• DNS settings
• User or group permissions
• Session restrictions

Example Access Policy

These are conceptual policy requirements, not preconfigured ASA roles.

6. Understanding Full-Tunnel and Split-Tunnel VPN

Remote Access VPN can send different categories of traffic through different paths.

Full-Tunnel VPN

A full-tunnel design routes the designated user traffic through the corporate VPN.

This can provide centralized security enforcement but increases the traffic load on the VPN gateway and corporate network.

Split-Tunnel VPN

A split-tunnel design sends selected corporate routes through the VPN while other traffic follows the user’s ordinary network connection.

Comparison

7. Cisco Secure Client VPN Licensing

The original article described AnyConnect Plus and Apex as the current licensing options.

Cisco’s modern licensing terminology is different.

Current Licensing Names

Advantage

Secure Client Advantage covers supported core VPN and related capabilities.

Premier

Secure Client Premier includes additional advanced capabilities, which can include supported posture functions, SAML authentication and ASA multiple-context Remote Access VPN.

VPN Only

VPN Only is a separate licensing option intended for defined VPN use cases and license arrangements.

Licensing Checklist

Verify:

• Number of users
• Required concurrent sessions
• Chosen VPN protocol
• VPN headend capacity
• Advanced authentication requirements
• Posture or endpoint modules
• Multiple-context use
• Contract and subscription terms

8. Cisco ASA Remote Access VPN Verification

After configuring the relevant VPN service, use ASA CLI to investigate connected clients.

Display VPN Sessions

show vpn-sessiondb

Display Cisco Secure Client Sessions

The ASA command retains the historical anyconnect keyword.

show vpn-sessiondb anyconnect

Display IKEv2 Remote Access Sessions

show vpn-sessiondb ra-ikev2-ipsec

Display IKEv2 Associations

show crypto ikev2 sa

Display IPsec Associations

show crypto ipsec sa

Review VPN Logging

show logging

Expected verification — illustrative summary

VPN session:
Authorized user is connected.

Assigned address:
Client has received the expected VPN address.

Tunnel:
Supported tunnel protocol is established.

Authorization:
Correct group policy and access restrictions apply.

Traffic:
Permitted corporate applications are reachable.

Logging:
Relevant session and security events are available.

This is an expected verification checklist, not literal command output.

9. Common Remote Access VPN Problems

Practical Troubleshooting Sequence

1. Confirm the client version is compatible.
2. Verify the VPN gateway’s public name or address.
3. Check certificates and TLS or IKEv2 negotiation.
4. Review authentication and MFA results.
5. Confirm the assigned VPN address.
6. Review applicable group policy.
7. Check split-tunnel and DNS settings.
8. Verify access policies, VPN filters and NAT.
9. Check remote application and network reachability.
10. Review logs before making configuration changes.

10. VPN Security Best Practices

Use Modern Cryptography

Select strong, supported encryption and authentication settings.

Avoid obsolete algorithms and outdated software.

Enable MFA

Use supported multi-factor authentication to reduce risk from stolen passwords.

Apply Least-Privilege Access

Use group policies, authorization and VPN filters to restrict users to required resources.

Maintain Trusted Certificates

Use appropriate certificates and validate the VPN gateway’s identity.

Control Split Tunneling

Define which traffic should use the corporate VPN based on security requirements.

Maintain Client and ASA Software

Review security advisories and supported releases.

Monitor Sessions

Watch for unusual authentication failures, unexpected user activity and abnormal connection patterns.

Review Licensing

Confirm that all required VPN capabilities remain properly entitled.

Plan Capacity

Evaluate remote-user counts, concurrent sessions, encrypted throughput and availability requirements.

Use Supported Posture Controls

Where required, select the appropriate Secure Client modules and compatible identity or endpoint systems.

Key Takeaways — Remote Access VPN

• Cisco ASA supports client-based Remote Access VPN.
• Cisco Secure Client 5 is the modern name for AnyConnect.
• TLS-based VPN and IKEv2 IPsec VPN are different supported tunnel methods.
• Clientless SSL VPN was removed in ASA 9.17 and later.
• Authentication and authorization are separate security functions.
• Full-tunnel and split-tunnel policies determine traffic routing.
• Secure Client Advantage and Premier are the current major licensing tiers.
• Modern licensing and feature support must be verified for each deployment.
• VPN session status and actual application connectivity should both be tested.

Conclusion

Cisco ASA Remote Access VPN provides protected connectivity for employees and other authorized users connecting from external networks.

Cisco Secure Client supports compatible TLS-based and IKEv2 IPsec remote-access methods.

However, a reliable deployment requires more than an encrypted tunnel.

Administrators must configure authentication, authorization, VPN address assignment, DNS, routing, split tunneling, licensing and logging.

It is also essential to distinguish current features from older technologies.

Clientless SSL VPN is no longer supported on modern ASA releases, and the AnyConnect branding has evolved into Cisco Secure Client.

By understanding these changes and following controlled access policies, organizations can build remote-access solutions that are both secure and manageable.

Useful Links and References

SanchitGurukul Static Resources

Official External References