Cisco ASA supports two major WebVPN modes: Clientless WebVPN and Anyconnect WebVPN.

Let’s see the differences between the two WebVPN modes and I’m sure you will understand why the AnyConnect mode is much better in my opinion.

Clientless WebVPN does not require any VPN client to be installed on user’s computer. It uses a normal web browser. By pointing the browser to https://[outside address of ASA] the user authenticates with the firewall and gets access to a Web Portal. Through this Web Portal, the user can then access a limited number of internal applications. Specifically, only internal Web applications (HTTP, HTTPs), email servers (POP3, SMTP, IMAP), Windows file shares and a small number of TCP legacy applications (e.g Telnet) can be accessed. That is, there is no full network connectivity with Clientless WebVPN.

AnyConnect WebVPN, on the other hand, provides FULL network connectivity to the remote user. The ASA firewall, working as AnyConnect WebVPN server, assigns an IP address to the remote user and attaches the user to the network. Thus, all IP protocols and applications function across the SSL VPN tunnel without any problems. For example, a remote user, after successfully authenticated with AnyConnect VPN, can open a Remote Desktop connection and access a Windows Terminal Server inside the central network. Although a special Java-based client is required to be installed on the user’s desktop, this client can be supplied dynamically to the user from the ASA. The user can connect with a browser to the ASA firewall and download the Java client on demand. The Java client can remain installed or even get removed from the user’s desktop when disconnected from the ASA appliance. This Java client is small in size (around 3MB) and is stored on the ASA flash memory.

The convenience and advantages of secure VPNs has driven the specific technology to keep evolving continuously. Several years ago we only had the standardized IPSec VPN (which still strongly exists today). IPSec is a pure IP network VPN technology for connecting distant LAN networks over unsecured paths. Also, IPSec is used for client VPNs connecting remote teleworkers to their central site network. The characteristic of IPSec VPNs is that it provides FULL network connectivity between the VPN peers. That is, a remote access client IPSec VPN will connect the remote user to the central network just like the user would be locally connected.

After IPsec, the Web SSL VPN made its appearance. The remote user needs just a Web Browser with HTTPs to connect to the central site network. After authentication, the user is presented with a Web portal with links to the applications he is allowed to run. That is, the Web SSL VPN does not provide full network visibility to the remote user. The user has access only to specific applications (like internal email, internal files etc). Both IPSec VPNs and SSL VPNs are supported by Cisco ASA 5500 firewalls.

The newest generation of remote access VPNs is offered from Cisco AnyConnect SSL VPN client. This is supported by Cisco ASA 8.x. The AnyConnect SSL VPN provides the best features from both of the other VPN technologies (IPSec and Web SSL). With AnyConnect, the remote user has full network connectivity to the central site. Also, it offers the convenience of the Web SSL since there is no need to install an IPSec VPN client permanently to the user’s computer. Instead, there is an SSL client stored in the ASA flash memory which is downloaded to the remote user’s computer on demand.

How AnyConnect SSL VPN Client works

For first time user connection, the remote teleworker just opens a browser pointing to https://<ASA-outside-public-IP>. The browser connects to the ASA firewall and presents the user with a login screen. The user enters his credentials (username/password) and the ASA identifies that the user does not have the SSL client installed. Therefore it pushes the SSL client to the user’s computer. The client installs itself to the remote PC and establishes a secure SSL VPN connection between the remote user and the ASA. The user is also assigned an IP address from an address pool configured on the ASA and has full network access to the central site. When the SSL connection is stopped, the SSL client either uninstalls itself or remains on the user’s PC (depending on the configuration of the ASA).

In the case of a previously installed client, when the user authenticates, the security appliance examines the revision of the client, and upgrades the client as necessary.

The AnyConnect SSL client can be downloaded from the security appliance, or it can be installed manually on the remote PC by the system administrator.

In another post I will explain how to configure the AnyConnect SSL VPN on a Cisco ASA 5500 firewall.

Access Control Lists (ACLs) and Network Address Translation (NAT) are two of the most common features that coexist in the configuration of a Cisco ASA appliance. For both inbound and outbound access control lists, the IP addresses specified in the ACL depend on the interface where the ACL is applied. These IP addresses must be valid on the specific interface that the ACL is attached, regardless of NAT. Keep the following statement in mind: An Access Control List takes precedence over NAT. That is, an ACL is evaluated FIRST and then a NAT rule is applied to the packet.

For example, assume an inside host with private address 10.1.1.10 is translated to a public address 200.200.200.10 for outbound traffic (inside to outside). An ACL applied to the inside interface of the ASA firewall will first be evaluated to verify if the host 10.1.1.10 can access the Internet (outbound communication) and if the ACL permits this communication, only then NAT will be performed to translate 10.1.1.10 to 200.200.200.10. This is shown in the figure below.

See the following commands for the example above:

!The following ACL is evaluated first
ciscoasa(config)# access-list INSIDE extended permit ip host 10.1.1.10 host 100.100.100.1
ciscoasa(config)# access-group INSIDE in interface inside

!NAT can be applied only if ACL allows the communication
ciscoasa(config)# global (outside) 1 200.200.200.10 netmask 255.255.255.255
ciscoasa(config)# nat (inside) 1 0.0.0.0 0.0.0.0

Similarly, a scenario with inbound traffic (outside to inside) works again the same way. That is, an ACL is evaluated first for inbound traffic and then a NAT translation rule is applied. For example, assume we have a Web Server located on the inside network (should be on a DMZ for better security but for the sake of simplicity we assume it is located on the inside network). The private address configured on the Web Server is 10.1.1.10. We configured also static NAT on the Firewall to map the private address of the Web Server to a public address 200.200.200.10 on the outside (see figure below). Inbound traffic coming from the Internet towards the public address of the Web Server will first go through an ACL to verify if the traffic is permitted or not. If traffic is allowed by the ACL, then the static NAT will be applied to translate the destination address from 200.200.200.10 to 10.1.1.10.

See the following commands for the example above:

!The following ACL is evaluated first
ciscoasa(config)# access-list OUTSIDE extended permit tcp any host 200.200.200.10 eq 80
ciscoasa(config)# access-group OUTSIDE in interface outside

! Static NAT can be applied only if ACL allows the communication
ciscoasa(config)# static (inside,outside) 200.200.200.10 10.1.1.10 netmask 255.255.255.255