Access Control List (ACL) Scenarios

Standard ACLs should be placed as close to the source as possible.

Why wrong: Placing a standard ACL close to the source is incorrect because it will evaluate every packet from that source regardless of its final destination, potentially dropping traffic that should be allowed to other networks. Since standard ACLs cannot match the destination address, a permit or deny statement applies globally to all destinations for the specified source. Cisco recommends applying standard ACLs near the destination, while extended ACLs — which can match destination — should indeed be placed close to the source to reduce unnecessary transit traffic.

Standard ACLs can filter traffic based on destination IP address.

Why wrong: Standard ACLs do not look at the destination IP address at all — each ACE contains only a permit/deny decision based on the source address, with an optional wildcard mask. Because the router never inspects the destination field of the packet, a standard ACL cannot differentiate between traffic going to one host and traffic going to another. This is why extended ACLs are required when you need to match both source and destination addresses.

Standard ACLs can filter traffic based on TCP or UDP port numbers.

Why wrong: Standard ACLs cannot filter by TCP or UDP port numbers because they operate only at Layer 3 and match solely on the source IP address and wildcard mask. Port fields are Layer 4 information, which the standard ACL code never examines; only an extended ACL (numbered 100–199 or named) can specify protocol and port numbers in its entries. Thus, any attempt to use a standard ACL to block a specific web service or application port will fail.

The policy needs to match only one source subnet.

Why wrong: If the policy needs to match only a single source subnet, a standard access list using a wildcard mask like 0.0.255.255 fully satisfies that goal. Standard ACLs evaluate only the source address, so one permit or deny statement can identify the subnet without extra protocol or port granularity. This requirement does not require an extended ACL at all.

The ACL must be placed near the destination.

Why wrong: Placement near the destination is a recommended practice once an extended ACL is selected, because it limits extraneous traffic traversing the network. However, the physical or logical placement of an ACL does not determine whether a standard or extended ACL is required; a standard ACL can also be deployed, although it is typically positioned near the source. Therefore, this is a design guideline, not a selection premise.

The network uses IPv6 instead of IPv4.

Why wrong: Whether the network is IPv4 or IPv6 does not alter the fundamental limitation: a named IPv6 ACL is essentially equivalent to an extended ACL in capability, and the choice between standard-like and extended-like matching still depends on the need for granular match criteria. If the requirement is only to match a source subnet, either address family can use a simple source-only ACL. Thus, using IPv6 does not inherently force the extended ACL variant.

access-list 100 permit tcp 10.0.0.0 0.0.0.255 host 203.0.113.1 eq 22 access-list 100 deny ip any host 203.0.113.1 interface GigabitEthernet0/0 ip access-group 100 out

Why wrong: This is incorrect because applying the ACL outbound on G0/0 (facing SW1) would filter traffic leaving R1 toward R2. While it could work, it is less efficient because the traffic has already been routed through R1. Additionally, the implicit deny at the end of the ACL would block all other traffic to the loopback, but the outbound application is not the recommended direction.

access-list 100 permit tcp 10.0.0.0 0.0.0.255 host 203.0.113.1 eq 22 interface GigabitEthernet0/1 ip access-group 100 in

Why wrong: This is incorrect because it lacks the explicit deny statement for all other IP traffic to the loopback. Without the deny, the implicit deny at the end of the ACL will block all other traffic, but the explicit deny is necessary to clearly show the requirement is met. More importantly, the ACL does not deny traffic from other sources to the loopback; the implicit deny only applies to the ACL itself, but the question requires explicit denial.

access-list 100 permit tcp 10.0.0.0 0.0.0.255 host 203.0.113.1 eq 22 access-list 100 deny ip any any interface GigabitEthernet0/1 ip access-group 100 in

Why wrong: This is incorrect because the deny statement 'deny ip any any' blocks all IP traffic, including traffic to other destinations, not just the loopback. The requirement is to deny only traffic to the loopback, not all traffic. This would break connectivity for other traffic.

Enter the interface facing the source, apply the ACL inbound, then enter global configuration mode and create the ACL with deny and permit statements.

Why wrong: You cannot apply an access-list to an interface before it exists. The 'ip access-group' command on an interface references a named or numbered ACL that must already be defined in the running configuration; if it is not, the router returns an error and the command is rejected. Even if ACL creation were possible from interface configuration mode, which it is not, the interface would have no policy to reference, so entering global configuration mode to create the ACL first is mandatory.

Enter global configuration mode, create the ACL with permit ip any any first, then deny tcp 192.168.1.0 0.0.0.255 10.0.0.0 0.0.0.255 eq telnet, then enter the interface facing the source and apply the ACL inbound.

Why wrong: ACLs are evaluated sequentially from top to bottom, and the first matching entry determines what happens. Placing 'permit ip any any' as the first line matches every IP packet, including the Telnet traffic from 192.168.1.0/24 to 10.0.0.0/24, so the subsequent deny statement is never evaluated and the Telnet filter is completely bypassed. To block Telnet, the specific deny entry must appear before any broad permit, making the line order critical for the ACL to function correctly.

Enter global configuration mode, create the ACL with deny tcp 192.168.1.0 0.0.0.255 10.0.0.0 0.0.0.255 eq telnet, then enter the interface facing the source and apply the ACL inbound, without adding a permit statement.

Why wrong: Every IP access-list has an implicit 'deny ip any any' at the end, so any traffic not explicitly matched is dropped. Since the only explicit entry is the deny for Telnet, all other traffic from the 192.168.1.0/24 network to the 10.0.0.0/24 network would also be denied when this ACL is applied inbound on the source-facing interface. To meet the requirement of blocking only Telnet while permitting everything else, you must add an explicit 'permit ip any any' after the deny entry, making the intended allow behavior explicit and overriding the implicit deny.

ip access-list extended BRANCH_IN permit tcp 192.168.1.0 0.0.0.255 host 203.0.113.10 eq 80 permit icmp any any echo-reply ! interface GigabitEthernet0/0 ip access-group BRANCH_IN out

Why wrong: Applying the ACL outbound on GigabitEthernet0/0 is directionally incorrect: inbound evaluates packets arriving from the 192.168.1.0/24 LAN before routing, whereas outbound evaluates packets leaving that interface toward the LAN, which would not inspect the HTTP requests going toward 203.0.113.10. The ACL is therefore useless for the stated purpose, and the implicit deny would still block the permitted traffic. The task specifically requires inbound application on the internal-facing interface.

ip access-list extended BRANCH_IN permit tcp 192.168.1.0 0.0.0.255 host 203.0.113.10 eq 80 permit icmp any any ! interface GigabitEthernet0/0 ip access-group BRANCH_IN in

Why wrong: The ICMP statement `permit icmp any any` is overly broad because it matches every ICMP message type, including echo requests, destination unreachable, and parameter problem. The requirement is to allow only ICMP echo-reply (type 0) so that return pings from the server are accepted; any other ICMP type should fall through to the implicit deny. Without the `echo-reply` keyword, the ACL permits far more control traffic than intended.

ip access-list extended BRANCH_IN permit tcp 192.168.1.0 0.0.0.255 host 203.0.113.10 eq 80 permit icmp any any echo-reply ! interface GigabitEthernet0/0 ip access-group BRANCH_IN in ! interface GigabitEthernet0/1 ip access-group BRANCH_IN in

Why wrong: Binding the same ACL to both GigabitEthernet0/0 and GigabitEthernet0/1 inbound creates an asymmetric filter: on G0/1 it inspects packets entering from the external network, and because the only TCP permit is sourced from 192.168.1.0/24, legitimate return traffic from the web server (source 203.0.113.10) would be denied by the implicit deny. Applying an ACL on the external-facing interface also violates the explicit instruction to apply it only on the internal-facing interface, and it disrupts inbound connectivity that the requirements never intended to restrict.

Because Telnet uses UDP, not TCP.

Why wrong: Telnet is an application-layer protocol that relies on TCP port 23 to provide a reliable, connection-oriented byte stream for interactive terminal sessions. UDP is a connectionless protocol not used by Telnet, so any ACL that tries to filter Telnet as UDP would fail to match Telnet traffic entirely. Therefore, this statement is factually incorrect.

Because the ACL should be a standard ACL, not an extended ACL.

Why wrong: Standard ACLs (numbered 1-99 or 1300-1999) can match only the source IP address and cannot examine protocol types or destination ports. Because the intention is to block only Telnet traffic to a specific server, an extended ACL is required to specify TCP and the destination port. So the claim that it should be a standard ACL is wrong.

Because the host keyword can never be used with TCP statements.

Why wrong: The 'host' keyword in an extended ACL is used to specify a single IP address for a source or destination, and it can be combined with any IP protocol, including TCP, UDP, and ICMP. There is no restriction preventing 'host' from being used in TCP permit or deny statements. Thus, this statement is invalid as a reason for the ACL blocking extra traffic.

Enter interface configuration mode, apply ACL inbound, then create ACL with permit statement, add deny ip any any, exit to global config.

Why wrong: This sequence is invalid because the ACL must exist before you can apply it to an interface. In Cisco IOS, entering interface configuration mode and attempting to bind a non-existent ACL (e.g., with ip access-group) will produce an error or an empty group, so the permit and deny entries are never defined. The proper order is: create the ACL in global configuration mode, exit, then enter interface configuration mode and apply it inbound—never the reverse.

Enter global configuration mode, create ACL with deny ip any any first, then permit statement for HTTP, enter interface, apply ACL inbound.

Why wrong: This ordering is incorrect because ACLs are processed sequentially, top-to-bottom, and the first match takes action. Placing deny ip any any as the first entry causes all packets—including the HTTP traffic from 192.168.1.0/24 to 10.0.0.1—to be immediately dropped, and the subsequent permit statement will never be evaluated. To allow the desired HTTP traffic and block everything else, the permit statement must precede the deny all entry.

Enter global configuration mode, create ACL with permit statement for HTTP, add deny ip any any, apply ACL outbound on interface GigabitEthernet0/1.

Why wrong: This option fails primarily because the ACL is applied outbound on GigabitEthernet0/1, whereas the requirement specifies inbound filtering. On a LAN-facing interface, inbound evaluates packets arriving from the source network before routing; outbound would apply after routing, missing the intended placement and potentially not matching the traffic path. Additionally, the permit statement here is underspecified—it lacks the source and destination details (192.168.1.0/24 to 10.0.0.1)—so even with correct direction, it would not enforce the desired granularity.

ip access-list standard INTERNET-FILTER permit 10.1.1.0 0.0.0.255 ! interface GigabitEthernet0/1 ip access-group INTERNET-FILTER in

Why wrong: This is incorrect because a standard ACL can only filter based on source IP, not destination or port. It would permit all traffic from the internal network, not just HTTP to the web server, and would not block other traffic.

ip access-list extended INTERNET-FILTER permit tcp host 10.1.1.100 10.1.1.0 0.0.0.255 eq 80 deny ip any any ! interface GigabitEthernet0/1 ip access-group INTERNET-FILTER in

Why wrong: This is incorrect because the permit statement has the source and destination reversed. It permits traffic from the web server to the internal network, not the other way around. Also, the deny any any would block all traffic, including necessary internal traffic.

ip access-list extended INTERNET-FILTER permit tcp 10.1.1.0 0.0.0.255 host 10.1.1.100 eq 80 deny ip any any ! interface GigabitEthernet0/0 ip access-group INTERNET-FILTER in

Why wrong: This is incorrect because the ACL is applied inbound on the external interface (GigabitEthernet0/0) instead of the internal interface. This would filter traffic coming from the internet into the router, not internal traffic going out.

The ACL is applied to the interface in the wrong direction (inbound instead of outbound).

Why wrong: If the ACL were applied in any direction, the output would show an access list number or name, even if it were the wrong direction. Both lines are 'not set', proving that no ACL is assigned.

The access-list 110 syntax has incorrect subnet masks causing no matches.

Why wrong: ACL syntax errors, including incorrect wildcard masks, would not prevent the ACL from being displayed as applied on the interface; 'show ip interface' would still list the ACL number or name even if its matching logic was flawed. The output shows 'Inbound access list is not set' and 'Outgoing access list is not set', which proves that no ACL is attached to GigabitEthernet0/0 at all. Furthermore, if the masks were wrong, the ACL would still be present in 'show ip access-lists', so the absence from the interface output definitively rules this out as the cause.

The interface GigabitEthernet0/0 is administratively down, preventing ACL processing.

Why wrong: The exhibit's first line clearly states 'GigabitEthernet0/0 is up, line protocol is up', meaning the interface is operational and capable of forwarding traffic. An administratively down interface would display 'administratively down, line protocol is down' and would not pass any packets, making ACL processing irrelevant. Since the interface is up, the lack of ACL hit counts must be explained by the ACL not being applied rather than by an interface state issue.

The access list is applied in the wrong direction on the interface.

Why wrong: The 'show access-lists' command does not reveal any interface binding or directional information; it only lists the access control entries and their match counters. Therefore, asserting that the ACL is applied in the wrong direction is an unsupported guess. In fact, regardless of whether the ACL is inbound or outbound on the interface, the absence of a permit for port 443 would still cause HTTPS traffic to be denied by the implicit deny.

The web server is not actually listening on TCP port 443, despite the configuration.

Why wrong: The scenario explicitly states that the web server is running and listening on both TCP port 80 and port 443, so the server is not the source of the problem. The failure occurs before packets reach the server: the router's ACL is dropping them. Because the ACL lacks a permit statement for port 443, the server never receives the HTTPS connection requests, so its listening state is irrelevant to the troubleshooting.

The 'deny ip any any log' statement at the end of the access list is blocking the HTTPS traffic, so it must be removed.

Why wrong: Removing the explicit deny statement would not help, because the default implicit deny-all still drops any traffic not explicitly permitted. The traffic must be allowed with a permit statement for port 443 before any deny line.

permit tcp any any eq 25 deny tcp 192.168.10.0 0.0.0.255 host 203.0.113.10 eq 25 permit ip any any

Why wrong: This is incorrect because it permits all SMTP traffic first, then denies the specific SMTP traffic, which has no effect since the permit any any already allows it. The deny line is never reached for that traffic.

deny tcp any any eq 25 permit tcp 192.168.10.0 0.0.0.255 host 203.0.113.10 eq 25 permit ip any any

Why wrong: Placing 'deny tcp any any eq 25' first is fatal because ACLs are evaluated top-down and the first match wins. Any SMTP packet (destination port 25) from any source, including the desired 192.168.10.0/24 to 203.0.113.10 traffic, will match this broad deny rule immediately and be dropped. The subsequent specific permit line is never evaluated for that traffic, so the permit becomes a dead entry that can only affect non-SMTP packets, which are already covered by the final 'permit ip any any'.

permit tcp 192.168.10.0 0.0.0.255 host 203.0.113.10 eq 25 permit ip any any deny tcp any any eq 25

Why wrong: This is incorrect because the permit ip any any at the end allows all IP traffic, including SMTP from other sources, before the deny tcp any any eq 25 is reached. The deny line becomes useless.

The original standard ACL only had a permit statement, so after removal the permit still takes effect because the ACL remains in the running configuration.

Why wrong: The misunderstanding here is that an ACL has effect merely by being defined in the configuration. In Cisco IOS, an ACL is only a filter when it is bound to an interface via the ip access-group command. Removing that binding deactivates the ACL entirely, leaving the permit statement in the running configuration as an inert list that does not inspect or affect any traffic. The router then applies its default permit-all behavior to that interface.

The ip access-group command on the interface remains but is missing the referenced ACL, causing the router to default to denying all ingress traffic except the previously permitted 10.0.0.0/8.

Why wrong: This option assumes a half-removed state where the ip access-group reference lingers after the ACL itself is deleted. In practice, removing the ACL from an interface also removes the ip access-group command, so no dangling reference remains. Even if such a reference were possible, Cisco IOS would not fall back to selectively permitting 10.0.0.0/8 based on the old ACL's contents; the system does not infer prior rules into a default deny. The router's behavior is simply all-pass once the ACL is de-applied.

The ACL was reapplied in the outbound direction instead of inbound, so it now blocks traffic leaving the interface but not entering it.

Why wrong: This scenario is explicit that the ACL was removed, not reapplied in a different direction. An outbound ACL would filter only packets leaving the interface, and it would have no effect on incoming spoofed traffic, so it cannot explain why such traffic is now allowed. Without an inbound access-group, the interface reverts to the default permit-all behavior for ingress packets. The root cause is de-applying the ACL, not a mistaken change of direction.

The implicit deny at the end of ACL 10 is blocking all outbound traffic from the 192.168.2.0/24 network.

Why wrong: Standard ACLs evaluate packets only as they enter the interface on which the ACL is applied. Because ACL 10 is applied inbound on G0/0, it inspects packets arriving from the Internet, not packets that the router is forwarding out G0/0 toward the Internet. Outbound traffic sourced from 192.168.2.0/24 would egress G0/0 (or another interface) and would never match this inbound ACL, so the implicit deny at the end of ACL 10 cannot block that traffic. The deny only rejects inbound packets that do not match the permit statement, making it irrelevant to outbound flow.

The router is not performing inter-VLAN routing between the 192.168.1.0 and 192.168.2.0 networks.

Why wrong: Inter-VLAN routing relies on the routing table, not ACLs, to forward packets between directly connected subnets. The ACL only filters traffic passing through the interface where it is applied and does not disable routing between the two LANs.

The ACL is missing a permit statement for the 192.168.2.0/24 network to allow traffic from that subnet.

Why wrong: Even if a permit for 192.168.2.0/24 were added, the ACL is applied inbound on G0/0. Traffic from 192.168.2.0/24 going to the Internet would exit out G0/0, not enter, so it would not be evaluated by this ACL. The missing permit is not the root cause; the direction is wrong.

Standard ACLs are typically placed closest to the source of the traffic.

Why wrong: Standard ACLs identify traffic based solely on the source IP address and have no way to distinguish destination or ports. Placing a standard ACL close to the source would incorrectly permit or deny traffic to any destination, potentially blocking legitimate traffic that should be allowed to reach other hosts. Therefore, standard ACLs are typically placed as close to the destination as possible to minimize the risk of over-filtering.

A wildcard mask of 255.255.255.255 in an ACL matches all bits of the IP address.

Why wrong: A wildcard mask of 255.255.255.255 is used to ignore all bits, meaning every bit in the IP address is treated as a wildcard and does not need to match. Therefore, this mask matches any IP address, equivalent to the keyword 'any.' The claim that it matches all bits is incorrect because binary 255 in each octet indicates 'don't care' for every bit, not a strict match.

Extended ACLs should be placed on the interface closest to the destination to filter traffic before it reaches the final segment.

Why wrong: Placing extended ACLs near the destination is poor practice because the unwanted traffic still traverses the entire network, consuming bandwidth and processing on every intermediate router before it is finally dropped. Extended ACLs can filter on details like destination port and protocol, so enforcing them at the source interface blocks the traffic early and avoids wasting network resources. This contradicts the design principle that extended ACLs should be closest to the source, not the destination.