Remote Access VPNs enable secure connectivity for remote users, and Cisco offers two primary methods to establish this access: legacy IPsec clients and the more modern AnyConnect client. The traditional IPSec (Software) Client relies on IKEv1 for tunnel establishment, while AnyConnect supports a broader range of protocols, including SSL, IPsec, and IKEv2, offering enhanced flexibility and security.

Cisco ASA functions as the VPN server in both client-based and clientless SSL VPN modes. In a client/server SSL VPN setup, users connect to the ASA using the AnyConnect client to establish a secure session. Alternatively, clientless SSL VPN offers browser-based access, allowing users to connect by clicking a bookmark on a web portal hosted by the ASA. This connection tunnels traffic to internal servers behind the ASA, provided they support HTTP or HTTPS. Additionally, protocols like FTP are also supported for broader application compatibility. For more advanced use cases, Smart Tunnels can be deployed, offering deeper application-level access without requiring a full client install.

 

Group-Based Access Control in Remote Access VPNs

Remote Access VPNs historically used the legacy IPsec Software (SW) Client, which authenticated users using IKEv1 and xAuth. Users provided a fully qualified domain name (FQDN), group name, and password to connect. Once connected, xAuth would further authenticate the user, and access policies were applied based on the assigned group. These groups could include settings such as DNS, WINS, banner messages, split-tunneling permissions, and specific access controls to internal resources.

By default, the software client did not restrict access to internal resources. Split-tunneling can be used to limit which traffic passes through the VPN, and administrators can enforce further restrictions using features like VPN-Filter and ACLs applied directly to the ASA (Adaptive Security Appliance). However, one major drawback was that the SW client stored group passwords locally, which posed security risks. To address this, Cisco introduced xAuth for stronger user authentication post-connection.

Administration also proved cumbersome with the software client. Whenever a new group was created, every client needed to be updated manually with the new group profile. This approach lacked scalability and was difficult to manage in larger environments.

 

The Modern Approach: AnyConnect Client and Group Flexibility

Cisco’s AnyConnect client, available in both full client and clientless (browser-based) modes, solves many of these administrative and usability challenges. With AnyConnect, the client does not need to be preconfigured with group information. Instead, users input the FQDN or IP address of the ASA, which initiates an SSL handshake and certificate exchange.

During the connection setup, the ASA sends an HTTP GET request that prompts the client to retrieve a list of available groups. This list is presented in a dropdown menu, allowing the user to select the appropriate group directly from the client interface. This simplifies group management significantly, as administrators no longer need to push configuration changes to every client device.

Each group can be configured with its unique authentication method. For example, one group may require RADIUS-based authentication, another may use a pre-shared key, and yet another may rely on certificate-based access. When users select a group, the authentication experience varies depending on the method in use. For password-based groups, users are prompted to enter a username and password. For certificate-based groups, the process is seamless unless multiple certificates are available on the client. In that case, the user is prompted to select the appropriate certificate from their certificate store.

 

Understanding SSL VPN: Transport Layer Security for Remote Access

SSL VPNs (Secure Socket Layer Virtual Private Networks) provide a flexible and secure method for connecting remote users to internal resources via web browsers. Initially developed by Netscape, SSL was designed to enable encrypted communication between web servers and browsers over the Internet. Although initially a general-purpose encryption protocol, it was later adopted by various vendors as the foundation for VPN solutions. Cisco, for instance, uses the term “Web VPN” as a marketing label for its SSL VPN offerings.

Despite the name, modern SSL VPNs typically do not use the original SSL protocol. SSL VPN operates at the Transport layer (Layer 4) of the OSI model, unlike IPsec, which functions at the Network layer (Layer 3). The SSL protocol itself underwent several iterations: Version 1 was never released, Version 2 was publicly released but had known weaknesses, and Version 3 became widely adopted. Importantly, SSL 3.0 later served as the foundation for the more secure Transport Layer Security (TLS) 1.0, which was standardized by the Internet Engineering Task Force (IETF).

Cisco SSL VPNs today use TLS rather than outdated SSL versions, ensuring stronger encryption and improved security. This shift aligns with best practices across the industry, as TLS provides a more robust and up-to-date foundation for protecting VPN traffic, particularly in clientless and browser-based VPN scenarios.

 

SSL VPN Modes: Clientless, Thin Client, and Thick Client Explained

Cisco SSL VPNs offer three distinct access modes, Clientless, Thin Client, and Thick Client, each tailored to different application needs and endpoint capabilities.

 

Clientless Mode

In Clientless Mode, users don’t need to install any software. Instead, they launch a web browser and connect to the SSL VPN gateway. The SSL gateway then acts as a proxy, securely relaying traffic to internal web-based applications. This mode is ideal for quick access to services like Microsoft Outlook Web Access (OWA), internal HTTPS portals, or intranet resources. However, it only supports web-based protocols such as HTTP, HTTPS, and MS Exchange. The only requirement for this mode is a compatible web browser.

 

Thin Client Mode

Thin Client Mode is designed for applications that rely on static TCP ports and are not web-based, such as Telnet, SSH, and RDP. Also known as port forwarding, this mode allows the user to request a connection to an internal resource through the SSL VPN gateway. The gateway forwards the traffic securely to the target internal system. While it still runs within a browser, Thin Client Mode requires Java support, and browser configurations must allow ActiveX and pop-ups to function correctly. This approach works well for IT administrators or power users needing secure remote access to command-line interfaces or remote desktops without installing full VPN software.

 

Thick Client Mode

Thick Client Mode offers the most robust access, allowing users to connect to both web-based and non-web-based internal resources. When a session is initiated, the SSL gateway pushes a client package, typically the Cisco AnyConnect Secure Mobility Client or Secure Desktop package, to the user’s device. Upon installation, the package sets policies such as assigned IP address, subnet mask, and routing for interesting traffic. This mode effectively transforms the remote system into a full VPN client, capable of handling a wide variety of applications, including those with dynamic ports or complex traffic flows.

Thick Client Mode shares some browser-based prerequisites with Thin Client Mode: a supported web browser, Java, and enabled ActiveX controls and pop-ups. However, it additionally requires installation of the AnyConnect client software and possibly the Cisco Secure Desktop package for full functionality.

 

How SSL VPNs Work: TLS Handshake and Secure Session Establishment

The core of SSL VPN functionality lies in how it establishes a secure, encrypted connection using TLS (Transport Layer Security). When a remote user initiates a connection to the SSL VPN gateway, the client sends a request to begin the session. This triggers a TLS handshake, which is the cryptographic process used to establish a secure channel.

During the handshake, the client presents a list of supported cipher suites, which are combinations of encryption algorithms and hash functions. The server reviews this list and selects a cipher suite that it also supports, informing the client of the chosen parameters. Next, the server sends its digital certificate to the client. This certificate includes the server’s name, the identity of a trusted Certificate Authority (CA), and the server’s public key.

Upon receiving the certificate, the client verifies its authenticity. If the certificate is valid, the client generates a session key, a symmetric encryption key to be used for the VPN session. This session key is encrypted using the server’s public key and sent back to the server.

The server then uses its private key to decrypt the session key. Because only the server possesses this private key, this step ensures confidentiality and authenticity. Once the session key is shared, both the client and the server use it to encrypt and decrypt all subsequent traffic in the session.

If any part of this handshake process fails, such as an unsupported cipher suite or an invalid certificate, the TLS session is not established, and the secure tunnel cannot be created. This strict validation process is why TLS and SSL are often described as “operating over some reliable transport layer,” ensuring data is transmitted securely and only between trusted parties.

 

Cisco AnyConnect Overview: More Than Just a VPN Client

Cisco AnyConnect is widely recognized as a versatile and secure remote access VPN client. While it’s often associated with SSL VPNs, it also supports IKEv2-based VPNs, providing organizations with flexibility in configuring remote access based on their performance, security, and compatibility needs.

What sets AnyConnect apart is its modular design. It’s not just a VPN client; it’s a full endpoint security suite that can be tailored with various extensions and capabilities. These modules can be selectively deployed based on organizational needs:

  • VPN Module: The core component that enables SSL and IKEv2-based remote access.
  • AMP Enabler: Added in AnyConnect version 4.1, this integrates Cisco’s Advanced Malware Protection to provide endpoint threat detection and response.
  • ISE Posture Module: Functions as a built-in NAC (Network Access Control) agent, allowing AnyConnect to assess endpoint posture (e.g., antivirus status, OS patch levels) before allowing network access.
  • Web Sentry: Acts as a connector to Cisco Web Security (formerly Cloud Web Security or CWS), enforcing web filtering policies on remote endpoints.
  • Network Access Manager (NAM): Serves as an 802.1X supplicant, managing wired and wireless network access based on enterprise policies.
  • Feedback Service Profile: Used to gather diagnostic or telemetry feedback from endpoints.
  • Telemetry Module: An older module used initially for collecting endpoint data, now mostly replaced by newer visibility tools.
  • Network Visibility Module (NVM): Introduced in AnyConnect version 4.2, this powerful feature collects endpoint-level statistics and flow data. It enables administrators to send real-time telemetry directly to a NetFlow collector, enhancing visibility, traffic analysis, and threat detection.

This modular approach makes AnyConnect a strategic choice for organizations seeking to integrate secure VPN access with comprehensive endpoint visibility, posture enforcement, and threat protection – all from a single, lightweight client.

 

Configuring Cisco AnyConnect Remote Access VPN on ASA

Before deploying Cisco AnyConnect, you must ensure the client image is uploaded to the ASA’s flash memory. The image file (e.g., anyconnect.pkg) must be explicitly referenced and loaded into configuration to support SSL VPN sessions.

Start by enabling WebVPN on the ASA’s outside interface. This step is necessary to allow SSL-based VPN connections from remote clients:

webvpn 
enable outside

 

Next, enable AnyConnect and point to the client image:

anyconnect enable 
anyconnect image flash:/anyconnect.pkg

 

Group Policy Configuration

Define a group policy to control client connection parameters. The example below creates a policy named SALES, enabling SSL VPN and configuring full-tunnel or split-tunnel behavior:

group-policy SALES internal 
group-policy SALES attributes 
vpn-tunnel-protocol ssl-client 
split-tunnel-policy tunnelall

 

IP Address Pool

Set up an address pool for assigning IPs to remote clients. This pool should align with your internal network’s design:

ip local pool SSLPOOL 192.168.1.10-192.168.1.254 mask 255.255.255.0

 

Tunnel Group Setup

Link the group policy and address pool to a tunnel group. This defines the remote access entry point and associates it with the desired policy and resources:

tunnel-group SSLTUNNEL type remote-access 
tunnel-group SSLTUNNEL general-attributes 
address-pool SSLPOOL 
default-group-policy SALES 
tunnel-group-list enable

 

User Authentication

Finally, create a test user for login:

username kmac password cisco123 
username kmac attributes 
vpn-group-policy SALES

 

GUI Configuration Using ASDM

Administrators preferring a graphical interface can use Cisco ASDM (Adaptive Security Device Manager). Navigate to:

Configuration > Remote Access VPN > AnyConnect Client Profile

Here, you can manage multiple AnyConnect profiles and add new ones. Profiles may include various usage types like VPN, telemetry, posture assessments, and visibility services. This centralizes control of the client experience and allows dynamic feature enablement depending on the assigned profile.

 

Transport Options for AnyConnect

Cisco AnyConnect uses multiple transport protocols for flexibility and performance:

  • TLS (Transport Layer Security): A fallback transport using TCP/443. While TLS and SSLv3 are nearly identical in function, TLS is an open standard developed by the IETF, whereas SSLv3 was licensed by Netscape. TLS is the default transport when DTLS is unavailable.
  • DTLS (Datagram TLS): Uses UDP/443 and is preferred for performance-sensitive applications like audio and video because of its lower latency and reduced overhead.

The recommended connection order is to first attempt DTLS, and if that fails, automatically fallback to TLS.

 

Building and Customizing AnyConnect Profiles in ASDM

To configure AnyConnect profiles through the ASDM, navigate to Configuration > Remote Access VPN > AnyConnect Client Profile and click Add. You’ll need to assign a profile name, define the group policy it applies to, and optionally enable “Always-On VPN”. This feature ensures the VPN is active whenever network connectivity is available.

Before applying changes, it’s a best practice to go to Tools > Preferences and check the Preview commands before sending them to the device box. This gives you visibility into the exact CLI commands being applied behind the scenes.

After creating the profile, click Edit to configure key behavioral features:

  • Use Start Before Login
  • Show Pre-Connect Message
  • Auto Connect on Start
  • Enable access to local LAN
  • Disable Captive Portal Detection
  • Auto Reconnect on disconnect/resume
  • Automatic software updates
  • RSA Secure ID or Windows Login Enforcement
  • VPN session persistence and user login control
  • IP protocol support (IPv4/IPv6)
  • Proxy settings and trusted server configuration
  • Always-On VPN (with/without disconnect option)
  • Manual Host Input, Backup Servers, Certificate Matching, SCEP Enrollment
  • Mobile Policy support
  • Server List with custom display names, fallback hosts, and CA details

For SSL VPN, the GUI allows admins to configure trusted servers, define custom messages, and manage client certificate behaviors. You can also create a group URL via CLI for easier client connection:

tunnel-group SALES webvpn-attributes 
group-url https://asa.cisco.local/sales enable

To delete a local profile for troubleshooting, users can browse to:
C:\ProgramData\Cisco\Cisco AnyConnect Secure Mobility Client\Profile\profile.xml

 

Certificate-Based Authentication and Enrollment (CLI)

For environments using certificate-based authentication, the ASA can act as a proxy for SCEP or integrate with an internal CA. If you’re testing or using a router-based CA in a lab setup, generate the RSA key pair and configure trustpoints:

crypto key generate rsa modulus 2048 label WIN7 exportable 
crypto pki trustpoint WIN7 
enrollment url http://192.0.2.20
rsakeypair WIN7 
subject-name cn=win7sales.cisco.local,o=Cisco,ou=SALES,c=us 
subject-alt-name win7sales.cisco.local 
exit 
crypto pki authenticate WIN7 
crypto pki enroll WIN7 
crypto pki export WIN7 pkcs12 terminal password cisco123

Export the certificate, save it as .pfx, and import it into User > Personal certificate store in Windows. Then, assign certificate authentication to the tunnel-group in ASDM.

 

Enabling IPsec (IKEv2) with AnyConnect

To switch from SSL to IKEv2, edit the AnyConnect server list and change the Primary Protocol to IPsec. Remove the group reference since IKEv2 doesn’t use group URLs in the same way.

Ensure the “Enable IKEv2” box is checked in the profile. Then configure the appropriate connection profile with certificate-based IKEv2:

group-policy FINANCE_POLICY attributes 
vpn-tunnel-protocol ikev2 
exit 
crypto ipsec ikev2 ipsec-proposal TS 
protocol esp encryption aes-192 
protocol esp integrity sha-1 
crypto dynamic-map DYNMAP 10 set ikev2 ipsec-proposal TS 
crypto map CMAP 100 ipsec-isakmp dynamic DYNMAP 
crypto map CMAP interface outside 
tunnel-group FINANCE ipsec-attributes 
ikev2 local-authentication certificate CA1 
ikev2 remote-authentication certificate CA1 
group-policy FINANCE_POLICY attributes 
address-pools value AC

 

Verifying and Troubleshooting AnyConnect

Once your AnyConnect or WebVPN deployment is live, verifying operational status and troubleshooting issues become essential. Cisco ASA provides a comprehensive set of show commands to inspect VPN sessions, certificates, licenses, and configurations.

Session and Certificate Inspection

  • show crypto ca cert – Checks the status of the CA certificates installed on the ASA. This is crucial for troubleshooting issues involving certificate-based authentication.
  • show vpn-sessiondb webvpn – Displays detailed information about active WebVPN sessions, including usernames, assigned public IPs, encryption algorithms (e.g., AES-GCM-128), group policy in use, and session duration. It’s useful for real-time visibility into browser-based (clientless) VPN connections.
  • show vpn-sessiondb – A broader command that shows session summaries for all VPN types, including cumulative totals, device load, and tunnel counts.
  • show vpn-sessiondb anyconnect – Specifically filters AnyConnect client sessions, showing protocol type (SSL or DTLS), IP assignment, encryption suites, and tunnel group associations. It helps confirm whether SSL fallback or DTLS is active.

 

Licensing and Group Policy Verification

  • show version – Lists current license entitlements, including AnyConnect Premium Peers, Essentials status, and total VPN capacity. This is vital for confirming whether your ASA can support additional concurrent VPN users.
  • show run tunnel-group – Displays default tunnel groups like DefaultRAGroup (remote access) and DefaultL2LGroup (site-to-site), along with associated attributes.
  • show run group-policy – Reveals configured group policies and their attributes such as smart tunnel settings, web content filtering, and custom banners.
  • show nat details – Helpful in packet tracer verification to confirm WebVPN traffic flows are permitted.

 

Session Management and Logging

  • vpn-sessiondb logoff webvpn – Clears current WebVPN sessions, useful for forcing user reauthentication or performing session cleanup.
  • vpn-sessiondb logoff all – Disconnects all VPN sessions across protocols—use this with caution in production.
  • logging class svc mon 7 – Enables verbose logging for the SSL VPN (svc) class, which helps in debugging client connection problems.

These commands offer essential visibility and control when managing Cisco ASA-based VPN deployments. Whether you’re troubleshooting a failed IKEv2 tunnel, validating group policy mapping, or reviewing session encryption, these tools ensure transparency across your VPN environment.

You can also initiate guided VPN setup from CLI using:

vpnsetup ssl-remote-access steps 
vpnsetup ipsec-remote-access steps

This lab helps define interfaces, WebVPN settings, routing, and client access profiles quickly and interactively.