# Named ACL

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/named-acl

## Quick definition

A Named Access Control List (ACL) is a set of rules on a router or switch that decides what network traffic is allowed or denied. Instead of using a number, it uses a descriptive name, making it easier to remember and edit. Named ACLs are used to filter traffic for security and network management.

## Simple meaning

Imagine you are the security guard at the entrance of a large office building. You have a list of people who are allowed to enter based on their ID badges. A standard list might just use a number, like "List 10," and it checks only the badge color. But a Named ACL is like having a list called "After-Hours Vendors" that allows only suppliers with a specific badge and a delivery note. 

In a computer network, a Named ACL works the same way. It is a group of rules, identified by a name you choose, that tells the network device (like a router or firewall) which data packets to let through and which to block. The device looks at each packet's source and destination IP addresses, the type of traffic (like web, email, or file transfer), and the specific port numbers (like port 80 for web traffic). If the packet matches a rule that permits it, it passes. If it matches a deny rule, it is dropped. If no rule matches, the packet is denied by default, just like an unlisted visitor is turned away at the door. 

For example, a Named ACL called "BLOCK_BAD_IPS" could be set up on a company router to block all traffic from a known malicious IP address. Another Named ACL called "ALLOW_HR_ONLY" could let only the HR department's computers access a sensitive payroll server. Because the names are descriptive, network engineers can quickly understand what each ACL is for without memorizing numbers. This makes Named ACLs much easier to manage in large networks where dozens or hundreds of ACLs exist. Also, Named ACLs allow you to insert new rules at any position in the list, which gives you more flexibility when updating security policies.

## Technical definition

A Named Access Control List (ACL) is a sequential set of permit or deny statements applied to a network interface on a router, switch, or firewall to control traffic flow based on Layer 3 (IP) and Layer 4 (TCP/UDP) information. Unlike numbered ACLs, which are identified by a standard or extended number range (e.g., 1-99 for standard IP ACLs, 100-199 for extended IP ACLs), Named ACLs use an alphanumeric name, which provides greater readability and administrative flexibility. Named ACLs were introduced in Cisco IOS Software Release 11.2 and are now standard across most network devices. 

Named ACLs can be used as standard ACLs (filtering only source IP address) or extended ACLs (filtering source and destination IP addresses, protocols, and port numbers). They are also used for more advanced functions like reflexive ACLs, dynamic ACLs (lock-and-key), and time-based ACLs. The key difference is that Named ACLs support both standard and extended capabilities and allow for easier editing. In a numbered ACL, all statements are tied to the number, and inserting a new rule at a specific position often requires deleting the entire ACL and recreating it. With Named ACLs, you can use sequence numbers (e.g., 10, 20, 30) to insert or delete individual rules without removing the whole list. 

When a packet arrives at an interface with a Named ACL applied, the device processes the packet through the ACL in sequential order from the top down. It checks the packet against each rule until it finds a match. The first matching rule determines the action, permit or deny. If no match is found, the packet is denied by the implicit deny all rule at the end of every ACL. This default deny behavior is critical for security: anything not explicitly permitted is automatically blocked. Named ACLs are typically applied inbound (traffic entering the interface) or outbound (traffic leaving the interface). Best practices recommend placing ACLs as close to the source as possible to conserve bandwidth by dropping unwanted traffic early. 

In real IT implementations, Named ACLs are configured on routers, multilayer switches, and firewalls. For example, a Cisco router uses the "ip access-list extended [name]" command to create or edit the list. Inside the ACL, individual rules are defined with sequence numbers using the "[sequence] permit tcp host [source] host [destination] eq [port]" syntax. After configuration, the ACL is applied to an interface with the "ip access-group [name] in" or "ip access-group [name] out" command. Modern firewalls like Palo Alto, Fortinet, and AWS Security Groups use similar named rule sets, though AWS Security Groups are stateful and do not use implicit deny in the same way. Nonetheless, the concept of named rule collections is foundational across IT certification exams.

## Real-life example

Think of a airport security checkpoint. The airport has many gates, each for a different airline. The security agents do not just let anyone through, they have specific lists of authorized personnel for each zone. Now, imagine the old way was to give each gate a numbered list: "List 5" for gate A, "List 7" for gate B. If you wanted to add a new cleaner to gate A, you had to rewrite the entire list from scratch because you could not just insert a name in the middle. That was the hassle of numbered ACLs. 

But then the airport switched to named lists. Now, the gate for Southwest Airlines has a list called "SOUTHWEST_CREW." This list contains the names, badge numbers, and security clearances of all employees allowed through that gate. If a new pilot joins, the security supervisor can add that pilot's name at any position in the "SOUTHWEST_CREW" list, between the first officer and the flight attendant, without affecting the rest. If a contractor needs temporary access to a specific gate, the supervisor creates a second list called "GATE_A_CONTRACTORS." Each list has a clear name that tells everyone what it is for. This is exactly what a Named ACL does for network traffic: it gives each rule set a meaningful name, and you can add, remove, or reorder rules easily. 

The security checkpoint also checks more than just a name, it checks the person's destination (like the destination IP) and their reason for traveling (like the protocol). For instance, a pilot might be permitted to go to any gate, but a cleaner is allowed only to the restrooms. Similarly, a Named Extended ACL can allow web traffic from HR to the payroll server but block file transfers from the same HR computers to the same server. By naming the ACL "HR_PAYROLL_ONLY," the network engineer instantly knows the purpose. The airport analogy maps directly to network security: you have a list of rules that decide who gets through, and you can manage those lists without chaos, which saves time and reduces errors.

## Why it matters

In IT environments, access control is one of the most fundamental security mechanisms. Named ACLs matter because they allow network administrators to create and manage security policies in a clear, organized, and efficient manner. Without them, a network could have dozens of numbered ACLs, and memorizing what ACL 101 does compared to ACL 115 would be nearly impossible in a large enterprise. Using names like "DENY_SSH_TO_CORE" or "ALLOW_DNS_SERVERS" makes the purpose obvious, reducing the risk of misconfiguration and security breaches. 

Named ACLs also matter because they support atomic edits. In busy production networks, you often need to add a new rule to block a newly discovered malicious IP address. With a numbered ACL, you might have to delete the entire ACL and reconfigure it from scratch, which could cause a brief window where no ACL is active, exposing the network. With a Named ACL, you can simply add a new rule at the top (using a sequence number like 5) to block the IP immediately, without taking the ACL offline. This capability is critical for incident response. 

Named ACLs are essential for fine-grained traffic filtering. Extended Named ACLs can filter based on source and destination IP, protocol type (TCP, UDP, ICMP), and port numbers, allowing you to craft security policies that are both precise and effective. For example, you can allow web traffic to a specific server but block all other traffic, including ping requests. This reduces the attack surface. Finally, Named ACLs appear in major cloud platforms like AWS (Security Groups are named rule collections), Azure (Network Security Groups), and Google Cloud (Firewall Rules), so understanding the concept is directly transferable to cloud network security. For any IT professional working on network security, from a help desk technician to a cloud architect, mastering Named ACLs is indispensable.

## Why it matters in exams

Named ACLs appear frequently in the CCNA and Network+ exams, and they hold significant weight in Security+, AWS SAA, AZ-104, and Google ACE exams, albeit in different contexts. In CCNA (200-301), the exam objectives explicitly include configuring and verifying Extended ACLs, including Named ACLs. You are expected to understand the difference between standard and extended ACLs, the order of evaluation, the implicit deny, and how to apply ACLs to interfaces. Questions often ask you to interpret a configuration or identify why a specific traffic flow is blocked. 

In Network+, the term is part of the network security domain (Objective 4.1). You may see multiple-choice questions that ask about the advantages of Named ACLs over numbered ACLs, such as easier editing and better readability. You might also be presented with a scenario where a network is down, and you must identify that a misconfigured ACL is blocking DHCP or DNS traffic. 

Security+ (SY0-601) focuses more on the security concepts: the principle of least privilege, default deny, and access control list types. While Security+ does not require you to configure ACLs on a router, you need to understand that ACLs are a tool for network access control and that Named ACLs provide better manageability. The exam may ask about how ACLs can be used to segment networks or block malicious traffic. 

For AWS SAA (AWS Certified Solutions Architect Associate), Named ACLs are analogous to Network ACLs (NACLs), which are stateless and have numbered rules (e.g., rule #100, #110). You need to know that NACLs support allow and deny rules and are evaluated in order, just like Named ACLs. The exam tests your ability to design a VPC with properly configured NACLs and Security Groups. In AZ-104 (Microsoft Azure Administrator), Azure Network Security Groups (NSGs) are also named collections of security rules that can be applied to subnets and NICs. The exam covers how to create NSGs, associate them, and understand rule priority. 

Google ACE (Google Associate Cloud Engineer) includes firewall rules in VPC networks, which function similarly to Named ACLs but with priority values. Across all these exams, the underlying concept is the same: a named list of ordered rules that control traffic. The exam questions vary in format: scenario-based (choose the correct ACL configuration), troubleshooting (why is traffic not passing?), and best-practice (which type of ACL should you use?). Understanding Named ACLs deeply will pay off across multiple certification paths.

## How it appears in exam questions

Exam questions about Named ACLs typically fall into three categories: scenario-based, configuration, and troubleshooting. In scenario-based questions, you are given a network topology with multiple subnets and servers, and you must decide which Named ACL to apply on which interface. For example: "The HR server at 192.168.10.10 should only be accessible from the HR subnet (192.168.20.0/24) on port 443. All other traffic should be denied. Which ACL configuration meets these requirements?" The answer choices will include various named ACLs with different rules. You must check whether the ACL is applied inbound or outbound, the direction matters. 

Configuration questions often ask you to complete a command or identify the correct syntax. For instance: "An administrator wants to create an extended Named ACL called BLOCK_TELNET that denies Telnet traffic from any source to the server 10.0.0.5. Which set of commands accomplishes this?" You need to know that the command is "ip access-list extended BLOCK_TELNET" followed by "deny tcp any host 10.0.0.5 eq 23" and then "permit ip any any" (unless you want to deny all traffic). The CCNA and Network+ exams may also ask about the order of rules: "An ACL denies traffic from 192.168.1.0/24 but permits traffic from 192.168.1.0/24 to 10.0.0.1. Which rule should be placed first?" (The more specific rule should come first). 

Troubleshooting questions present a scenario where users cannot access a resource, and you must examine the ACL configuration to find the error. Common errors include: wrong interface direction (inbound vs outbound), misplaced deny statement that blocks legitimate traffic, forgetting to add the permit ip any any statement after explicit denies, or applying the ACL to the wrong interface. For example: "Users in the Sales VLAN cannot access the internet. The ACL INTERNET_ACCESS is applied to the outside interface. What is likely the issue?" The correct answer might be that the ACL is missing a permit rule for return traffic from the internet back to Sales, or it is applied to the wrong interface direction. By understanding these patterns, you can quickly zero in on the correct answer. Exam creators also love to test the implicit deny: they will present an ACL with only permit statements and ask what happens to traffic that does not match any rule, it is denied.

## Example scenario

Company XYZ has two departments: Marketing and Engineering. The Marketing team uses the network 192.168.10.0/24, and Engineering uses 192.168.20.0/24. There is a file server at 192.168.30.10 that should be accessible only from Engineering on port 445 (SMB). The company also has a web server at 192.168.30.20 that everyone in the company should be able to access on port 80 and 443. The CEO wants a Named ACL called "SERVERS_ACCESS" that implements this policy. 

The network administrator configures the Named ACL as follows: first, the ACL permits TCP traffic from Engineering (192.168.20.0/24) to the file server (192.168.30.10) on port 445. Second, it permits TCP traffic from any source to the web server (192.168.30.20) on ports 80 and 443. Then, the administrator applies this ACL to the router interface facing the servers in the inbound direction. However, when Marketing users try to access the web server, they are blocked. Why? Because there is an implicit deny all at the end of the ACL. The Marketing users (192.168.10.0/24) do not match the first rule (only for Engineering), and they match the second rule (permit to web server), so they should be allowed. But wait, the administrator made a mistake: the ACL includes a rule that denies all traffic from the Marketing subnet to any server, which was placed before the web server permit rule. So, the Marketing traffic hits the deny rule first and is blocked. 

To fix this, the administrator must rearrange the ACL rules so that the permit for the web server comes before the deny for Marketing. Alternatively, he can remove the specific deny rule for Marketing and rely on the implicit deny, but then Marketing would be denied to all servers anyway, which is not the goal. The correct solution is to have the web server permit rule before any broad deny rule. This scenario shows the importance of rule order in Named ACLs and how easy it is to accidentally block legitimate traffic.

## Understanding Named ACL Syntax and Structure

Named Access Control Lists (ACLs) represent a significant advancement over traditional numbered ACLs in network security configuration. Instead of relying on a numeric identifier between 1 and 199 for standard ACLs or 100 to 199 for extended ACLs, named ACLs use a descriptive word or phrase that immediately conveys the purpose of the rule set. The fundamental syntax for creating a named ACL on a Cisco IOS device begins with the command 'ip access-list extended <name>' or 'ip access-list standard <name>', followed by a succession of permit or deny statements. This structured approach eliminates the guesswork that often plagues numbered lists, especially in large enterprise environments where dozens of ACLs may exist. The naming convention must be unique per device and cannot include spaces unless enclosed in quotes, but it can contain letters, numbers, hyphens, and underscores. A typical network administrator might use names like 'BLOCK_OUTBOUND_RDP' or 'ALLOW_WEB_TRAFFIC' to make the purpose instantly clear. Once the ACL is created, individual entries are added in sequence using subcommands such as 'permit tcp any any eq 80' or 'deny ip 192.168.1.0 0.0.0.255 any'. The power of named ACLs lies not only in readability but also in the flexibility to modify entries dynamically. With numbered ACLs, removing a single line typically requires deleting and recreating the entire list; however, named ACLs allow for the insertion, deletion, or resequencing of individual entries using sequence numbers. When an administrator issues 'ip access-list extended MY_ACL', they enter a configuration mode where they can use 'no permit tcp any any eq 443' to remove a specific rule or '5 permit tcp host 10.0.0.1 any eq 22' to insert a rule at a specific position. This granular control drastically reduces configuration errors and downtime. On Cisco devices, named ACLs also support additional features such as remark statements for documentation, using 'remark <text>' within the ACL configuration mode. Exams such as CCNA, Network+, and Security+ heavily emphasize the syntax differences between numbered and named ACLs, particularly the ability to edit individual entries and the required order of operations. Understanding how to interpret and construct a named ACL from a given scenario is a common exam objective. The administrator must also remember that named ACLs are applied to interfaces exactly like numbered ACLs, using the 'ip access-group <name> in' or 'ip access-group <name> out' command under interface configuration mode. The directional application-inbound or outbound-is critical; an inbound ACL filters traffic before it reaches the router's routing engine, while an outbound ACL filters traffic after it has been routed but before it exits the interface. Misunderstanding this direction can lead to security breaches or unintended traffic blocks. Named ACLs provide a superior method for organizing, documenting, and maintaining access control lists, and mastering their syntax is essential for any network or security professional.

## How Named ACL Editing Improves Security Management

One of the most compelling advantages of named ACLs over their numbered counterparts is the unprecedented flexibility in editing and modification. In traditional numbered ACLs, if you need to remove a specific permit or deny statement located in the middle of the list, you must delete the entire ACL and then recreate it with the correct order. This process is error-prone and often requires a temporary network outage or a carefully timed maintenance window. Named ACLs solve this problem by using an integrated sequence numbering system that allows administrators to remove, insert, or reorder entries without disrupting the entire ACL. When you create a named ACL, each entry is automatically assigned a sequence number (by default, increments of 10 such as 10, 20, 30). If you later need to add a new rule between two existing entries, you can simply specify a sequence number that falls between them, like issuing '15 permit tcp 10.0.0.0 0.255.255.255 any eq 443' to insert a rule between entries 10 and 20. The device will automatically reorder the ACL accordingly. Similarly, deleting a specific entry is straightforward: 'no permit ip 192.168.1.0 0.0.0.255 any'. This changes the troubleshooting and remediation workflow dramatically. For example, if a security team discovers that a certain IP subnet should be blocked from SSH access, they can instantly add a deny statement at the beginning of the existing ACL without affecting other rules. Named ACLs support resequencing commands such as 'ip access-list resequence <name> <starting-sequence> <increment>' which allows the administrator to renumber the entries to make room for future additions. This is especially useful in dynamic environments where rules are frequently updated. The ability to add remarks at specific sequence points further enhances documentation. For instance, adding '10 remark Allow internal users to web servers' followed by the permit statement makes the configuration self-documenting. In exam scenarios, particularly in CCNA and Security+, questions often present a scenario where an existing named ACL needs to be modified to block a particular traffic pattern without disrupting existing allowed flows. The correct answer usually involves inserting a new deny statement with an appropriate sequence number before the existing permit statements. It is also crucial to understand that the order of processing is sequential from top to bottom. The first matching entry determines the action, so new entries intended to block traffic must be placed before any subsequent permit statements. Many exam questions test this exact concept by presenting a flawed numbering scheme. Mastery of named ACL editing is not only an exam requirement but a real-world skill that reduces configuration errors and improves response times during security incidents.

## Applying Named ACLs to Network Interfaces for Inbound and Outbound Filtering

Once a named ACL is defined, it must be applied to a router or Layer 3 switch interface to take effect. The application point and direction are critical to the ACL's behavior. The command to apply a named ACL is 'ip access-group <acl-name> <in|out>' under interface configuration mode. The 'in' direction filters packets as they enter the interface before the routing decision is made. This means the ACL inspects packets sourced from devices connected to that interface and destined for any network reachable by the router. Conversely, the 'out' direction filters packets after the routing lookup is completed but just before they exit the interface. This distinction is vital for designing effective security policies. For example, to prevent external users from initiating connections to internal servers, an inbound ACL on the external interface would block incoming SYN packets. However, if you need to restrict which internal users can access the internet, an outbound ACL on the internal interface is more appropriate because it catches traffic after the router has decided to forward it out the external interface. In Cisco IOS, only one ACL per direction per interface can be applied. That means you can have one inbound and one outbound ACL on a single interface, but not two inbound ACLs. This limitation makes it essential to carefully plan what is included in each ACL. Named ACLs applied to interfaces also support logging, using the 'log' keyword at the end of a permit or deny statement. When logging is enabled, the router generates syslog messages whenever a packet matches that rule, providing valuable auditing and troubleshooting information. On exam-related topics like CCNA and Network+, there is a strong emphasis on correctly identifying which interface and direction to apply an ACL based on a given security requirement. Questions may describe a network topology with multiple routers and VLANs, and the candidate must determine whether an ACL should be applied inbound on the WAN interface or outbound on the LAN interface. Understanding that filtering inbound minimizes unnecessary routing lookups for denied traffic is a key performance consideration. Cloud-related exams such as AWS-SAA and Google ACE have parallel concepts in security group rules (stateful) and network ACLs (stateless) applied to subnets or VPCs. While the syntax differs, the logical application of inbound versus outbound rules remains similar. For Azure AZ-104, Network Security Groups (NSGs) applied to subnets follow a comparable paradigm. Familiarity with the Cisco-style interface application helps in understanding these cloud equivalents. In practice, careful documentation of which ACLs are applied where is non-negotiable. A common troubleshooting scenario involves an interface with an applied named ACL that accidentally blocks necessary traffic after a modification. The network administrator should always verify the configuration with 'show ip access-lists <name>' and 'show run interface <interface>' to confirm the application. Applying named ACLs is a straightforward yet critical step that requires accurate direction and interface selection.

## Implicit Deny and Order Evaluation Logic in Named ACLs

Every named ACL, whether standard or extended, includes an implicit deny all statement at its end. This means that any traffic that does not match a preceding permit or deny rule is automatically dropped. Understanding the implicit deny is fundamental to creating effective ACLs and is a recurring theme in exams like Security+, CCNA, and Network+. If no permit statements are included in the ACL, all traffic is blocked, which can lead to unintentional outages. For example, if an administrator creates a named ACL called 'ALLOW_HTTP' with only 'permit tcp any any eq 80', then all other traffic such as SSH, DNS, and ICMP will be implicitly denied when the ACL is applied to an interface. This often surprises newcomers who expect the router to allow everything by default. The implicit deny does not appear in the ACL listing when displayed with 'show ip access-list', but it logically exists. The order of evaluation is strictly sequential from the top (lowest sequence number) to the bottom. Once a packet matches a rule, the corresponding action (permit or deny) is executed, and no further rules are evaluated. This top-down processing makes the placement of rules extremely important. For instance, if you want to permit all traffic from a specific host while denying traffic from a subnet, the specific permit rule must come before the broader deny rule. Reversing the order would cause the host’s traffic to be denied by the subnet rule before it reaches the permit rule. Named ACLs allow the use of 'any' to match all sources or destinations, and 'host' to match a single IP address. Network masks in ACLs use wildcard masks (inverse masks) such as 0.0.0.255 for a Class C subnet, not subnet masks. This is a frequent point of confusion. For example, 'deny ip 192.168.1.0 0.0.0.255 any' blocks all hosts in the 192.168.1.0/24 subnet, whereas 'deny ip 192.168.1.1 0.0.0.0 any' blocks only that specific host. Implicit deny also interacts with logging; if the last rule is an explicit 'deny ip any any log', it can help detect malicious probes. However, adding an explicit deny at the end does not change the logic-it is already there implicitly. The only advantage is the ability to add logging, which can be crucial for incident response. In cloud environments like AWS, network ACLs are stateless and also have an implicit deny, but the order of rules is evaluated in numeric order (lower numbers first). This similarity extends the relevance of the concept across multiple platforms tested in AWS-SAA, Google ACE, and AZ-104 exams. Understanding that ACLs are first-match and that the implicit deny is unavoidable helps engineers design more secure and predictable networks. A common exam trick involves presenting an ACL with only deny statements and asking whether traffic gets through; the correct answer is that only traffic not matching any deny is permitted, which is none due to implicit deny. Another trick is to ask where to place a new permit rule for a specific host to avoid disruption after an existing permit for the entire subnet. The answer is before the subnet permit, with a lower sequence number. Mastering this logic is indispensable for exam success and real-world security.

## Common mistakes

- **Mistake:** Applying the Named ACL to the wrong interface direction (inbound vs outbound).
  - Why it is wrong: The direction determines which traffic the ACL filters. Applying an inbound ACL meant for incoming traffic on an outbound interface will not filter the intended traffic, and vice versa.
  - Fix: Always visualize the traffic flow: if you want to filter traffic entering the interface, use 'in'; if filtering traffic leaving the interface, use 'out'. Place the ACL on the interface closest to the source of the traffic you want to filter.
- **Mistake:** Forgetting the implicit deny 'deny ip any any' rule and assuming unlisted traffic is permitted.
  - Why it is wrong: The implicit deny blocks all traffic that does not match any permit statement. This can cause unintended blocks, especially when you think you have permitted everything you need.
  - Fix: Always include an explicit 'permit ip any any' at the end of your ACL if you want to allow all traffic that is not explicitly denied. However, if you want strict security, rely on the implicit deny and explicitly permit only necessary traffic.
- **Mistake:** Placing a broad deny rule before a more specific permit rule.
  - Why it is wrong: ACLs are processed top-down. If a broad deny rule matches traffic that you later want to permit, the traffic will be denied before reaching the permit rule.
  - Fix: Order your rules from most specific to most general. Always put your permit statements before any broader deny statements that might catch the same traffic.
- **Mistake:** Using 'permit ip any any' as the first rule, which bypasses all subsequent rules.
  - Why it is wrong: Since ACLs stop after the first match, placing a blanket permit as the first rule will allow all traffic and nullify any deny rules placed after it.
  - Fix: Place specific deny or permit rules first. Only put 'permit ip any any' at the very end of the ACL (after all deny rules) if you intend to allow all remaining traffic.
- **Mistake:** Not including sequence numbers when editing a Named ACL, causing rules to be appended at the end instead of inserted in the desired position.
  - Why it is wrong: Without sequence numbers, new rules are added at the end, which may not be the intended place. This can render your ACL ineffective.
  - Fix: Always specify a sequence number when adding a rule to a Named ACL. Use numbers like 10, 20, 30 to leave gaps for future insertions. For example, 'ip access-list extended MY_ACL 5 permit tcp ...' inserts the rule as rule number 5.
- **Mistake:** Applying a standard Named ACL (which only checks source IP) when an extended ACL is needed to filter by destination or port.
  - Why it is wrong: Standard ACLs cannot differentiate between traffic going to different destinations or ports. For example, you cannot allow web traffic but block FTP using a standard ACL.
  - Fix: Use an extended Named ACL (using the 'ip access-list extended' command) when you need to filter by source/destination IP, protocol, and port. Use standard ACLs only for simple source-based filtering, such as limiting access to a device itself.

## Exam trap

{"trap":"The question states: 'An administrator configures a Named ACL called BLOCK_ALL that has only one rule: deny ip any any. The ACL is applied outbound on the WAN interface. A user wants to access the internet, but cannot. Why?' The expected answer is often 'The ACL denies all traffic leaving the interface.' But the trap is about direction: if the user is inside and the ACL is applied outbound, the user's traffic is blocked as it exits. However, some exam versions might make it inbound on the outside interface to trick you.","why_learners_choose_it":"Learners often think that the implicit deny is at the end, so since there is no permit rule, everything is blocked. They forget to consider that the ACL might be applied inbound on the external interface, which would block incoming traffic, but users inside would still be able to go out if return traffic is not filtered. The trap is the direction and placement of the ACL.","how_to_avoid_it":"Always check the interface and direction the ACL is applied to. Draw the traffic flow: a user inside sends a packet to the internet. If the ACL is outbound on the internal interface, the packet hits the ACL when leaving. If the ACL is inbound on the external interface, it only filters packets entering the network from the internet. Also, remember that ACLs do not affect traffic originating from the router itself unless explicitly configured with 'ip access-group' on the interface. Read the question carefully for interface and direction details."}

## Commonly confused with

- **Named ACL vs Standard ACL:** A standard ACL filters traffic based only on the source IP address, while a Named ACL can be either standard or extended. Extended Named ACLs filter on source and destination IPs, protocol, and port. Standard ACLs use a number (1-99 or 1300-1999) or a name, but they lack the filtering capability of extended ACLs. (Example: A standard Named ACL called "DENY_SALES" can block all traffic from the Sales subnet, but it cannot allow only web traffic from Sales to a specific server. An extended Named ACL can do that.)
- **Named ACL vs Reflexive ACL:** A reflexive ACL is a type of dynamic ACL that allows only return traffic that matches an outbound connection. It is often used for session filtering. Named ACLs are static; they do not automatically open ports for return traffic. Reflexive ACLs are a subclass of Named ACLs in Cisco, but they operate temporarily. (Example: A Named ACL named "OUTBOUND" permits outbound web traffic. A reflexive ACL named "TEMP_IN" automatically creates a temporary rule to allow the return web traffic back in. A regular Named ACL would require you to manually add a permit rule for return traffic.)
- **Named ACL vs Security Group (AWS):** AWS Security Groups are stateful, meaning they automatically allow return traffic for allowed outbound connections. Named ACLs on routers are stateless and require explicit permit rules for return traffic. Also, Security Groups support only allow rules (no deny), while Named ACLs support both permit and deny. (Example: If you allow outbound HTTP traffic in a Security Group, the inbound HTTP response is automatically allowed. With a Named ACL on a router, you must add a separate rule to allow inbound HTTP response traffic.)
- **Named ACL vs Network ACL (AWS VPC):** AWS Network ACLs are stateless, support numbered rules (like 100, 200), and have both allow and deny statements. They are very similar to Named ACLs but are managed through the AWS console. The key difference is that AWS Network ACLs apply to subnets, not interfaces, and they have a separate rule for inbound and outbound. (Example: You create a Network ACL called "WEB_TIER" with rule 100 to allow inbound HTTP from 0.0.0.0/0. This is analogous to a Named ACL applied inbound on a router interface. But with a Network ACL, you must also add an outbound rule to allow return traffic, just like a stateless Named ACL.)

## Step-by-step breakdown

1. **Identify the filtering requirements** — Before creating a Named ACL, you must determine what traffic you want to permit or deny. Identify the source and destination IP addresses, the protocol (TCP, UDP, ICMP, etc.), and the port numbers (e.g., 80 for HTTP, 443 for HTTPS). Also, decide whether the ACL will be applied to inbound or outbound traffic on a specific interface. This step is critical because an incorrect requirement leads to a flawed ACL.
2. **Choose a descriptive name for the ACL** — Select a name that clearly indicates the purpose of the ACL. For example, "BLOCK_TELNET_TO_CORE" or "ALLOW_HR_ONLY." The name can contain letters, numbers, and hyphens but cannot start with a number. A good name improves readability and makes management easier, especially when multiple ACLs are deployed.
3. **Enter global configuration mode on the device** — On a Cisco router or switch, you must access privileged EXEC mode and then global configuration mode. This is done using the commands 'enable' (to enter privileged mode) and 'configure terminal' (to enter global configuration mode). All ACL configuration commands are issued from this mode.
4. **Create the Named ACL using the 'ip access-list extended [name]' command** — Use the command 'ip access-list extended [name]' (for extended filtering) or 'ip access-list standard [name]' (for source-only filtering). This enters the ACL configuration mode for that specific name. From here, you can add rules. In this mode, the prompt changes to include the ACL name, like 'Router(config-ext-nacl)#'.
5. **Add rules with sequence numbers in order from most specific to least specific** — Each rule is entered with a sequence number and the action (permit or deny), followed by the protocol (tcp, udp, icmp, ip), source, destination, and optional port. For example: '10 permit tcp 192.168.10.0 0.0.0.255 host 10.0.0.1 eq 80'. Sequence numbers (like 10, 20, 30) allow you to insert new rules between existing ones later. Always start with specific denies, then permits, and finally a general deny or permit if needed.
6. **Apply the ACL to the desired interface using the 'ip access-group [name] [in|out]' command** — After the ACL is defined, it must be applied to an interface to take effect. Enter interface configuration mode (e.g., 'interface gigabitethernet0/1') and use the command 'ip access-group [name] [in|out]'. The 'in' keyword filters traffic entering the interface; 'out' filters traffic leaving the interface. Only one ACL per direction per interface can be applied.
7. **Verify the ACL configuration using 'show access-lists [name]'** — After applying the ACL, you must verify that it is correctly configured and is being hit. Use 'show access-lists [name]' to see the rules and the match count (number of packets matched). This helps confirm that the ACL is filtering traffic as intended. You can also use 'show ip interface [interface]' to check which ACL is applied in each direction.

## Practical mini-lesson

In practice, configuring Named ACLs requires careful planning. Start by mapping out your network and identifying which resources need protection. For instance, in a typical enterprise, you might have a server farm with a database server that should only be accessed by the application servers on a specific port. You would create an extended Named ACL named "DB_ACCESS_ONLY" with one rule: 'permit tcp host 10.0.1.10 host 10.0.2.20 eq 1433' (for SQL Server). Then, you apply this ACL inbound on the interface facing the database server. This ensures that only the app server can talk to the database-all other traffic is denied. 

When editing an existing Named ACL, always specify the sequence number. For example, if you need to add a new rule to block traffic from a rouge IP at the beginning of the ACL, you can use a low sequence number like 5. If you omit the sequence number, the rule will be appended at the end, which may not produce the desired effect. Also, be aware that if you delete a Named ACL while it is still applied to an interface, traffic will be blocked until you either remove the ACL from the interface or reapply a new ACL. The safe approach is to remove the ACL from the interface before making major changes. 

Another practical tip is to use remark statements to document each rule. For example: 'remark Allow web traffic from internal users to external' before a permit rule. This helps other administrators understand the purpose of each rule. Remarks do not affect traffic processing. Finally, always test the ACL in a lab or during a maintenance window. A single misordered rule can bring down entire departments. Many troubleshooting calls are caused by ACL misconfigurations. By understanding the order of operations, the implicit deny, and the importance of matching traffic flow, you can avoid these issues. Practicing on simulators like Cisco Packet Tracer or GNS3 is highly recommended for building confidence before the exam.

## Commands

```
ip access-list extended BLOCK_SOCIAL_MEDIA
 deny tcp any any eq 443
 deny tcp any any eq 80
 permit ip any any
```
Creates a named extended ACL that blocks all HTTPS and HTTP traffic (commonly used to restrict social media), then permits everything else. Applied on an outbound interface.

*Exam note: Tests understanding that the order matters-permitting IP any any at the end is necessary to allow non-web traffic. Often seen in Network+ and Security+ as a way to selectively block applications.*

```
ip access-list standard ALLOW_MGMT
 permit host 192.168.1.100
 permit host 10.0.0.5
```
Creates a standard named ACL that permits only two management hosts. It is applied to the VTY lines to restrict SSH/telnet access to the router.

*Exam note: Standard ACLs (both numbered and named) can only filter based on source IP. This is a classic CCNA and AZ-104 scenario for restricting administrative access.*

```
ip access-list extended RESTRICT_DB
 deny tcp 10.10.0.0 0.0.255.255 any eq 3306
 permit ip any any
```
Denies MySQL (port 3306) traffic from a specific internal subnet while permitting all other traffic. The named ACL helps identify its purpose.

*Exam note: Tests application of port numbers (3306) and wildcard masks. Common in Security+ and CCNA for database protection scenarios.*

```
interface gigabitEthernet 0/0
 ip access-group OUTBOUND_RULES out
```
Applies the named ACL called OUTBOUND_RULES to the outbound direction of GigabitEthernet 0/0. Traffic is filtered after routing.

*Exam note: Directional application is frequently tested. Example: 'Where would you apply an ACL to block internal users from accessing a public server?' The answer is often outbound on the inside interface.*

```
ip access-list extended MONITOR
 permit icmp any any echo
 permit icmp any any echo-reply
 deny ip any any log
```
Creates a named ACL that permits ping requests and replies but logs all denied traffic. Useful for troubleshooting and intrusion detection.

*Exam note: The 'log' keyword is a security feature tested in Security+ and CCNA. It generates syslog messages for matched denies, which aids in identifying attacks.*

```
ip access-list extended GUEST_SECURITY
 remark Only allow web and DNS for guests
 permit tcp any any eq 80
 permit tcp any any eq 443
 permit udp any any eq 53
 deny ip any any
```
Uses remarks to document the ACL purpose, permits web and DNS, then explicitly denies everything else. The implicit deny is overridden by an explicit deny for logging purposes.

*Exam note: Remarks are an important configuration documentation tool tested in CCNA. Understanding that the explicit deny does not change behavior but allows logging is key.*

```
ip access-list resequence ALLOW_WEB 1 5
```
Resequences the named ACL 'ALLOW_WEB' so that the first entry starts at sequence number 1 and each subsequent entry increments by 5. This makes room for inserting new rules.

*Exam note: Resequencing is a powerful feature for named ACLs. Exam questions may ask how to prepare an ACL for a new rule-resequencing is the correct step.*

```
show ip access-list EXTERNAL_INTERFACE_ACL
```
Displays the entire named ACL with sequence numbers, including how many packets have matched each entry. Useful for real-time verification and troubleshooting.

*Exam note: The 'show ip access-list' command is widely used in CCNA and Network+ to verify ACL hits. Understanding packet counts helps identify rules that are not being triggered.*

## Troubleshooting clues

- **Unintentional traffic being blocked by named ACL** — symptom: Users cannot reach a specific server or service, but no error appears in the logs.. The named ACL likely has an implicit deny at the end that blocks non-permitted traffic. Possibly a permit statement for the needed service is missing or incorrect. (Exam clue: Exam questions present a scenario where a newly applied ACL blocks legitimate traffic, and the solution is to add a permit statement before the implicit deny.)
- **ACL not filtering as expected despite being applied** — symptom: Denied traffic still passes through the interface, or permitted traffic is blocked.. Common causes: ACL applied to the wrong direction (in vs out), wrong interface, or the ACL name is misspelled in the 'ip access-group' command. Also check if the ACL has conflicting rules. (Exam clue: Questions about directional filtering are common-for instance, an inbound ACL on a WAN interface blocking internal traffic that is actually sourced from inside.)
- **Cannot add a new rule to existing named ACL without breaking connections** — symptom: Adding a rule at the end of the ACL causes unintended traffic to be blocked.. The ACL is processed top-down. Adding a new rule at the end may not block traffic because a previous permit statement might already match that traffic. The new rule should be inserted with an appropriate sequence number before the existing permit. (Exam clue: Exam scenario: engineer adds a deny statement to a named ACL but traffic is still permitted. The fix is to place the deny rule at the correct sequence position.)
- **Incorrect wildcard mask causing over-blocking or over-permitting** — symptom: ACL blocks more hosts or fewer hosts than intended.. Wildcard masks are bitwise inverted subnet masks. Misuse of wildcard mask (e.g., using 255.255.255.0 instead of 0.0.0.255) leads to incorrect host matching. For a /24 subnet, the wildcard should be 0.0.0.255. (Exam clue: Exam questions often give a scenario with a misconfigured wildcard mask and ask to identify the correct mask to achieve the desired filtering.)
- **ACL counters show no matches but traffic should match** — symptom: 'show ip access-list' shows zero hits for a rule that should be matching packets.. Possible reasons: the ACL is not applied to the correct interface or direction, the traffic is being intercepted by a preceding rule (order issue), or the traffic is using a different protocol/port than expected. (Exam clue: This is a classic exam troubleshooting scenario-identify that the ACL may have a rule with 'permit ip any any' before the rule supposed to block traffic.)
- **Named ACL editing does not work as expected in older IOS versions** — symptom: Cannot delete or insert individual rules using sequence numbers; router prompts for full deletion.. Older IOS versions (e.g., 12.2 and earlier) may not support per-rule editing of named ACLs. The feature was introduced in later IOS versions. Devices with older code require the traditional delete-and-recreate approach. (Exam clue: Exam questions can test the historical limitation: 'When would you have to delete the entire ACL to modify an entry?' Answer: On devices running older IOS that lack sequence editing.)
- **ACL blocks VTY access even though it's not applied to an interface** — symptom: Users cannot SSH or telnet to the router's management IP after ACL creation.. The ACL might be applied directly under the VTY lines using 'access-class <acl-name> in'. If the ACL does not permit the management hosts, access is blocked. Verify with 'show run | section line vty'. (Exam clue: A common CCNA question: 'What command restricts remote access to a router based on source IP?' Answer: 'access-class' applied to VTY lines.)

## Memory tip

Remember 'N-A-C-L' as 'Name And Sequence, Clear Logic', use descriptive Names and Sequence numbers to keep ACLs organized, and always follow Clear Logic by placing specific rules before general ones.

## FAQ

**What is the difference between a Named ACL and a numbered ACL?**

A Named ACL uses a descriptive name instead of a number, making it easier to identify. Numbered ACLs have fixed ranges (e.g., 1-99 for standard, 100-199 for extended). With Named ACLs, you can insert and delete individual rules using sequence numbers, whereas numbered ACLs require you to remove and recreate the entire list to change rule order.

**Can I apply a Named ACL to both inbound and outbound traffic on the same interface?**

Yes, you can apply one Named ACL for inbound traffic and a different Named ACL for outbound traffic on the same interface. The command is 'ip access-group [name] in' and 'ip access-group [name2] out'. They function independently.

**What does the 'implicit deny' mean in a Named ACL?**

The implicit deny is a hidden rule at the end of every ACL that denies all traffic not explicitly permitted. This means if you only have permit rules, traffic that does not match any permit rule is automatically denied. This is a security feature, but it can cause unintended blocks if you forget to include a necessary permit rule.

**How do I edit a Named ACL without removing it?**

You can add a new rule with a specific sequence number using the 'ip access-list extended [name]' command followed by '[sequence-number] permit/deny ...'. To delete a rule, use 'no [sequence-number]'. To edit a rule, delete the old sequence entry and add a new one. This does not disrupt the ACL or require re-application to the interface.

**Do Named ACLs work on Layer 2 switches?**

Yes, but with limitations. Most managed Layer 2 switches support Named ACLs, but they often only filter based on MAC addresses (Layer 2 ACLs) unless the switch supports Layer 3 routing (multilayer switch). On a pure Layer 2 switch, you can apply port ACLs (PACLs) or VLAN ACLs (VACLs) using named ACLs, but for IP filtering, you typically need a Layer 3 device.

**Are Named ACLs used in cloud networking?**

Yes, the concept is directly analogous in cloud platforms. AWS Network ACLs, Azure Network Security Groups, and Google Cloud Firewall Rules are all named collections of rules with sequence numbers. Understanding Named ACLs on routers provides a solid foundation for understanding cloud network security.

**Can I use the same Named ACL on multiple interfaces?**

Yes, you can apply the same Named ACL to multiple interfaces on the same device. However, be cautious because the ACL will filter traffic in the same way on all those interfaces, which may not be appropriate if the traffic patterns differ. It is often better to create separate ACLs for different purposes.

## Summary

A Named ACL is a powerful, flexible tool for controlling network traffic based on a set of ordered rules. Unlike numbered ACLs, Named ACLs use descriptive names, support easy editing with sequence numbers, and can be configured as either standard (source IP only) or extended (source/destination IP, protocol, port). The core concept includes the implicit deny rule, the importance of rule order, and the correct application to interfaces. 

Named ACLs matter in IT because they enable fine-grained security policies that can be maintained efficiently in a production environment. They are the backbone of many security architectures on premises and in the cloud. For certification exams like CCNA, Network+, Security+, AWS SAA, AZ-104, and Google ACE, understanding Named ACLs is essential. You must be able to interpret why traffic is blocked, identify misconfigurations, and choose the correct ACL design for a given scenario. 

The key exam takeaway is: always think about the traffic flow, remember the implicit deny, place more specific rules first, and verify the direction of the ACL. Mastery of Named ACLs will not only help you pass exams but also make you a more competent network and security professional. Practicing with configuration commands and troubleshooting scenarios is the best way to solidify this knowledge.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/named-acl