# Standard ACL

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

## Quick definition

A Standard ACL is a simple firewall rule that decides whether to allow or block data packets based only on where they came from (the source IP address). It does not look at the destination, port, or protocol. These rules are often used to control traffic near the destination network. They are numbered or named and applied to router interfaces.

## Simple meaning

Think of a Standard ACL like a building security guard who only checks IDs at the front door. The guard looks at each person's ID to see which company they work for, and if they are from an allowed company, they can enter. The guard does not care which floor the person wants to go to, what they are carrying, or if they are visiting the cafeteria or the CEO's office. The only thing that matters is the company name on the ID, which is like the source IP address of a network packet.

In computer networking, data travels in small chunks called packets. Each packet has a header that includes the source IP address (where it came from) and a destination IP address (where it is going). A Standard ACL is like a simple bouncer that only reads the source IP address part. It does not check the destination, the type of data (like web traffic or email), or the specific application. That simplicity makes it fast and easy to configure, but it also means it is not very precise.

For example, if you create a Standard ACL that denies traffic from the IP address 192.168.1.10, then any packet that comes from that address will be blocked, no matter if it is trying to reach a web server, a database, or a printer. This is very useful for blocking a specific computer from accessing the whole network, but it is not helpful if you only want to block that computer from accessing a single server while allowing it to do other things.

Standard ACLs are usually placed as close to the destination as possible. Why? Because they only filter by source address. If you place it near the source, you might accidentally block traffic that was supposed to go somewhere else. Imagine the security guard at the entrance of a shopping mall who checks IDs. If he blocks a person because they are from a company that is not allowed in the mall, that person is blocked from every shop. But if you only want to block that person from one specific store, you would put a checker at the store's door, not the mall entrance. In networking, that means applying the Standard ACL to the interface that leads to the destination network, not the source network.

Standard ACLs are one of the earliest and simplest forms of traffic filtering. They are still taught in certification exams because they form the foundation for understanding more complex access lists like Extended ACLs. They help learners grasp the core idea of packet filtering before adding more conditions like ports and protocols. In the real world, you will rarely use a Standard ACL alone for serious security, but you might see them in legacy networks, lab exercises, or as part of larger configurations where simple source filtering is enough.

## Technical definition

A Standard Access Control List (ACL) is a sequential collection of permit and deny statements that are evaluated in order to control IP packet forwarding or filtering on network devices such as routers and Layer 3 switches. The distinguishing characteristic of a Standard ACL is that it filters based solely on the source IP address of the packet. According to Cisco standards, Standard ACLs are defined using numbers from 1 to 99 or 1300 to 1999 (expanded range), or they can be created with a name using the ip access-list standard command.

Each entry in a Standard ACL is an Access Control Entry (ACE). Each ACE contains a permit or deny action, a source IP address, and a wildcard mask. The wildcard mask, often called an inverse mask, determines which bits of the source address must match exactly (0 in the mask) and which bits are ignored (1 in the mask). For example, a wildcard mask of 0.0.0.0 means match all bits, a single host. A wildcard mask of 255.255.255.255 means match nothing, effectively any address. The keyword "any" is equivalent to 0.0.0.0 255.255.255.255, and the keyword "host" is equivalent to a specific address with mask 0.0.0.0.

Standard ACLs are applied to interfaces using the ip access-group command, either inbound or outbound. An inbound ACL filters packets before they are routed by the router. An outbound ACL filters packets after they have been routed but before they exit the interface. A critical rule is that an implicit deny any exists at the end of every ACL. If a packet does not match any explicit permit statement, it is automatically denied. This means you must have at least one permit statement in the ACL if you want any traffic to pass.

The order of entries in a Standard ACL is crucial. The router evaluates the list from top to bottom and stops processing as soon as a match is found. This first-match logic means that more specific statements should be placed before more general statements. If you place a permit any statement at the top, all traffic is permitted and the rest of the list is never checked. Conversely, if you place a deny any statement at the top, all traffic is blocked regardless of later permit statements.

Standard ACLs have several important limitations. Because they only examine the source IP address, they cannot filter based on destination, protocol type (TCP/UDP) or port numbers. This makes them unsuitable for tasks like blocking specific web traffic while allowing email. They are also less granular, meaning they often affect more traffic than intended. Best practice dictates placing Standard ACLs as close to the destination as possible, because applying them near the source could filter traffic that was destined for other networks.

In real IT implementations, Standard ACLs are still used for specific purposes. They can control which networks are advertised in routing protocols like EIGRP using the distribute-list command. They can restrict management access to a router using the access-class command applied to VTY lines. They are frequently used in lab exercises and certification scenarios to teach the basics of ACL logic, sequence, and wildcard masks. However, for most production security filtering, Extended ACLs or Firewall rule sets are preferred due to their additional control over ports and destinations.

For exam objectives, Standard ACLs appear in the Cisco CCNA (200-301), CompTIA Network+, and other vendor-neutral certifications. In the CCNA, candidates must know how to configure numbered and named Standard ACLs, apply them to interfaces, interpret wildcard masks, and troubleshoot common mistakes. In CompTIA Network+, the focus is on understanding the concept, when to use it, and how it differs from Extended ACLs. In cloud certifications like AWS SAA or Azure AZ-104, Standard ACLs are not directly used, but the concept of stateless, simple source-based filtering is analogous to Network ACLs in cloud virtual networks.

## Real-life example

Imagine you are the manager of a private movie theater that has several different screening rooms. You have a list of VIP members who are allowed to enter the theater complex. But you do not care which movie they watch or which room they go to. You hire a ticket checker at the main entrance. The checker only looks at the person's membership card. If the card shows VIP status, the person is allowed in. If not, they are turned away. The checker does not ask about the movie time, the seat number, or whether they have snacks. That single check at the door is enough to control access to the whole building.

Now, think about what happens if you want to allow VIPs to enter the theater but also allow regular guests into only one specific screening room, say Room 3. The ticket checker at the main entrance cannot do that. With only a simple ID check, every person who passes through the door can go anywhere in the theater. If you want to allow some people into Room 3 but not the others, you would need a different check at the door of Room 3 itself. In networking terms, the ticket checker at the main entrance is a Standard ACL, it only sees the source (the guest type) and makes a simple yes/no decision for the entire destination (the whole theater).

This analogy maps directly to Standard ACLs in networking. The VIP membership card is the source IP address. The whole theater is the destination network. The ticket checker is the Standard ACL applied to the router interface that connects to that network. If you place the ACL at the entrance to the whole theater (the destination network), you can block or allow entire groups of users. But if you place it at the source side, you might block people from even entering the lobby, which could prevent them from going to other places they are allowed.

To take it further, suppose the theater has a backstage area that only staff can enter. You could put a second ticket checker at the door to the backstage. That second checker could also use a simple ID check (staff ID). That is another Standard ACL. Each Standard ACL only sees one attribute. If you needed to check both the membership and the specific movie time, you would need a more advanced system, like an Extended ACL. But for many simple tasks, the basic ID check works fine.

In your home, you might have a similar setup. Your front door key lets you into the house, but it does not control which room you can enter. That is a simple access control. The key is your source credential. The house is the destination. A Standard ACL is like that one key that opens the front door but gives you full access to everything inside. It is simple, effective, and easy to manage, but not very refined.

## Why it matters

In practical IT, Standard ACLs matter because they provide a foundational, low-resource method for controlling traffic based on source identity. They are one of the first security tools a network technician learns, and they teach the critical concepts of sequential evaluation, wildcard masks, and the implicit deny rule. Even though many production environments now use stateful firewalls or Extended ACLs, understanding Standard ACLs helps you troubleshoot legacy configurations and grasp the logic behind more complex filtering mechanisms.

Standard ACLs also play a role in controlling routing updates. For example, in Cisco routers, you can use a Standard ACL with the distribute-list command to filter which routes are advertised to a neighbor. This is a common task in routing protocol configuration and appears in certification exams. Without knowing Standard ACL syntax and behavior, you cannot effectively control route advertisement.

Another practical reason is that they are extremely lightweight. They require no CPU-intensive state tracking and no deep packet inspection. For simple tasks like blocking a specific rogue device from accessing a network, a Standard ACL applied inbound on a trunk port is quick and effective. They are also easy to audit, you can see the list of source addresses and immediately understand the filter logic.

Finally, Standard ACLs are a prerequisite for learning many other network security concepts. They introduce the idea of packet filtering, which is the basis for firewalls, Network ACLs in cloud platforms (AWS, Azure, GCP), and even some aspects of software-defined networking. For IT certification learners, mastering Standard ACLs builds confidence and prepares you for more advanced topics like Extended ACLs, named ACLs, and firewall rule sets.

## Why it matters in exams

For the CCNA (200-301) exam, Standard ACLs are a core topic. You need to know how to configure numbered ACLs (1-99) and named Standard ACLs, apply them to interfaces with the ip access-group command, and understand the effect of inbound vs. outbound application. You will also see questions that test your understanding of wildcard masks and the order of ACEs. A typical CCNA question might present a scenario where you need to permit a single host and deny another, and you must choose the correct sequence. The exam also tests troubleshooting: given a misconfigured Standard ACL showing no output or incorrect filtering, you must identify the error.

For CompTIA Network+ (N10-008), Standard ACLs appear in the networking fundamentals section. You are expected to understand the difference between Standard and Extended ACLs, know the typical use case (source-based filtering), and recognize that they are stateless. Questions are usually multiple choice asking which type of ACL filters only by source IP, or where you should place a Standard ACL. The typical answer is "near the destination."

For CompTIA Security+ (SY0-601), ACLs are part of access control mechanisms. You need to know that ACLs are a security control for network devices. Standard ACLs may appear in a question about stateless packet filtering. The exam emphasizes the principle of least privilege and the implicit deny. You might see a question comparing stateless (Standard ACL) vs. stateful inspection.

For AWS SAA (AWS Solutions Architect Associate), Standard ACLs are not directly referenced by name, but the concept of stateless Network ACLs (NACLs) in AWS Virtual Private Cloud (VPC) is very similar. AWS NACLs filter traffic based on source and destination IP, but they are stateless like Standard ACLs. Understanding the behavior of Standard ACLs helps you understand why you must configure both inbound and outbound rules in an AWS NACL. Many exam questions test this difference from security groups (stateful).

For Azure AZ-104 (Azure Administrator), the Azure Network Security Group (NSG) is more analogous to an Extended ACL because it filters by source and destination IP, port, and protocol. However, Azure NSG rules are also evaluated in order (priority) and have an implicit deny. The foundational logic learned from Standard ACLs directly applies. You may see a scenario where you need to allow RDP from a specific IP, that is a source-based filter similar to a Standard ACL, but with port restriction.

For Google ACE (Google Associate Cloud Engineer), VPC firewall rules are similar. They can be source-based or destination-based. Understanding Standard ACL helps you think about whether a rule applies to ingress or egress traffic, which is a key exam concept.

For A+ (CompTIA A+), Standard ACLs are lightly supporting. You might encounter the term in the context of network security or basic router configuration, but it is not a primary objective.

## How it appears in exam questions

In certification exams, Standard ACL questions often fall into a few patterns. The most common is a scenario-based question where you are given a network diagram and a security requirement, and you must choose the correct ACL configuration. For example: "A company wants to allow only the host at 10.0.0.5 to access the 192.168.1.0/24 network. All other traffic should be denied. Which ACL should be applied?" The correct answer would be a Standard ACL with a permit statement for host 10.0.0.5, followed by the implicit deny. You might also need to select the correct wildcard mask, such as host 10.0.0.5 or 10.0.0.5 0.0.0.0.

Another common pattern is placement. Questions will ask where a Standard ACL should be applied. The correct answer is always as close to the destination as possible. For example: "Which interface should the ACL be applied to in order to filter traffic from the 10.1.1.0/24 network to the 192.168.2.0/24 network?" The answer is the interface on Router B that connects to the 192.168.2.0/24 network (the destination router's inbound interface or outbound interface depending on direction).

Troubleshooting questions are also frequent. They may show an ACL configuration and ask why traffic is being blocked or allowed incorrectly. For instance, you might see: "access-list 10 deny 192.168.1.0 0.0.0.255" followed by "access-list 10 permit any" and then a question about why host 192.168.1.10 cannot reach the server. The error might be that the order is correct (deny before permit) but the wildcard mask is wrong. Or the application direction is wrong. These questions test your ability to analyze the logic.

Comparison questions are used in Network+ and Security+. They ask: "Which type of ACL filters only by source IP address?" or "What is a key advantage of an Extended ACL over a Standard ACL?" The answer is that Standard ACLs lack destination and port filtering.

Finally, some questions test the implicit deny. For example: "You have applied a Standard ACL with only one permit statement for host 10.0.0.1. What will happen to traffic from host 10.0.0.2?" The answer is that it will be denied because of the implicit deny any at the end. This concept is repeatedly tested.

## Example scenario

You are a junior network technician at a small company. The company has two networks: the Sales network (192.168.10.0/24) and the Finance network (192.168.20.0/24). The Finance server contains sensitive payroll data. A new policy says that only the manager's computer (IP 192.168.20.100) in the Finance network is allowed to access the Finance server. All other computers in the Finance network must be blocked from the server. But they can still access the internet and other resources.

You decide to use a Standard ACL on the router that connects the Finance network to the rest of the company. You create a Standard ACL with the following entries: first, permit host 192.168.20.100 (the manager's computer). Then, deny any other source from the 192.168.20.0/24 network. But here is the catch: if you place the ACL to filter traffic going to the server, you must apply it to the interface that connects to the server. If the server is on a separate VLAN, you apply the ACL inbound on that VLAN interface. You do not want to block all traffic, only traffic from the Finance network to the server. However, a Standard ACL cannot specify destination, so it will block all traffic from the denied sources, even if they try to go to the internet. This is a problem.

This scenario highlights a limitation of Standard ACLs. In practice, you would need an Extended ACL to permit the manager's traffic to the specific server (destination IP and port) while denying others to that server but allowing them elsewhere. The scenario teaches you why Standard ACLs are often insufficient for granular security and why they must be placed carefully to avoid unintended blocking.

## How Wildcard Masks Define Standard ACL Match Logic

Standard Access Control Lists (ACLs) in Cisco IOS and many other networking platforms rely on wildcard masks rather than subnet masks to determine which source IP addresses are matched. A wildcard mask is a 32-bit value that tells the ACL which bits of the source IP address must be checked exactly and which bits can be ignored. A 0 in the wildcard mask means the corresponding bit must match exactly; a 1 means it is ignored, or “don’t care.” This logic is the opposite of a subnet mask, where 1s represent the network portion and 0s represent the host portion. For example, to match the entire 192.168.1.0/24 network, you would use source address 192.168.1.0 with wildcard mask 0.0.0.255. The zeros in the first three octets tell the ACL to match those bits exactly, while the 255 in the last octet indicates that any host value is acceptable. Understanding wildcard masks is essential for the CCNA and Network+ exams, as misconfigured masks are one of the most common causes of ACL failures. In the exam, you might see questions that ask you to calculate the wildcard mask from a given network prefix, or to identify which IP addresses would be matched by a specific ACL entry. For instance, a wildcard mask of 0.0.0.15 applied to address 192.168.1.16 would match any address in the range 192.168.1.16 through 192.168.1.31, because the last four bits are ignored. This granular control allows administrators to permit or deny traffic from specific subnets or even individual hosts. Standard ACLs only filter based on the source IP address, so the wildcard mask determines the scope of that source. A common trick exam question involves the keyword “host” which is equivalent to a wildcard mask of 0.0.0.0, meaning that every bit must match, so only a single IP address is matched. Conversely, the keyword “any” equates to a wildcard mask of 255.255.255.255, meaning all bits are ignored, so every source address matches. The Security+ exam may also test the concept of implicit deny, which acts as a catch-all rule at the end of every ACL, but the wildcard mask is the mechanism that defines the scope of each explicit entry. When writing standard ACLs, always remember that the wildcard mask is not a subnet mask, and using a subnet mask by mistake will cause the ACL to behave unpredictably. For example, writing access-list 1 permit 10.0.0.0 0.255.255.255 would match any address that begins with 10, which is often correct, but a common error is to use 255.0.0.0 instead, which would require the first octet to be exactly 10 but the rest to match exactly 0.0.0, effectively only allowing host 10.0.0.0. This subtlety is frequently tested in CCNA simulation questions where you must select the correct wildcard mask to allow a specific range of addresses. Mastering wildcard mask notation is the foundation of effective standard ACL deployment and a key skill for any network professional.

## Placement Strategies: Why Source-Based Filtering Demands Edge Proximity

Standard ACLs filter traffic based solely on the source IP address, which introduces a critical design principle: they should be placed as close to the destination as possible. This contrasts with extended ACLs, which can filter on source and destination, and are typically placed close to the source. The reason for this placement strategy is that standard ACLs cannot distinguish between traffic intended for different destinations. If you place a standard ACL near the source router, it might deny traffic that is actually destined for a different, permissible network, simply because the source address matches a deny entry. This could block legitimate traffic unnecessarily. For example, if you want to block traffic from subnet 192.168.1.0/24 from reaching a specific server at 10.0.0.1, but you want that same subnet to still reach the internet, placing the ACL at the ingress of the router closest to 192.168.1.0/24 would block all traffic from that subnet, including internet-bound packets. Instead, you would place the ACL on the interface closest to the server 10.0.0.1, filtering inbound traffic to that interface. This ensures that only traffic actually headed toward that server is evaluated, while other traffic flows unimpeded. In the CCNA and AWS SAA exams, this placement concept is often tested through scenario-based questions, such as: “A network administrator wants to prevent a specific department from accessing a finance server but allow all other access. Which ACL type and placement would achieve this?” The correct answer would be a standard ACL on the interface closest to the finance server, filtering inbound. Another common mistake is applying a standard ACL to an interface in the outbound direction without considering the filtering logic. Outbound ACLs evaluate traffic leaving the interface, so the source IP is still the original source, but the router checks the ACL before forwarding the packet out. For standard ACLs, outbound placement can sometimes be simpler, but the proximity-to-destination rule still applies. Standard ACLs are often numbered 1-99 or 1300-1999 in Cisco devices, and they cannot be modified once configured; you must remove and reapply them. This limitation makes planning even more critical. In the Network+ exam, you might be asked to identify the correct interface and direction for a standard ACL based on a network diagram. The general rule is: for standard ACLs, apply them inbound on the interface closest to the destination network. This minimizes unintended filtering and keeps the network efficient. In cloud environments like AWS, standard ACLs are analogous to network ACLs (NACLs) at the subnet level, but AWS NACLs can filter both source and destination, so they function more like extended ACLs. However, the same principle of placing filtering rules near the boundary of the resource you want to protect applies. Finally, remember that every ACL has an implicit deny at the end, so if no explicit permit matches, the traffic is dropped. This means that a misplaced standard ACL might silently drop traffic that the administrator expected to pass, leading to difficult troubleshooting scenarios. By following the placement principles, you reduce the risk of such issues and ensure that your security policies are both effective and minimal in their impact on legitimate traffic.

## The Implicit Deny and Sequence Number Mechanics in Standard ACLs

Every standard ACL, whether on a Cisco router, a Linux iptables firewall, or a cloud network ACL, ends with an implicit deny statement. This means that if a packet does not match any of the explicit permit or deny entries in the ACL, it is denied (dropped). This concept is fundamental to network security and is tested heavily in the Security+, CCNA, and Network+ exams. For example, consider a standard ACL with only one entry: access-list 1 permit 192.168.1.0 0.0.0.255. This ACL permits traffic from the 192.168.1.0/24 subnet, but implicitly denies all other traffic. An administrator who expects that traffic from other subnets might still pass is mistaken, unless there is an explicit permit for those subnets. The implicit deny is always added at the end of the ACL, so any traffic that does not match earlier rules is dropped. In Cisco IOS, standard ACLs can be configured either as numbered (1-99, 1300-1999) or named. Named standard ACLs allow for the use of sequence numbers to insert, delete, or reorder entries, whereas traditional numbered ACLs do not support sequence numbers and must be removed and reapplied if changes are needed. This is a crucial difference. In the CCNA exam, you might be asked to explain how to edit a standard ACL without affecting existing traffic. The answer often involves using a named standard ACL with sequence numbers, where you can add new entries at a specific sequence number. For instance, the command ip access-list standard BLOCK_DEPT followed by permit 192.168.1.0 0.0.0.255 and then deny 10.0.0.0 0.0.0.255 (with sequence numbers) allows the administrator to reorder entries by specifying sequence numbers. The default sequence numbers increment by 10, so the first entry is 10, the next 20, etc. If you need to insert a rule between them, you can use a sequence number like 15. This granular control is a boon for production networks where ACL changes must be minimal. Another important detail is that the order of entries matters. ACLs are processed top-down, and the first match determines the action. If you have a deny statement for a broad range followed by a permit for a specific host within that range, the specific host will be denied because the first match (deny) wins. This is a classic exam trick question: “Which traffic is permitted by ACL 10?” with conflicting entries. The answer requires you to trace the order of the rules. In the Security+ exam, the implicit deny principle is part of the broader topic of least privilege and default-deny security models. Understanding that an ACL is essentially a list of exceptions to a default-deny policy helps architects design more secure networks. In practice, a well-designed standard ACL will have explicit permit statements for allowed traffic and then rely on the implicit deny to block everything else. However, it is common to add an explicit deny any statement at the end of the ACL for documentation purposes, even though it is technically redundant. Some older IOS versions also supported an explicit deny as the last line, but modern best practice is to let the implicit deny handle it. Finally, note that the implicit deny only applies to the ACL itself, not to the entire router. If no ACL is applied to an interface, all traffic is permitted by default. It is only when an ACL is applied that the implicit deny rule is enforced. This distinction is often blurred in exam questions, so be vigilant. The sequence number feature for named standard ACLs also allows for better auditing and troubleshooting, as you can see the exact order of rules and easily identify which rule is matching a particular flow. Overall, mastering both the implicit deny concept and sequence number mechanics will help you deploy standard ACLs that are both secure and maintainable.

## Applying Standard ACLs to Router Interfaces: Inbound vs. Outbound and Directional Considerations

In Cisco networking, a standard ACL becomes active only when it is applied to a router interface in a specific direction: inbound or outbound. The direction is specified relative to the router. Inbound ACLs process packets as they enter the interface, before the routing decision is made. Outbound ACLs process packets after the routing decision, as they are about to leave the interface. For standard ACLs, the choice of direction has significant implications for performance and security policy. Because standard ACLs filter only on source IP, applying an inbound standard ACL on an interface means that you are filtering traffic as soon as it arrives. This can reduce unnecessary processing because if the traffic is denied, the router does not need to route it. However, the placement challenge remains: if you apply it inbound on an interface far from the destination, you might block traffic unnecessarily. The recommended practice for standard ACLs is to apply them outbound on the interface closest to the destination, because you want to filter based on source only when the traffic is about to reach its intended network. For example, consider a router with three networks: 192.168.1.0/24 (source), 10.0.0.0/24 (server), and 172.16.0.0/24 (internet). You want to block 192.168.1.0/24 from reaching 10.0.0.0/24 but allow all other traffic. The best approach is to create a standard ACL that permits any (or denies only the specific source) and apply it outbound on the interface facing the server network (10.0.0.0/24). That way, when traffic from 192.168.1.0/24 is routed toward the server, it is filtered at the last hop. If you applied it inbound on the network that contains 192.168.1.0, you would block all traffic from that subnet everywhere, which is not the intention. In the CCNA exam, you may be given a network diagram and asked to choose the correct interface and direction for a given ACL. The correct answer often involves applying the standard ACL outbound on the destination router’s interface. Another important nuance is that ACLs can be applied to both physical interfaces and subinterfaces (for VLANs). On a router-on-a-stick configuration, you might apply a standard ACL outbound on the subinterface that corresponds to the destination VLAN. In the AWS SAA exam, while you don’t configure Cisco routers, the concept of direction applies to security groups and network ACLs. A security group is stateful and can filter inbound and outbound traffic, while a network ACL is stateless and requires explicit rules for both directions. In practice, many cloud architects forget that NACLs are stateless, which can cause connectivity issues similar to outbound ACL misconfigurations. For example, if you apply a standard-like rule in a NACL that allows inbound HTTP traffic but does not allow outbound return traffic, the connection fails. This tests your understanding of state vs. stateless filtering. In the Network+ and Security+ exams, you might be asked to explain how direction affects ACL processing. A common troubleshooting scenario is when a user can initiate a connection to a server but the server cannot send a response back; the problem often lies in the outbound ACL on the server’s interface blocking return traffic. For standard ACLs, since they only look at source, you must ensure that the source IP of the return traffic (the server) is permitted by the outbound ACL on the server’s interface. But because standard ACLs only filter on source, this can be tricky. That is why extended ACLs are usually preferred for such scenarios. However, the exam may still present standard ACL scenarios to test your understanding of direction and source-based filtering. Always verify the direction of the ACL applied to an interface. A misdirected ACL either fails to protect the intended resources or blocks legitimate traffic. Best practices dictate that standard ACLs be applied outbound on the interface closest to the destination network, and that you document the ACL’s purpose and direction clearly to avoid configuration errors.

## Common mistakes

- **Mistake:** Placing a Standard ACL near the source instead of the destination.
  - Why it is wrong: A Standard ACL filters only by source IP. If placed near the source, it will block traffic from that source to all destinations, not just the intended one. This can accidentally block legitimate traffic to other networks.
  - Fix: Apply the Standard ACL as close to the destination as possible, usually inbound on the destination router's interface facing the destination network.
- **Mistake:** Forgetting the implicit deny at the end of the ACL.
  - Why it is wrong: If you create an ACL with only a permit statement, traffic that does not match that permit will be dropped by the implicit deny. Many beginners think that unmatched traffic is permitted by default.
  - Fix: Always include a permit any statement at the end if you want to allow all other traffic, or be aware that the implicit deny will block everything else. Remember: there is an invisible 'deny any' at the end.
- **Mistake:** Using the wrong wildcard mask, especially confusing it with a subnet mask.
  - Why it is wrong: A wildcard mask uses 0 to mean 'match this bit' and 1 to mean 'ignore this bit'. A subnet mask does the opposite. Using a subnet mask like 255.255.255.0 instead of 0.0.0.255 will produce incorrect filtering.
  - Fix: Remember the rule: in a wildcard mask, 0 is 'must match', 1 is 'don't care'. For a /24 network, the wildcard mask is 0.0.0.255. You can also use the keyword 'host' for a single IP (mask 0.0.0.0) and 'any' for all IPs (mask 255.255.255.255).
- **Mistake:** Applying the ACL to the wrong interface or direction (inbound vs outbound).
  - Why it is wrong: If you apply an inbound ACL on an interface that does not receive the traffic you want to filter, the ACL will never be evaluated. Similarly, applying it outbound on the wrong interface may filter traffic that has already passed through the router towards the wrong network.
  - Fix: Trace the traffic flow. For a Standard ACL filtering source-based traffic, apply it inbound on the interface where the source traffic enters the router, or outbound on the interface where the traffic exits toward the destination. Verify with 'show access-list' and 'show running-config'.
- **Mistake:** Putting a 'permit any' before a more specific deny statement.
  - Why it is wrong: Because ACLs are evaluated sequentially from top to bottom, a 'permit any' at the top will match all packets before the deny statement is reached, making the deny useless.
  - Fix: Always place the most specific entries first. List deny statements before broad permit statements. The order matters: first match wins.
- **Mistake:** Using a Standard ACL when an Extended ACL is needed for the task.
  - Why it is wrong: If you need to filter by destination IP or port, a Standard ACL cannot do it. Trying to force a Standard ACL will result in either over-blocking or under-blocking traffic.
  - Fix: Identify the filtering criteria. If you need to filter by source and destination and/or port, use an Extended ACL (numbered 100-199 or named). Reserve Standard ACLs for simple source-based filtering.
- **Mistake:** Not removing or editing an existing ACL correctly, causing accidental traffic blocking.
  - Why it is wrong: Cisco IOS ACLs are edited by sequence number. If you try to remove an entry and add a new one, you might create a gap or unintentionally allow or block traffic. Sequence numbers can get confused.
  - Fix: Use 'ip access-list standard' to enter ACL configuration mode and then use sequence numbers (default increments by 10). To delete a single entry, use 'no sequence-number'. To replace the entire ACL, remove it with 'no access-list number' and reconfigure.

## Exam trap

{"trap":"When a question asks to allow traffic from a specific host to a specific server, and the answer options include both a Standard ACL and an Extended ACL, many learners choose the Standard ACL because it is simpler. But the Standard ACL will allow that host to reach all destinations, not just the server, which might violate security requirements. The exam trap is that the Standard ACL appears to work at first glance but is not precise enough.","why_learners_choose_it":"Learners are often instructed that Standard ACLs are for source-based filtering, and they see the source IP address requirement. They think 'Standard' means 'easier' and they default to it. They may not fully analyze that the destination restriction is also necessary.","how_to_avoid_it":"Read the scenario carefully. If the requirement says 'allow only this host to reach the specific server', you need an Extended ACL because it can also specify the destination. If the requirement says 'allow this host to access the network', a Standard ACL might be sufficient. Always ask: 'Does the rule need to be destination-specific?' If yes, use Extended."}

## Commonly confused with

- **Standard ACL vs Extended ACL:** An Extended ACL filters traffic based on source IP, destination IP, protocol (TCP/UDP), and port numbers. A Standard ACL filters only by source IP. Extended ACLs are more granular and are placed closer to the source, while Standard ACLs are placed close to the destination. (Example: Extended ACL can block a specific computer from accessing only a web server on port 80. Standard ACL can only block that computer from everything.)
- **Standard ACL vs Named ACL:** Named ACL can be either Standard or Extended, but it uses a name instead of a number to identify the ACL. Named ACLs allow for more descriptive identification and easy editing with sequence numbers. Standard ACLs can be numbered or named, but the term 'Standard ACL' refers to the type, not the naming method. (Example: A Standard ACL numbered 10 is the same function as a Standard ACL named 'BLOCK_SALES'. Both filter by source IP only.)
- **Standard ACL vs Reflexive ACL:** A Reflexive ACL is a type of ACL that creates temporary permit statements based on outbound traffic, allowing return traffic. It is stateful in a basic way. A Standard ACL is stateless, it treats each packet independently without considering whether it is a response to a previous connection. (Example: Reflexive ACL: Allow web request out, automatically allow reply in. Standard ACL: If you permit out, you must also manually permit replies in if needed.)
- **Standard ACL vs Network ACL (NACL) in AWS:** AWS NACL is analogous to a stateless firewall that filters traffic at the subnet level. It can filter both inbound and outbound traffic and supports rules based on IP address, protocol, and port range. However, AWS NACL rules are evaluated by rule number (priority), similar to extended ACL order, not by source IP only. A Standard ACL is more limited, while an AWS NACL is more like an Extended ACL. (Example: AWS NACL can allow SSH (port 22) from a specific IP. Standard ACL cannot specify port, so it would allow all traffic from that IP.)
- **Standard ACL vs IP Access-Group:** IP access-group is not a type of ACL, but the command used to apply an ACL to a router interface. Learners often confuse the application command with the ACL itself. The Standard ACL is the list of rules; the access-group is how you attach it. (Example: You create Standard ACL 10, then use 'ip access-group 10 in' on an interface. The ACL is the filter, the access-group is the placement.)

## Step-by-step breakdown

1. **Determine the Traffic to Filter** — Identify the source IP address or range that you want to permit or deny. Since Standard ACLs only check the source, you must be clear about which devices or networks are being filtered. For example, you might want to block all traffic from the 10.0.0.0/24 subnet.
2. **Choose a Number or Name for the ACL** — For numbered Standard ACLs, use a number between 1 and 99 (or 1300-1999 for expanded range). For named ACLs, use a descriptive name like 'MANAGEMENT_ONLY'. Named ACLs allow editing with sequence numbers, which is easier.
3. **Create the ACL with Permit or Deny Statements** — Enter global configuration mode and use the command 'access-list <number> permit|deny <source> [wildcard]' for numbered ACLs, or 'ip access-list standard <name>' for named ACLs. Add the first line. Remember that order matters: the first matching entry is used. For example: 'access-list 10 deny 192.168.1.0 0.0.0.255' blocks the entire subnet.
4. **Add Subsequent Statements in the Correct Order** — Add any additional permit or deny statements. More specific entries should come before more general ones. Use sequence numbers to insert or delete statements in named ACLs. For numbered ACLs, you cannot insert, you must delete and recreate the entire list if you need to change order.
5. **Verify the ACL Configuration** — Use 'show access-list' to display the ACL and see the number of matches for each entry. This helps confirm that the logic is correct. Check for any missing entries or incorrect wildcard masks. Also check that the implicit deny appears (it may not be shown but it is always there).
6. **Apply the ACL to an Interface** — Enter interface configuration mode for the desired interface. Use 'ip access-group <number|name> in|out' to apply the ACL. 'in' filters packets arriving on that interface; 'out' filters packets leaving that interface. For Standard ACLs, the best practice is to apply 'in' on the interface closest to the destination network.
7. **Test and Troubleshoot** — Generate test traffic from the source devices and verify whether the ACL is behaving as expected. Use 'ping' or 'traceroute' from a permitted host and from a denied host. Use 'show access-list' to see the 'matches' counter increase. If traffic is being unexpectedly blocked, check the direction, the wildcard mask, and the order of the entries.
8. **Document and Maintain** — Record the purpose of the ACL in your network documentation. Use descriptive names and include comments in named ACLs (using the remark command). Periodically review the ACL to remove unused or outdated entries.

## Practical mini-lesson

In a real-world production network, you will rarely use a raw Standard ACL as a primary security control. However, understanding how to configure and troubleshoot one is still essential for several reasons. First, many older network devices still use them. Second, they appear in certification labs and exams. Third, they teach the fundamental logic that applies to all access control mechanisms.

Let us walk through a realistic configuration task. Imagine you are managing a Cisco router that connects a branch office to the main office. The branch office has a subnet 172.16.1.0/24. Corporate policy states that only the VLAN for the finance department (172.16.1.64/26) is allowed to access the main office VPN server at 10.10.10.5. Other VLANs in the branch should not be able to reach that server. But wait, a Standard ACL cannot filter by destination IP, so you cannot achieve this with a Standard ACL alone. This is a common scenario where professionals realize they need an Extended ACL instead. This lesson: identify the limitations early.

Now consider a different scenario: You want to block a specific rogue device with MAC address x on the branch network from accessing any corporate resource. You could use a Standard ACL that denies the IP address of that device. Since the ACL is applied inbound on the branch router's WAN interface, all traffic from that device will be blocked. This is a valid use case for a Standard ACL because you are only interested in the source. You would configure: 'access-list 10 deny host 172.16.1.100' followed by 'access-list 10 permit any' to allow everyone else. Then apply 'ip access-group 10 out' on the WAN interface (or 'in' on the LAN interface, depending on traffic flow).

A common troubleshooting scenario: a user complains they cannot reach the internet. You check the router. There is a Standard ACL applied inbound on the LAN interface. The ACL has only one statement: 'permit host 192.168.1.10'. You realize that the implicit deny is blocking all other hosts. The fix is to add 'permit any' as the last line, or change the ACL to 'permit 192.168.1.0 0.0.0.255' if you want to allow the whole subnet.

Professionals also use Standard ACLs to filter routing updates. For example, in EIGRP, you might want to advertise only a specific network to a neighbor. You create a Standard ACL that permits that network's source, and then use the 'distribute-list' command under the routing process. This is a specialized but important use case.

What can go wrong? Beyond the common mistakes, one subtle issue is that Standard ACLs do not track connection state. If you deny inbound traffic but permit outbound, reply packets will be dropped unless you also permit them. This can lead to asymmetric traffic problems. Another issue is performance: while ACLs are fast, too many ACEs or extremely large wildcard masks can slow down the router's CPU. Always keep ACLs as simple as possible.

the practical mini-lesson is: know what Standard ACLs can and cannot do. Use them for simple source blocking or route filtering. For any filtering that needs destination, port, or protocol awareness, use Extended ACLs or a firewall. Always test your ACL before and after deployment.

## Commands

```
access-list 1 permit 192.168.1.0 0.0.0.255
```
Creates a standard numbered ACL (list 1) that permits all traffic originating from the 192.168.1.0/24 network.

*Exam note: Exams test understanding of wildcard mask format; 0.0.0.255 matches exactly the first 24 bits. A common error is to use 255.255.255.0 as a mask.*

```
ip access-list standard BLOCK_DEPT
```
Enters named standard ACL configuration mode for an ACL called BLOCK_DEPT. Subsequent permit or deny statements are added.

*Exam note: Named ACLs support sequence numbers and are preferred for manageability. CCNA questions often ask about sequence number modification.*

```
deny 10.0.0.0 0.255.255.255
```
Under the named ACL configuration, this denies all traffic sourced from the 10.0.0.0/8 network.

*Exam note: A wildcard mask of 0.255.255.255 matches any address starting with 10. Be careful: 10.0.0.0 is not a single host but a whole class A network.*

```
interface gigabitethernet0/1
ip access-group 1 out
```
Applies ACL number 1 to interface gigabitethernet0/1 in the outbound direction, filtering traffic as it leaves the interface.

*Exam note: The direction keyword (in or out) is critical. Standard ACLs are typically applied outbound near the destination in exam scenarios.*

```
ip access-list standard RESTRICT_LAN
sequence 10 permit 172.16.0.0 0.0.255.255
sequence 20 deny any
```
Creates a named standard ACL with explicit sequence numbers; permits 172.16.0.0/16 and then explicitly denies all else.

*Exam note: Sequence numbers allow insertion of new rules between existing ones. The explicit deny is redundant due to implicit deny, but tests understanding of processing order.*

```
no access-list 1
```
Deletes the entire standard ACL number 1. To modify a numbered ACL, you must remove and recreate it.

*Exam note: This is a limitation of numbered ACLs. Named ACLs can be edited without removing them, which exam questions often contrast.*

```
show access-list 1
```
Displays the contents of ACL 1 along with packet match counts for each entry.

*Exam note: Used in troubleshooting to verify if traffic is matching the ACL rules. The hit count is a valuable diagnostic tool tested in CCNA and Network+.*

## Troubleshooting clues

- **ACL applied to wrong interface** — symptom: Traffic from a permitted source reaches the network but is unexpectedly dropped on a different path.. Standard ACLs filter based on source IP, and if applied to an interface not in the path to the destination, they either drop traffic that should pass or allow unwanted traffic. The ACL must be placed on the interface closest to the destination. (Exam clue: Exam scenarios often present a diagram with multiple routers and ask which interface should have the ACL applied. The correct answer is the one closest to the destination network.)
- **Incorrect wildcard mask** — symptom: Either too many or too few hosts are permitted/denied. For example, a host outside the intended range is allowed or a host inside the range is blocked.. The wildcard mask defines which bits are checked. Using 0.0.0.0 for a single host or 0.0.0.255 for a /24 is correct, but using a subnet mask like 255.255.255.0 will cause unexpected matches because the ACL interprets 255 as 'ignore' in wildcard logic. (Exam clue: The exam may give a wildcard mask like 0.0.0.15 and ask which addresses match. The answer is a block of 16 contiguous addresses starting at the network address (with the base aligned to that block size).)
- **Order of ACL entries reversed** — symptom: A specific host is denied even though a permit statement for that host exists, because a broader deny statement appears before it.. Standard ACLs are processed top-down. The first matching entry determines the action. If you deny a range and then permit a specific address within that range, the permit is never evaluated. (Exam clue: Exam questions often list two ACL entries in a specific order and ask which traffic is permitted. You must trace the order to find the first match.)
- **Forgetting to apply the ACL to the interface** — symptom: The ACL is configured but has no effect; all traffic passes.. An ACL is only active after it is applied to an interface using the ip access-group command. Without this, the router ignores the ACL. (Exam clue: This is a common 'trick' in configuration exercises. The ACL exists but is not bound to any interface, so the implicit deny never triggers.)
- **Implicit deny causing connectivity loss** — symptom: Traffic from a source that is not explicitly permitted is blocked, resulting in no connectivity for those users.. After all explicit entries, the ACL has an implicit deny any. If no permit matches, the packet is dropped. This can surprise administrators who expect other traffic to pass. (Exam clue: Exam questions may ask 'What happens to traffic from 10.0.0.1 if ACL 1 only permits 192.168.1.0/24?' The answer is that it is denied due to the implicit deny.)
- **ACL applied to an interface in the wrong direction** — symptom: Traffic that should be filtered is not, or legitimate traffic is dropped when it should not be.. Inbound ACLs filter packets as they enter the interface; outbound filters after routing. If you apply a standard ACL inbound on the source network’s interface, it blocks all traffic from that source, even if destined for non-restricted networks. (Exam clue: A classic troubleshooting question: 'Users from the Sales network cannot reach the Finance server, but they can reach the internet. What is the most likely cause?' The answer is often a misdirected inbound ACL.)
- **Mixing standard and extended ACL forces** — symptom: The router rejects the ACL or applies it with unexpected behavior, such as only filtering source instead of source and destination.. Standard ACLs can only filter on source IP. If you mistakenly include destination information (e.g., 10.0.0.1) in a standard ACL, it will be interpreted as source, leading to wrong matches. (Exam clue: Exams test the distinction: standard ACLs can only use source and wildcard mask. Any additional parameters are ignored or rejected.)

---

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