CLI Book 1: Cisco ASA Series General Operations CLI Configuration Guide, 9.1
Information About Access Lists
Downloads: This chapterpdf (PDF - 189.0 KB) The complete bookPDF (PDF - 12.93 MB) | Feedback

Table of Contents

Information About Access Control Lists

ACL Types

Access Control Entry Order

Access Control Implicit Deny

IP Addresses Used for ACLs When You Use NAT

Where to Go Next

Information About Access Control Lists

Cisco ASAs provide basic traffic filtering capabilities with access control lists (ACLs), which control access in your network by preventing certain traffic from entering or exiting. This chapter describes ACLs and shows how to add them to your network configuration.

ACLs are made up of one or more access control entries (ACEs). An ACE is a single entry in an ACL that specifies a permit or deny rule (to forward or drop the packet) and is applied to a protocol, to a source and destination IP address or network, and, optionally, to the source and destination ports.

ACLs can be configured for all routed and network protocols (IP, AppleTalk, and so on) to filter the packets of those protocols as the packets pass through a router.

ACLs are used in a variety of features. If your feature uses Modular Policy Framework, you can use an ACL to identify traffic within a traffic class map. For more information on Modular Policy Framework, see Chapter 1, “Configuring a Service Policy Using the Modular Policy Framework,” in the firewall configuration guide.

This chapter includes the following sections:

ACL Types

The ASA uses five types of access control lists:

Table 18-1 lists the types of ACLs and some common uses for them.


Table 18-1 ACL Types and Common Uses

ACL Type

Control network access for IP traffic (routed and transparent mode)


The ASA does not allow any traffic from a lower security interface to a higher security interface unless it is explicitly permitted by an extended ACL.

Note To access the ASA interface for management access, you do not also need an ACL allowing the host IP address. You only need to configure management access according to Chapter41, “Configuring Management Access”

Identify traffic for AAA rules


AAA rules use ACLs to identify traffic.

Control network access for IP traffic for a given user

Extended, downloaded from a AAA server per user

You can configure the RADIUS server to download a dynamic ACL to be applied to the user, or the server can send the name of an ACL that you already configured on the ASA.

Identify addresses for NAT (policy NAT and NAT exemption)


Policy NAT lets you identify local traffic for address translation by specifying the source and destination addresses in an extended ACL.

Establish VPN access


You can use an extended ACL in VPN commands.

Identify traffic in a traffic class map for Modular Policy Framework



ACLs can be used to identify traffic in a class map, which is used for features that support Modular Policy Framework. Features that support Modular Policy Framework include TCP and general connection settings, and inspection.

For transparent firewall mode, control network access for non-IP traffic


You can configure an ACL that controls traffic based on its EtherType.

Identify OSPF route redistribution


Standard ACLs include only the destination address. You can use a standard ACL to control the redistribution of OSPF routes.

Filtering for WebVPN


You can configure a Webtype ACL to filter URLs.

Control network access for IPV6 networks


You can add and apply ACLs to control traffic in IPv6 networks.

Access Control Entry Order

An ACL is made up of one or more access control entries (ACEs). Each ACE that you enter for a given ACL name is appended to the end of the ACL. Depending on the ACL type, you can specify the source and destination addresses, the protocol, the ports (for TCP or UDP), the ICMP type (for ICMP), or the EtherType.

The order of ACEs is important. When the ASA decides whether to forward or to drop a packet, the ASA tests the packet against each ACE in the order in which the entries are listed. After a match is found, no more ACEs are checked. For example, if you create an ACE at the beginning of an ACL that explicitly permits all traffic, no further statements are checked, and the packet is forwarded.

Access Control Implicit Deny

All ACLs have an implicit deny statement at the end, so unless you explicitly permit traffic to pass, it will be denied. For example, if you want to allow all users to access a network through the ASA except for one or more particular addresses, then you need to deny those particular addresses and then permit all others.

For EtherType ACLs, the implicit deny at the end of the ACL does not affect IP traffic or ARPs; for example, if you allow EtherType 8037, the implicit deny at the end of the ACL does not now block any IP traffic that you previously allowed with an extended ACL (or implicitly allowed from a high security interface to a low security interface). However, if you explicitly deny all traffic with an EtherType ACE, then IP and ARP traffic is denied.

IP Addresses Used for ACLs When You Use NAT

For the following features, you should always use the real IP address in the ACL when you use NAT, even if the address as seen on an interface is the mapped address:

  • access-group command
  • Modular Policy Framework match access-list command
  • Botnet Traffic Filter dynamic-filter enable classify-list command
  • AAA aaa ... match commands
  • WCCP wccp redirect-list group-list command

The following features use ACLs, but these ACLs use the mapped values as seen on an interface:

  • IPsec ACLs
  • capture command ACLs
  • Per-user ACLs
  • Routing protocols
  • All other features...

Where to Go Next

For information about implementing ACLs, see the following chapters: