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.
Standard ACLs—Identify the destination IP addresses of OSPF routes and can be used in a route map for OSPF redistribution. Standard ACLs cannot be applied to interfaces to control traffic. For more information, see Chapter21, “Adding a Standard Access Control List”
Extended ACLs—Use one or more access control entries (ACE) in which you can specify the line number to insert the ACE, the source and destination addresses, and, depending upon the ACE type, the protocol, the ports (for TCP or UDP), or the IPCMP type (for ICMP). For more information, see Chapter19, “Adding an Extended Access Control List”
Table 18-1 lists the types of ACLs and some common uses for them.
Table 18-1 ACL Types and Common Uses
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:
Modular Policy Framework match access-list command