Basic Clientless TLS VPN on ASA

“The What?” - Understanding the configuration building blocks for Clientless TLS VPNs on Cisco Adaptive Security Appliance (ASA)

For remote access VPN solutions we have two options: client-based & clientless. I want to understand/share what a basic clientless TLS VPN is (specifically on Cisco ASA).

“The Why?” - So, why would one need a clientless TLS VPN?

Clientless VPNs are simple to manage, grant remote access via web browsers, & provide flexibility for organizations. I do want to note that clientless TLS VPNs do not offer complete network access that full-tunnel VPNs provide. Organizations wishing to grant access to remote users want the communication secured. By utilizing existing technologies such as TLS we can ensure that communications between internal resources, the ASA proxy, and remote users are secured.

Quick overview of TLS:

Main services provided by TLS include: authentication to validate identities, confidentiality to encrypt data, integrity to protect from attacks, & key management.

The TLS protocol works in two unique phases: session establishment & data transfer phase. The order of operations looks like this:

-Establish client/server security capabilities via hello messages exchanged

-Server certificate and key exchange initiated by the server via sending its identity certificate

-Client certificate (if necessary) & key exchange. During this step the session key is calculated & the agreed cipher suite activates.

-Last part, secured data transfer starts after exchange of session keys.

Note that each session has a unique ID which is obtained during the authentication process. Typically the session ID is different between each session. However, TLS can cache IDs, and has the ability to resume sessions via the client asking the server to resume its session.

Diagram of TLS Client/Server Authentication:

Note I won't be touching on specific clientless VPN Features, but I do want to share them so we are aware: The ASA appliance has several techniques for granting resource and application access for remote users:

Application plug-ins: these simply allow the remote user to launch an app plug-in inside the browser and connect to the internal server running the application. (Well known plug-ins include: RDP, Citrix, SSH)

Smart tunnels: provides remote users with native-application client access to enterprise resources.

Port forwarding: predecessor to smart tunnels. Offers the same native-application access to resources. Recommended to use only if you cannot use smart tunnels.

URL & CIFS file access: the ASA presents the remote user resource bookmarks that allow the user to access preconfigured web pages or file shares.

“The How?” - So, how do we do utilize a basic clientless TLS VPN?

In a Clientless TLS VPN solution using a Cisco ASA, the ASA acts as a proxy to protect internal resources and grant access to authorized users. Before we dive any deeper I want to touch on a few things that will get referenced a bit and so that we both have a general understanding:

Connection Profile (AKA tunnel groups) = define pre-login requirements.

Group Policy = define reusable post-login requirements/security policies that are applied after successful user authentication.

Note: Make sure before you start you know what IP addressing scheme you will use, an appropriate naming plan for the gateway proxy identity, & your security policy requirements.

Cisco ASA Clientless TLS VPN Configuration Blocks:

Pre-TLS: On the ASA you need to configure a digital certificate that the proxy will use to negotiate TLS sessions with remote clients. Other configuration includes: configuring tunnel and group policies, user authentication, and what you wish your clientless end-user to use.

Basic TLS: In order for the ASA to be setup you must enable the TLS VPN on an interface. Determine how you wish to authenticate clients (local/AAA/etc.), what resources each respective tunnel-group will have access to, and finally apply the VPN policies & connection profile attributes.

Advanced TLS: determine if you wish to have plug-ins, portal customization, web-type ACLS, and any sort of advanced authentication.

Ok, so let’s step into my personal home lab to take a deeper dive: Here is the simple lab topology used for this setup:

  • The VPN gateway is configured on ASA2

  • Win1 client is used to access the VPN

  • Ignore the transparent ASA & CSR2 for the sake of understanding what we are trying to learn & accomplish (Basic Clientless TLS VPN & it's building blocks)

  • I am skipping parts of the basic ASA config to include ASDM configuration

Overview of configuring a basic Clientless TLS VPN on Cisco ASA via cli:

Pre-TLS config from CLI:

Brief overview of base config for outside interface that we will enable . Note that the ASA has a default route to CSR2:

Note: Local user can be created in ASDM via Configuration->Device Management->Users/AAA->User Accounts or via CLI

Let's generate a keypair, self-signed certificate, CA trustpoint, connection profile, and unique group policy to use. We will also harden the ASA for security purposes. The steps via CLI are as follows:

  • Create key pair

  • Create CA trustpoint & Enroll the trustpoint

Note: It is NOT best practice to use self-signed certificates, but for the purpose of this demo/studying a self-signed cert suffices. You can see that we create the trustpoint, assign the previously generated keypair to use, assign usage, subject-name identifiers, and the ASA fqdn. Lastly, we enroll the trustpoint.

  • Assign trustpoint to be used on interface to handle incoming TLS VPN negotiations;

ASDM screenshot for certificate creation:

Now let's create a unique connection profile & new group policy to use for our lab. For play purposes the connection profile will be named: Cifelli-Lab & the group policy will be named: Cifelli-Lab-GP.

  • From CLI the the simple tunnel-group & group-policy config looks like this:

Issuing a # show run group-policy Cifelli-Lab-GP

  • Under general-attributes we assign our group policy; note that if we used a AAA server group beyond local we would see additional AAA config.

  • Under webvpn-attributes is where we configure TLS attributes used for the webvpn configuration; In our test setup we disable url-entry, enable a generic banner, and default users to the TLS portal

Note: In our configuration our test user can access the portal via the specific group-url OR by selecting the group via dropdown on portal frontend.

Screenshots from within ASDM to configure a new connection profile & group policy:

Access via: Configuration->Remote Access VPN->Clientless SSL VPN Access->Connection Profiles/Group Policies

Note: You should always strive to use advanced authentication mechanisms. For the purpose of this learning I will be using the local database on the ASA.

Tying the group-policy together with the connection profile:

Additional note: It is best practice to disable legacy protocols (SSL & older versions of TLS) for security purposes. To configure your ASA to negotiate using TLSv1.2 or greater, offer stronger ciphers, and generate stronger keys see the following example:

Configuring from within ASDM:

Basic-TLS Config from CLI:

Lets enable clientless TLS remote access on the ASA2 outside interface:

A few things to note here: we enable the webvpn service on our outside interface, hsts is enabled by default which helps to protect against downgrade attacks and cookie hijacking. The <tunnel-group-list enable> cmd enables the group list dropdown.

Enabling webvpn on outside interface from within ASDM:

Note: Advanced-TLS Configuration is omitted in this post. Typically you would assign restrictions via webacls, bookmarks, or other features to grant/restrict access to internal resources based on requirements.

TLS VPN Verification from CLI:

Verification from within ASDM:

Blog overview: In this post we went over understanding the basic configuration blocks for a Clientless TLS VPN on Cisco ASAs to include what they are, why we would need them, and how to use them. In the how section we demo config on how to setup a basic Clientless VPN RA solution, and how to verify sessions. Thanks for reading, & sharing!


Recent Posts

See All

In the post I want to cover understanding IKEv1 status messages & debugging IKEv1 main mode. It is important as each message has its own unique meaning, and these messages are typically seen when att

"The What?" - In this post I will cover configuring & verifying a basic site-to-site VPN tunnel between two Cisco ASAs using IKEv1 with pre-shared keys (PSK). These types of VPNs are also known as L2