Extended Access Control Lists (ACLs) are the primary tool for granular traffic filtering in Cisco networks, and mastering them is essential for the CCNA 200-301 exam (objective 5.6). Unlike standard ACLs, extended ACLs can filter based on source and destination IP addresses, protocols, and port numbers, giving you precise control over which traffic is permitted or denied. In real networks, extended ACLs are used to enforce security policies, restrict access to sensitive servers, and block specific types of attacks. This lab will walk you through configuring an extended ACL to secure a small enterprise network.
Jump to a section
Think of an extended ACL as an airport security checkpoint that inspects not just the passenger's identity (source IP) but also their destination, the airline (protocol), and even the type of ticket (port number). At a standard checkpoint, a guard only checks ID—anyone with a valid ID can pass. But at an extended checkpoint, the guard examines the boarding pass: they check the departure gate (source IP), the arrival city (destination IP), the airline (protocol like TCP or UDP), and the class (port number like port 80 for web traffic). For example, if a passenger wants to board a flight to New York (destination IP) on Delta (protocol TCP) with a first-class ticket (port 443 for HTTPS), the guard checks each detail against a list of allowed combinations. If the list says 'Allow Delta flights to New York only for first-class passengers,' then a coach passenger (port 80) is denied. Similarly, an extended ACL processes each packet sequentially: it checks the source IP, then destination IP, then protocol, then port. If a match is found, the action (permit/deny) is applied immediately, and no further rules are checked. This granularity allows you to, for instance, block all traffic to a server except web traffic from a specific subnet—just like allowing only first-class passengers on a specific airline to a specific destination.
What is an Extended ACL?
An extended ACL is a sequential list of permit or deny statements that filter IP packets based on multiple criteria: source IP address, destination IP address, protocol (IP, TCP, UDP, ICMP, etc.), and optionally source and destination port numbers. Extended ACLs are identified by a number (100-199 or 2000-2699 for modern IOS) or a name. They are more flexible than standard ACLs, which can only filter based on source IP. Extended ACLs are applied to interfaces in a specific direction (inbound or outbound) and are processed top-down: the first matching rule determines the action. If no match is found, an implicit deny all at the end drops the packet.
How Extended ACLs Work Step-by-Step
A packet arrives at an interface where an extended ACL is applied.
The router examines the packet's source IP, destination IP, protocol type (e.g., TCP), and port numbers (if TCP/UDP).
The router checks the ACL entries in order (lowest sequence number first).
For each entry, the router compares the packet's fields against the entry's conditions:
- If the source IP matches (using wildcard mask), continue; else try next entry. - If the destination IP matches, continue; else try next entry. - If the protocol matches (e.g., tcp), continue; else try next entry. - If the port numbers match (e.g., eq 80), then a match is declared. 5. If a match is found, the router applies the configured action (permit or deny) and stops processing the ACL. 6. If no match is found after all entries, the implicit deny any any applies, and the packet is dropped.
Key Characteristics and Defaults
Extended ACLs use numbers 100-199 and 2000-2699. Named ACLs are also supported.
Wildcard masks are used to match IP addresses. A 0 in the mask means 'must match exactly', while 255 means 'ignore'. For example, 192.168.1.0 0.0.0.255 matches all addresses in the 192.168.1.0/24 subnet.
Port numbers can be specified with operators: eq (equal), gt (greater than), lt (less than), neq (not equal), and range (inclusive range).
The protocol keyword can be tcp, udp, icmp, ip (all IP protocols), or a protocol number.
Extended ACLs should be applied as close to the source as possible to conserve bandwidth, but this is a best practice, not a requirement.
The implicit deny any any is always present at the end of every ACL. It does not appear in the configuration but is enforced.
IOS CLI Configuration and Verification
To configure an extended ACL, use global configuration mode:
R1(config)# access-list 100 permit tcp 192.168.1.0 0.0.0.255 host 10.0.0.1 eq 80
R1(config)# access-list 100 deny ip any anyThis ACL permits TCP traffic from the 192.168.1.0/24 subnet to destination host 10.0.0.1 on port 80 (HTTP). All other IP traffic is denied. Note that the deny entry is optional but explicitly shows the implicit deny.
To apply the ACL to an interface:
R1(config)# interface GigabitEthernet0/0
R1(config-if)# ip access-group 100 inTo verify the ACL:
R1# show access-lists 100
Extended IP access list 100
10 permit tcp 192.168.1.0 0.0.0.255 host 10.0.0.1 eq www (12 matches)
20 deny ip any any (5 matches)Notice that sequence numbers (10, 20) are automatically assigned. You can also use named ACLs:
R1(config)# ip access-list extended BLOCK_SSH
R1(config-ext-nacl)# deny tcp any host 10.0.0.1 eq 22
R1(config-ext-nacl)# permit ip any anyInteraction with Other Features
Extended ACLs interact with Network Address Translation (NAT) and routing. When an ACL is applied inbound, it filters packets before routing; when applied outbound, it filters after routing. For NAT, the ACL is evaluated against the packet's pre-translation IP (if inbound) or post-translation IP (if outbound). Also, extended ACLs can be used with the access-class command to restrict Telnet/SSH access to the router itself.
Common Pitfalls
Forgetting the implicit deny: If you only have permit statements, all other traffic is denied. Always include a permit any any at the end if you want to allow all other traffic.
Incorrect wildcard mask: A common mistake is using a subnet mask instead of a wildcard mask. For example, 192.168.1.0 255.255.255.0 is invalid; the correct wildcard is 0.0.0.255.
Applying the ACL in the wrong direction: Inbound ACLs filter traffic coming into the interface, outbound ACLs filter traffic leaving the interface. Misapplication can cause unintended blocks.
Design the ACL Policy
Before configuring, define the security policy. In this lab, we have a network with three subnets: 192.168.1.0/24 (Sales), 192.168.2.0/24 (Engineering), and 10.0.0.0/24 (Server Farm). Policy requirements: 1) Allow Sales subnet to access the web server at 10.0.0.1 (port 80) and the database server at 10.0.0.2 (port 3306). 2) Allow Engineering subnet to access the database server only. 3) Allow all hosts to ping the servers (ICMP). 4) Deny all other traffic from these subnets to the servers. 5) Permit all other traffic (e.g., Internet access). We'll implement this with a named extended ACL applied inbound on the router interface facing the servers.
Configure the Extended ACL
Use the `ip access-list extended` command to create a named ACL. Enter the following configuration on the router (R1) that connects the subnets to the servers: ``` R1(config)# ip access-list extended SERVER_ACCESS R1(config-ext-nacl)# permit tcp 192.168.1.0 0.0.0.255 host 10.0.0.1 eq 80 R1(config-ext-nacl)# permit tcp 192.168.1.0 0.0.0.255 host 10.0.0.2 eq 3306 R1(config-ext-nacl)# permit tcp 192.168.2.0 0.0.0.255 host 10.0.0.2 eq 3306 R1(config-ext-nacl)# permit icmp 192.168.1.0 0.0.0.255 host 10.0.0.1 R1(config-ext-nacl)# permit icmp 192.168.1.0 0.0.0.255 host 10.0.0.2 R1(config-ext-nacl)# permit icmp 192.168.2.0 0.0.0.255 host 10.0.0.1 R1(config-ext-nacl)# permit icmp 192.168.2.0 0.0.0.255 host 10.0.0.2 R1(config-ext-nacl)# deny ip 192.168.1.0 0.0.0.255 10.0.0.0 0.0.0.255 R1(config-ext-nacl)# deny ip 192.168.2.0 0.0.0.255 10.0.0.0 0.0.0.255 R1(config-ext-nacl)# permit ip any any ``` Note: The deny statements block all other IP traffic from the subnets to the server subnet. The final permit any any allows all other traffic (e.g., Internet-bound).
Apply the ACL to the Interface
Apply the ACL inbound on the interface that connects to the server subnet. Assuming the router's interface facing the servers is GigabitEthernet0/1 with IP 10.0.0.254/24: ``` R1(config)# interface GigabitEthernet0/1 R1(config-if)# ip access-group SERVER_ACCESS in ``` This filters all traffic entering the router from the server subnet direction. Since the ACL is applied inbound, it examines packets before the router makes a routing decision. For traffic from Sales to the web server, the packet enters GigabitEthernet0/1? No—traffic from Sales enters via another interface (e.g., GigabitEthernet0/0) and is routed out GigabitEthernet0/1. So the ACL should be applied outbound on the interface facing the servers? Actually, careful: The ACL filters traffic *flowing through* the interface. If we want to filter traffic from Sales to servers, that traffic enters the router on Sales interface and exits towards servers. To filter it as it exits towards servers, apply the ACL outbound on the server-facing interface. Let's correct: apply outbound on GigabitEthernet0/1: ``` R1(config-if)# ip access-group SERVER_ACCESS out ``` This is a common decision point. In this lab, we apply it outbound because the traffic is destined out that interface.
Verify the ACL Configuration
Use the following commands to verify: ``` R1# show access-lists SERVER_ACCESS Extended IP access list SERVER_ACCESS 10 permit tcp 192.168.1.0 0.0.0.255 host 10.0.0.1 eq www 20 permit tcp 192.168.1.0 0.0.0.255 host 10.0.0.2 eq 3306 30 permit tcp 192.168.2.0 0.0.0.255 host 10.0.0.2 eq 3306 40 permit icmp 192.168.1.0 0.0.0.255 host 10.0.0.1 50 permit icmp 192.168.1.0 0.0.0.255 host 10.0.0.2 60 permit icmp 192.168.2.0 0.0.0.255 host 10.0.0.1 70 permit icmp 192.168.2.0 0.0.0.255 host 10.0.0.2 80 deny ip 192.168.1.0 0.0.0.255 10.0.0.0 0.0.0.255 90 deny ip 192.168.2.0 0.0.0.255 10.0.0.0 0.0.0.255 100 permit ip any any ``` Check that the ACL is applied to the correct interface: ``` R1# show ip interface GigabitEthernet0/1 GigabitEthernet0/1 is up, line protocol is up Internet address is 10.0.0.254/24 ... Outgoing access list is SERVER_ACCESS ``` Also verify with `show running-config | include access-group`.
Test the ACL with Ping and Telnet
From a host in Sales (192.168.1.10), test connectivity: ``` C:\> ping 10.0.0.1 Reply from 10.0.0.1: bytes=32 time<1ms TTL=128 (should succeed) C:\> telnet 10.0.0.1 80 Connecting To 10.0.0.1...Could not open connection (should fail because ACL permits only TCP, not Telnet; but Telnet on port 80? Actually, telnet to port 80 is HTTP, but the ACL permits TCP to port 80, so it should succeed. Let's use a different test: try to SSH to 10.0.0.1 (port 22) – should fail because not permitted) ``` From Engineering (192.168.2.10): ``` C:\> ping 10.0.0.1 Reply from 10.0.0.1: bytes=32 time<1ms TTL=128 (should succeed) C:\> telnet 10.0.0.1 80 Could not open connection (should fail because Engineering is not permitted to access port 80 on web server) ``` Use `show access-lists SERVER_ACCESS` to see hit counts increase.
Troubleshoot ACL Issues
If expected traffic is blocked, check the following: 1. Verify the ACL entries order: The first match wins. Use `show access-lists` to see the sequence numbers and hit counts. If a deny entry has matches but you expected permit, the deny is too early. 2. Check the direction: `show ip interface` shows applied access group direction. If traffic is not filtered as expected, ensure the ACL is applied in the correct direction (in/out) on the correct interface. 3. Check for implicit deny: If you forgot `permit ip any any`, all unmatched traffic is denied. Add it if needed. 4. Use `debug ip packet` with caution: This can generate a lot of output. Use an ACL to limit debug to specific traffic. 5. Verify routing: Ensure the router has a route to the destination networks. ACLs do not replace routing. Example debug: ``` R1# debug ip packet 100 R1# terminal monitor ``` This will show packets that match ACL 100. But be careful in production.
In enterprise networks, extended ACLs are deployed at network boundaries to enforce security policies. For example, a company might have a data center with multiple servers (web, database, mail) and want to restrict access based on department. A network engineer would configure an extended ACL on the distribution switch that connects the access layer to the data center. The ACL would permit HTTP/HTTPS traffic from the entire company to the web server, but only allow database traffic from the application server subnet to the database server. This is often done using a 'security zone' model where each server has a specific ACL.
Another common scenario is blocking peer-to-peer traffic or limiting access to sensitive resources like HR systems. For instance, an ACL can deny all traffic from the guest wireless network to the internal server subnet while permitting Internet access. This is achieved by applying an inbound ACL on the guest VLAN interface that denies traffic to the internal IP range.
Performance considerations: Extended ACLs are processed in software on most routers, so a large ACL (hundreds of entries) can impact CPU usage. On high-end routers, ACLs can be hardware-accelerated. A best practice is to keep ACLs as small as possible and place them close to the source to reduce unnecessary traffic. Also, use named ACLs for easier management.
Misconfiguration can lead to security breaches or service outages. For example, if an ACL incorrectly blocks DNS traffic (UDP port 53), users cannot resolve domain names. Another common mistake is applying an ACL in the wrong direction, causing all traffic to be dropped. Always test ACLs in a lab before deploying to production, and use hit counts to verify that rules are being matched as expected.
On the CCNA 200-301 exam, objective 5.6 covers configuring and verifying extended ACLs. You must know how to interpret ACL syntax, apply ACLs to interfaces, and understand the order of operations. The exam will test you on:
Identifying the correct ACL number range (100-199, 2000-2699) or named ACL.
Understanding wildcard masks: A common trap is confusing wildcard with subnet mask. For example, matching a host 10.0.0.1 uses wildcard 0.0.0.0, not 255.255.255.255.
The implicit deny any any: Many candidates forget this and think only explicit entries matter. The exam will test scenarios where no permit any any exists, and traffic is denied.
Direction: Inbound ACLs filter before routing, outbound after routing. A classic question: 'Where should you place an ACL to block traffic from a specific source?' The answer: as close to the source as possible, but the direction depends on traffic flow.
Port operators: eq, gt, lt, neq, range. A question might ask which ACL entry permits only HTTP traffic (tcp eq 80).
Common wrong answers: 1. Using subnet mask instead of wildcard mask. Candidates choose 255.255.255.0 instead of 0.0.0.255. 2. Placing an ACL in the wrong direction. For example, applying an inbound ACL on the source interface to filter traffic going out. 3. Forgetting that extended ACLs can filter on destination IP; standard ACLs cannot. Some candidates think only source IP can be filtered. 4. Thinking that the order of entries doesn't matter. In fact, the first match wins, so ordering is critical.
Elimination strategy: For scenario questions, first identify what traffic needs to be filtered (source, destination, protocol, port). Then look for the ACL that has the correct combination. Eliminate any ACL that uses wrong syntax (e.g., missing protocol, wrong wildcard). Then check the direction and interface application. Finally, ensure the implicit deny is accounted for.
Extended ACLs filter based on source/destination IP, protocol, and port (TCP/UDP).
ACL numbers: 100-199 and 2000-2699 for extended; named ACLs are also valid.
Wildcard masks: 0 = match exact, 255 = ignore; e.g., 0.0.0.255 matches any host in the /24 subnet.
Implicit deny any any is always present at the end of every ACL.
Apply ACLs as close to the source as possible to reduce unnecessary traffic.
Use 'show access-lists' to view hit counts and verify matches.
The first matching entry determines action; order matters.
These come up on the exam all the time. Here's how to tell them apart.
Standard ACL
Filters only on source IP address.
Uses numbers 1-99 and 1300-1999.
Applied close to destination (best practice).
Less granular; cannot filter by port or protocol.
Example: access-list 1 permit 192.168.1.0 0.0.0.255
Extended ACL
Filters on source/destination IP, protocol, and port.
Uses numbers 100-199 and 2000-2699, or named ACLs.
Applied close to source (best practice).
Granular control; can block specific applications.
Example: access-list 100 permit tcp 192.168.1.0 0.0.0.255 host 10.0.0.1 eq 80
Mistake
Extended ACLs can only filter on source IP and destination IP.
Correct
Extended ACLs can also filter on protocol (TCP, UDP, ICMP, IP) and port numbers (for TCP/UDP). This is what distinguishes them from standard ACLs.
Many candidates confuse standard and extended ACL capabilities because standard ACLs only use source IP.
Mistake
The implicit deny any any can be overridden by adding a permit any any at the end.
Correct
The implicit deny is always present, but an explicit permit any any will match all remaining traffic before the implicit deny, effectively allowing everything. The implicit deny still exists but is never reached.
Candidates think the implicit deny is a configuration line that can be removed; it is not configurable.
Mistake
Wildcard mask 0.0.0.0 matches all IP addresses.
Correct
Wildcard mask 0.0.0.0 means all bits must match exactly, so it matches only a single host. To match all addresses, use 255.255.255.255.
The name 'wildcard' is misleading; a 0 in the mask means 'check this bit', not 'wildcard'.
Mistake
ACLs are processed in the order they are entered, but the router reorders them for efficiency.
Correct
ACLs are always processed in the order they are entered (sequence number order). The router does not reorder them. The first match wins.
Some candidates think the router optimizes ACLs, but that is not true for standard IOS.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A standard ACL filters only on source IP address, while an extended ACL can filter on source IP, destination IP, protocol (e.g., TCP, UDP, ICMP), and port numbers. Extended ACLs are more granular and are preferred for security policies. On the CCNA exam, remember that standard ACLs use numbers 1-99 and 1300-1999, while extended ACLs use 100-199 and 2000-2699, or named ACLs. Standard ACLs are typically placed close to the destination, extended ACLs close to the source.
Use the 'ip access-group' command in interface configuration mode. For example: 'interface GigabitEthernet0/0' then 'ip access-group 100 in' applies ACL 100 inbound. The direction can be 'in' (filtering packets entering the interface) or 'out' (filtering packets leaving the interface). Remember: inbound ACLs are processed before routing, outbound after routing. To verify, use 'show ip interface'.
Every ACL has an implicit 'deny any any' at the end. This means if a packet does not match any explicit permit or deny statement, it is denied. This is not visible in the configuration but is always enforced. To allow all other traffic, you must add an explicit 'permit ip any any' at the end of the ACL. On the exam, be aware that omitting this will cause unexpected denials.
You can use sequence numbers to insert or delete entries. For example, 'ip access-list extended MY_ACL' enters config-ext-nacl mode, then 'no 10' deletes sequence 10, or '5 permit tcp any any' inserts a new entry as sequence 5. Alternatively, you can remove the entire ACL with 'no access-list 100' and reconfigure. Named ACLs are easier to edit. Always verify with 'show access-lists'.
No, extended ACLs filter only IP packets. For non-IP protocols (e.g., IPX, AppleTalk), you need other types of ACLs (e.g., MAC ACLs or protocol-specific ACLs). On modern networks, IP is dominant, so this is rarely an issue. The CCNA exam focuses on IP ACLs.
A wildcard mask is a 32-bit number where 0 means 'must match' and 1 means 'ignore'. It is the inverse of a subnet mask. For example, to match a single host, use 0.0.0.0. To match a /24 subnet, use 0.0.0.255. To match all addresses, use 255.255.255.255. You can calculate by subtracting the subnet mask from 255.255.255.255. For example, /24 subnet mask 255.255.255.0 gives wildcard 0.0.0.255.
Use the 'show access-lists' command to see hit counts. You can also use 'debug ip packet' with an ACL to monitor specific traffic. However, debug can be CPU-intensive. In a lab, simulate traffic with ping or telnet. For production, apply the ACL with 'permit' first and monitor logs before adding 'deny' statements. Always have a rollback plan.
You've just covered Lab: Configure Extended ACL — now see how well it sticks with free CCNA 200-301 practice questions. Full explanations included, no account needed.
Done with this chapter?