ACLGlobal Config

access-list [name] extended permit [proto] [src] [dst]

Creates an extended access control list (ACL) entry to permit traffic based on protocol, source, and destination.

Overview

The 'access-list [name] extended permit [protocol] [src] [dst]' command is fundamental for defining traffic filtering policies on Cisco ASA firewalls. Extended ACLs allow granular control based on source and destination IP addresses, protocol (e.g., TCP, UDP, ICMP), and port numbers. This command is used in global configuration mode to create named ACL entries. The ASA processes ACLs in sequential order, matching traffic against the first rule that applies. Understanding this command is crucial for implementing security policies, segmenting networks, and controlling access between security zones (inside, outside, DMZ). In troubleshooting workflows, ACLs are often the first place to check when traffic is unexpectedly blocked. The ASA's ACL implementation differs from IOS in that it uses subnet masks instead of wildcard masks, and it supports object groups for scalability. Proper ACL design minimizes security risks and ensures legitimate traffic flows.

Syntax·Global Config

access-list [name] extended permit [protocol] [source_address] [source_mask] [destination_address] [destination_mask]

When to Use This Command

Permitting HTTP traffic from a specific internal subnet to a web server in the DMZ.
Allowing ICMP echo requests from a management station to the firewall interface for monitoring.
Permitting SSH access from a remote admin network to the inside interface for management.
Allowing DNS queries from internal clients to an external DNS server.

Parameters

Parameter	Syntax	Required	Description
name	WORD	Required	A descriptive name for the ACL. It must be unique and can contain letters, numbers, and hyphens. The name is used to reference the ACL when applying it to an interface.
protocol	tcp \| udp \| icmp \| ip \| <protocol-number>	Required	The IP protocol to permit. Common values are tcp, udp, icmp, or ip (all protocols). You can also specify a protocol number (e.g., 6 for TCP).
source_address	A.B.C.D	Required	The source IP address or network. Use 'host A.B.C.D' for a single host or 'any' for all sources.
source_mask	A.B.C.D	Required	The subnet mask for the source address. For a host, use 255.255.255.255. For a network, use the appropriate mask (e.g., 255.255.255.0 for /24).
destination_address	A.B.C.D	Required	The destination IP address or network. Similar to source, use 'host' or 'any' as needed.
destination_mask	A.B.C.D	Required	The subnet mask for the destination address.

Command Examples

Permit HTTP from internal subnet to DMZ web server

access-list INSIDE_TO_DMZ extended permit tcp 10.1.1.0 255.255.255.0 192.168.1.100 255.255.255.255 eq 80

This command creates an ACL entry named INSIDE_TO_DMZ that permits TCP traffic from source network 10.1.1.0/24 to destination host 192.168.1.100 on port 80 (HTTP). No output is generated on success.

Permit ICMP echo from management station

access-list MGMT extended permit icmp host 10.10.10.10 host 192.168.0.1 echo

This command permits ICMP echo requests (ping) from host 10.10.10.10 to host 192.168.0.1. The 'host' keyword specifies a single IP address.

Understanding the Output

The access-list command itself does not produce output when entered. To view the configured ACL, use 'show access-list [name]'. The output lists each ACE with a sequence number, permit/deny action, protocol, source, destination, and hit count. For example: 'access-list INSIDE_TO_DMZ; 1 elements; name hash: 0x...' followed by 'access-list INSIDE_TO_DMZ line 1 extended permit tcp 10.1.1.0 255.255.255.0 192.168.1.100 255.255.255.255 eq 80 (hitcnt=0)'. The hitcnt shows how many times the rule has matched traffic; a zero hitcnt may indicate the rule is not being used or traffic is not matching. Healthy values are non-zero for expected traffic. Problem values are zero for rules that should be active.

Configuration Scenarios

Permit Web Traffic from Inside to DMZ

An organization has an internal network (10.1.1.0/24) and a DMZ with a web server at 192.168.1.100. The goal is to allow HTTP access from internal users to the web server.

Topology

Inside (10.1.1.0/24) --- ASA --- DMZ (192.168.1.100)

Steps

1.Create the ACL entry: access-list INSIDE_TO_DMZ extended permit tcp 10.1.1.0 255.255.255.0 host 192.168.1.100 eq 80
2.Apply the ACL to the inside interface in the inbound direction: access-group INSIDE_TO_DMZ in interface inside

Configuration

! ACL configuration
access-list INSIDE_TO_DMZ extended permit tcp 10.1.1.0 255.255.255.0 host 192.168.1.100 eq 80
! Apply to interface
access-group INSIDE_TO_DMZ in interface inside

Verify: Use 'show access-list INSIDE_TO_DMZ' to verify the entry and check hit counts. Use 'show access-group' to confirm the ACL is applied to the interface.

Watch out: Ensure the ACL is applied to the correct interface and direction. Inbound on the inside interface means traffic coming from inside to the ASA. Also, remember that ASA ACLs are stateful; return traffic is automatically allowed.

Troubleshooting with This Command

When traffic is not passing as expected, start by verifying the ACL configuration with 'show access-list [name]'. Check the hit counts: if a rule has zero hits, traffic may not be matching that rule. Ensure the ACL is applied to the correct interface and direction using 'show access-group'. Use 'packet-tracer' to simulate traffic and see which ACL rule is matched. For example: 'packet-tracer input inside tcp 10.1.1.10 12345 192.168.1.100 80'. This will show the ACL processing steps. Also, verify that there are no implicit deny rules blocking traffic; the ASA has an implicit deny at the end of every ACL. If the ACL is correct but traffic is still blocked, check for NAT rules, routing, or interface security levels. Remember that ACLs on the ASA are applied before NAT; ensure the ACL uses pre-NAT addresses. If using object groups, verify they are correctly defined. Finally, clear ACL counters with 'clear access-list [name] counters' to reset hit counts for fresh troubleshooting.

CCNA Exam Tips

Remember that ACLs are processed top-down; order matters. Use 'show access-list' to verify sequence numbers.

On ASA, ACLs are applied to interfaces using the 'access-group' command in global config mode.

Know that the 'extended' keyword is required for ACLs with protocol and port specifications.

Common Mistakes

Forgetting to apply the ACL to an interface with 'access-group', causing the ACL to have no effect.

Using incorrect subnet masks (e.g., using wildcard masks instead of subnet masks; ASA uses subnet masks in ACLs).

Omitting the 'extended' keyword, which results in a standard ACL that cannot filter by protocol or port.

Platform Notes

On Cisco ASA, ACLs use subnet masks (e.g., 255.255.255.0) instead of wildcard masks used in IOS. The ASA also supports object groups to simplify ACL management. Unlike IOS, the ASA's ACLs are stateful; only the initial packet is checked against the ACL, and return traffic is automatically permitted. The 'access-list extended' command is similar to IOS but with different mask syntax. On ASA version 9.x and later, ACLs can be configured with network objects and service objects for easier management. The command 'show access-list' displays hit counts, which are useful for monitoring. For troubleshooting, the 'packet-tracer' tool is ASA-specific and invaluable. When migrating from IOS to ASA, remember to convert wildcard masks to subnet masks.

Practice for the CCNA 200-301

Test your knowledge with hundreds of CCNA practice questions covering all exam domains.

Practice CCNA Questions