Cisco ASA Firewall Archives

Using Object Groups with Cisco ASA

The usage of object groups (network objects, service object etc) is becoming more popular on Cisco ASA firewalls especially with the new OS version 8.3(x). In this version, network object groups are used extensively for the configuration of NAT mechanisms in addition to other uses. In this post I will show a quick example of using network objects with access lists. In another post I will expand this to show how object groups are used with NAT as well.

Suppose we have a few Web servers located on a DMZ which are accessed from the Internet. We want to enable http (80) and https (443) access from internet towards these web servers.

Assume that we have configured static NAT for those web servers and translated their real private IP addresses to the following Public IP addresses:

Web Server1:
Web Server2:
Web Server3:

Configuration of access list using object groups:

! create a service group for the http and https protocols
object-group service http-protocols tcp
port-object eq 80
port-object eq 443

! create a network object group for the web servers
object-group network webservers
network-object host
network-object host
network-object host

! create the access list applied inbound on the outside interface
access-list OUTSIDE-IN extended permit tcp any object-group webservers object-group http-protocols

access-group OUTSIDE-IN in interface outside

EDIT (ASA Versions after 8.3):

In newer ASA versions after 8.3, the access list must always reference the Real IP address of a host and NOT the translated IP address. So, in our example above, the “webservers” object-group must include the Real (private) IP addresses of the servers and not the translated public IP.

! create a network object group for the web servers with their Real private IP
object-group network webservers
network-object host
network-object host
network-object host

! create the access list applied inbound on the outside interface
access-list OUTSIDE-IN extended permit tcp any object-group webservers object-group http-protocols

access-group OUTSIDE-IN in interface outside

One of the ways to configure authentication between two Cisco ASA firewalls having a site-to-site IPSec VPN tunnel between them is to configure a pre-shared key under the tunnel group attributes. This is actually the most common implementation of IPSEC lan-to-lan authentication that you will find in most real life networks.

The pre-shared key must be the same on both IPSEC VPN devices between which the secure tunnel is created. To configure the pre-shared key on a Cisco ASA:

tunnel-group type ipsec-l2l
tunnel-group ipsec-attributes
pre-shared-key key123

Now, after configuring the pre-shared key, it is stored as encrypted hash on the ASA appliance and therefore when you view the running configuration (show run) you don’t see the actual clear text key anymore (i.e instead of “key123” you will see “*”).

Ciscoasa# show run

tunnel-group type ipsec-l2l
tunnel-group ipsec-attributes
pre-shared-key *

The problem arises when you forget the pre-shared key after a few months and you want to change one of the VPN tunnels. This situation happened to me recently when I had to change the public IP address on one of the ASA sites which had a Lan-to-Lan tunnel with a second ASA. Therefore I had to reconfigure the tunnel group and re-enter the old pre-shared key. However, I did not have it stored in clear text anywhere. The way to recover the pre-shared key is actually simple. Use the more system:running-config command. This command shows the pre-shared key in clear text format:

Ciscoasa# more system:running-config

tunnel-group ipsec-attributes
pre-shared-key key123

The following article describes how to configure Access Control Lists (ACL) on Cisco ASA 5500 firewalls. An ACL is the central configuration feature to enforce security rules on your network.

The Cisco ASA 5500 is the new Cisco firewall model series which followed the successful Cisco PIX firewall appliance. Cisco calls the ASA 5500 a “security appliance” instead of just a “hardware firewall”, because the ASA is not just a firewall. This device combines several security functionalities, such as Intrusion Detection, Intrusion Prevention, Content Inspection, Botnet Inspection, in addition to the firewall functionality.

However, the core ASA functionality is to work as a high performance firewall. All the other security features are just complimentary services on top of the firewall functionality. Having said that, the purpose of a network firewall is to protect computer and IT resources from malicious sources by blocking and controlling traffic flow. The Cisco ASA firewall achieves this traffic control using Access Control Lists (ACL).

An ACL is a list of rules with permit or deny statements. Basically an Access Control List enforces the security policy on the network. The ACL (list of policy rules) is then applied to a firewall interface, either on the inbound or on the outbound traffic direction. If the ACL is applied on the inbound traffic direction (in), then the ACL is applied to traffic entering a firewall interface. The opposite happens for ACL applied to the outbound (out) direction.

The ACL permit or deny statements basically consist of source and destination IP addresses and ports. A permit ACL statement allows the specified source IP address/network to access the specified destination IP address/network. The opposite happens for deny ACL statements. At the end of the ACL, the firewall inserts by default an implicit DENY ALL statement rule which is not visible in the configuration.

Enough theory so far. Let us see some examples below to clarify what we have said above.

The basic command format of the Access Control List is the following:

ciscoasa(config)# access-list “access_list_name” extended {deny | permit} protocol “source_address” “mask” [source_port] “dest_address” “mask” [ dest_port]

To apply the ACL on a specific interface use the access-group command as below:

ciscoasa(config)# access-group “access_list_name” [in|out] interface “interface_name”

Example 1:

Allow only http traffic from inside network to outside internet

ciscoasa(config)# access-list HTTP-ONLY extended permit tcp any eq 80

ciscoasa(config)# access-group HTTP-ONLY in interface inside

The name “HTTP-ONLY” is the Access Control List itself, which in our example contains only one permit rule statement. Remember that there is an implicit DENY ALL rule at the end of the ACL which is not shown by default.

Example 2:

Deny telnet traffic from host to host and allow everything else.

ciscoasa(config)# access-list DENY-TELNET extended deny tcp host host eq 23

ciscoasa(config)# access-list DENY-TELNET extended permit ip host host

ciscoasa(config)# access-group DENY-TELNET in interface inside

The above example ACL (DENY-TELNET) contains two rule statements, one deny and one permit. As we mentioned above, the “access-group” command applies the ACL to an interface (either to an inbound or to an outbound direction).

Example 3:

The example below will deny ALL TCP traffic from our internal network towards the external network Also, it will deny HTTP traffic (port 80) from our internal network to the external host All other traffic will be permitted from inside.

ciscoasa(config)# access-list INSIDE_IN extended deny tcp

ciscoasa(config)# access-list INSIDE_IN extended deny tcp host eq 80

ciscoasa(config)# access-list INSIDE_IN extended permit ip any any

ciscoasa(config)# access-group INSIDE_IN in interface inside

A very popular scenario for small networks is to have a Cisco ASA 5505 as border firewall connecting the LAN to the Internet. Administrators in such networks are usually encountered with requests from their users that are not very security conscious. Such a request could be to allow Remote Desktop access from the Internet to an internal Windows server. This might be very helpful for users who want to work from home but I would not recommend it. If you have to implement such a scenario, I suggest that you put the Remote Desktop server in a DMZ and not directly in the internal network. However, companies with limited budget might have purchased a Cisco ASA 5505 with basic license which restricts the creation of a DMZ Vlan (although you can create 3 Vlans, the third Vlan can only communicate with one of the other two Vlans but not both). So, let’s see a typical network topology with ASA 5505 basic license and an internal Remote Desktop server.

Again, I don’t recommend such a network topology as shown above. Remote Desktop machines are very prone to attacks, especially brute-force password attacks. In windows, the administrator account does not get locked-out by default. So a brute force administrator password attack on the RDP server from remote attackers can be successful especially if the administrator password is weak. In any case, if you are “forced” to implement such a scenario, here is the configuration:


Assume that the ASA receives IP address dynamically from the ISP (via DHCP protocol). So the outside IP of the ASA is not fixed. Therefore, we will configure static NAT with port redirection using the outside interface. Since the outside address is dynamic, you can use a service such as DynDNS to get a fixed domain name irrespective of the IP mapped with it. The following is a configuration snapshot for ASA versions prior to 8.3 and for ASA 8.3 as well.

ASA version prior to 8.3
ciscoasa(config)# static (inside , outside) tcp interface 3389 3389 netmask
ciscoasa(config)# access-list OUTSIDE-IN extended permit tcp any any eq 3389
ciscoasa(config)# access-group OUTSIDE-IN in interface outside

ASA version 8.3 and later
ciscoasa(config)# object network RDP_static
ciscoasa(config-network-object)# host
ciscoasa(config-network-object)# nat (inside , outside) static interface service tcp 3389 3389
ciscoasa(config)# access-list OUTSIDE-IN extended permit tcp any host eq 3389
ciscoasa(config)# access-group OUTSIDE-IN in interface outside

NOTE: Notice that in version 8.3 we reference the Real IP address ( in the access-list and not the mapped IP

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.

 Page 5 of 15  « First  ... « 3  4  5  6  7 » ...  Last »