Extended ACL Configuration

Standard ACLs filter traffic by source IP alone — a blunt instrument that cannot distinguish between a user browsing a web server and the same user sending an email to it. Extended ACLs add four additional match criteria: source IP, destination IP, protocol (TCP, UDP, ICMP, and others), and port number. This combination allows surgical traffic control — permit HTTP to the web server but deny FTP, allow ICMP from the network operations centre but block it from untrusted hosts, or restrict Telnet to the router while permitting SSH. For ACL concepts and wildcard masks see ACL Overview and Wildcard Masks.

Because extended ACLs can specify both source and destination, they should be placed close to the source — dropping unwanted traffic as early as possible before it wastes bandwidth traversing the network. This is the opposite placement rule from standard ACLs.

Before starting, complete Standard ACL Configuration to understand ACL fundamentals — implicit deny, wildcard masks, sequence numbers, and the access-class vs ip access-group distinction. For applying ACLs to interfaces and VTY lines see Applying ACLs and Named ACLs. For common port number reference see Common Port Numbers. For the NAT context where extended ACLs are sometimes used alongside PAT, see Dynamic NAT & PAT Configuration and NAT Overview.

1. Extended ACL — Core Concepts

Extended ACL Syntax

Extended ACL entries follow a consistent pattern. Every element after the sequence number is evaluated left to right — all specified criteria must match for the rule to fire:

  [sequence] permit|deny  protocol  source wildcard  [src-port]  destination wildcard  [dst-port]  [log]

  Example:
  10 permit tcp  192.168.10.0 0.0.0.255  any          eq 80
     └permit─┘  └──tcp──────┘ └─src────┘ └─dst──┘    └─HTTP────┘
  "Permit TCP from any host in 192.168.10.0/24 to any destination on port 80"

  20 deny   icmp 192.168.20.0 0.0.0.255  host 10.0.0.1  echo
     └deny─┘  └icmp──┘ └─src─────────┘  └─dst────────┘ └ICMP echo (ping)─┘
  "Deny ICMP echo (ping) from 192.168.20.0/24 to host 10.0.0.1"

Extended ACL Number Range

ACL Type	Numbered Range	Named	Match Fields
Standard	1–99, 1300–1999	✅	Source IP only
Extended	100–199, 2000–2699	✅	Source IP, Destination IP, Protocol, Port

Protocol Keywords

Keyword	Protocol	Protocol Number	When to Use
`tcp`	TCP	6	HTTP, HTTPS, SSH, Telnet, FTP, SMTP — any TCP-based service
`udp`	UDP	17	DNS, DHCP, NTP, SNMP, syslog — any UDP-based service
`icmp`	ICMP	1	Ping (echo), traceroute (echo-reply), unreachable messages
`ospf`	OSPF	89	Permit/deny OSPF routing protocol packets specifically — see OSPF Configuration
`eigrp`	EIGRP	88	Permit/deny EIGRP routing protocol packets — see EIGRP Configuration
`ip`	All IP protocols	—	Match any IP packet regardless of protocol — equivalent to "any" at the protocol level

Port Match Operators

Operator	Meaning	Example	Matches
`eq [port]`	Equal to — exactly this port	`eq 80`	Exactly port 80 only
`neq [port]`	Not equal to — anything except this port	`neq 23`	All ports except 23
`lt [port]`	Less than — all ports below this number	`lt 1024`	Ports 0–1023 (well-known ports)
`gt [port]`	Greater than — all ports above this number	`gt 1023`	Ports 1024–65535 (ephemeral ports)
`range [start] [end]`	Inclusive range between two port numbers	`range 20 21`	Ports 20 and 21 (FTP data + control)

Common Port Numbers for ACL Rules

For the full port number reference see Common Port Numbers and Ports Overview.

Service	Protocol	Port	IOS Keyword
HTTP	TCP	80	`eq www` or `eq 80`
HTTPS	TCP	443	`eq 443`
SSH	TCP	22	`eq 22` or `eq ssh`
Telnet	TCP	23	`eq 23` or `eq telnet`
FTP Data	TCP	20	`eq ftp-data` or `eq 20`
FTP Control	TCP	21	`eq ftp` or `eq 21`
DNS	UDP / TCP	53	`eq domain` or `eq 53`
SMTP	TCP	25	`eq smtp` or `eq 25`
SNMP	UDP	161	`eq snmp` or `eq 161`
NTP	UDP	123	`eq 123` or `eq ntp`

Extended ACL Placement — Close to Source

Extended ACLs can specify both source AND destination. Placing them close to the source drops unwanted traffic immediately — it never wastes bandwidth traversing the network:

ACL Type	Placement Rule	Reason
Standard	Close to destination	Filters only source IP — near source blocks the source from all destinations
Extended	Close to source	Specifies exact destination — can safely block specific source→destination without collateral damage

2. Lab Topology & Scenario

Four extended ACL use cases are covered in this lab, each targeting a different real-world requirement. All ACLs are applied on NetsTuts_R1 — the edge/distribution router sitting between internal VLANs and the server/internet segment:

         192.168.10.0/24              192.168.20.0/24
         Staff VLAN                   Guest VLAN
         [PC1: .10.10]                [Laptop1: .20.10]
               |                           |
          Gi0/1 (INSIDE)             Gi0/2 (INSIDE)
          192.168.10.1               192.168.20.1
               └──────────────────────────┘
                         NetsTuts_R1
                         Gi0/0: 203.0.113.2 (WAN)
                              |
              ════════════════════════════
                         10.0.12.0/30
                              |
                         NetsTuts_R2
                         Gi0/1: 192.168.30.1
                              |
                    192.168.30.0/24 — Server VLAN
                    [Web Server:  192.168.30.10  TCP/80,443]
                    [FTP Server:  192.168.30.11  TCP/20,21]
                    [Mail Server: 192.168.30.12  TCP/25]

  Use Case 1: Block Telnet from Guest VLAN to ALL destinations
              (applied inbound on R1 Gi0/2 — close to Guest source)
  Use Case 2: Permit only HTTP/HTTPS from Guest to Web Server
              (applied inbound on R1 Gi0/2)
  Use Case 3: Deny ICMP from Guest VLAN to Server VLAN entirely
              (applied inbound on R1 Gi0/2)
  Use Case 4: Block FTP from Staff VLAN to FTP Server
              but permit all other Staff traffic
              (applied inbound on R1 Gi0/1 — close to Staff source)

Use Case	ACL Name	Protocol + Port	Source	Destination	Applied Interface	Direction
Block Telnet	GUEST-POLICY	TCP/23	192.168.20.0/24	any	Gi0/2	in
Permit HTTP/HTTPS only	GUEST-POLICY	TCP/80, 443	192.168.20.0/24	192.168.30.10	Gi0/2	in
Deny ICMP to Servers	GUEST-POLICY	ICMP echo	192.168.20.0/24	192.168.30.0/24	Gi0/2	in
Block FTP from Staff	STAFF-POLICY	TCP/20,21	192.168.10.0/24	192.168.30.11	Gi0/1	in

3. Step 1 — Numbered Extended ACL (Classic Syntax)

Numbered extended ACLs use numbers 100–199 or 2000–2699. The syntax adds protocol and optional port operators after the source and destination wildcards:

NetsTuts_R1>en
NetsTuts_R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.

! ── ACL 110: Block Telnet (TCP/23) from Guest VLAN ───────
NetsTuts_R1(config)#access-list 110 deny tcp 192.168.20.0 0.0.0.255 any eq 23
NetsTuts_R1(config)#access-list 110 permit ip any any

! ── Apply inbound on Gi0/2 (Guest VLAN interface) ────────
NetsTuts_R1(config)#interface GigabitEthernet0/2
NetsTuts_R1(config-if)#ip access-group 110 in
NetsTuts_R1(config-if)#exit

This ACL denies TCP only on port 23 — all other protocols (UDP, ICMP, other TCP ports) from the Guest VLAN are permitted by the final permit ip any any. The keyword ip in the permit rule means "all IP protocols" — it is the extended ACL equivalent of permit any in a standard ACL. Without this final permit, the implicit deny all would block all Guest traffic.

Numbered Extended ACL — Single Host, Specific Port

! ── Deny SSH (TCP/22) from one specific host to one server
NetsTuts_R1(config)#access-list 110 deny tcp host 192.168.20.50 host 192.168.30.10 eq 22
NetsTuts_R1(config)#access-list 110 permit ip any any

Both host keywords replace the IP + wildcard pairs — host 192.168.20.50 is shorthand for 192.168.20.50 0.0.0.0 and host 192.168.30.10 is shorthand for 192.168.30.10 0.0.0.0. The rule matches exactly one source and exactly one destination.

4. Step 2 — Named Extended ACL: GUEST-POLICY

The GUEST-POLICY ACL consolidates all Guest VLAN filtering into one named ACL. Multiple use cases are handled in a single policy — the rule order ensures the most specific rules appear before broader ones:

! ── Remove numbered ACL (replacing with named) ───────────
NetsTuts_R1(config)#no access-list 110

! ── Named extended ACL for Guest VLAN ────────────────────
NetsTuts_R1(config)#ip access-list extended GUEST-POLICY
NetsTuts_R1(config-ext-nacl)#remark Guest VLAN outbound policy — applied inbound Gi0/2

! ── Use Case 1: Block Telnet to any destination ──────────
NetsTuts_R1(config-ext-nacl)#10 deny tcp 192.168.20.0 0.0.0.255 any eq 23 log

! ── Use Case 2: Permit HTTP and HTTPS to Web Server only ─
NetsTuts_R1(config-ext-nacl)#20 permit tcp 192.168.20.0 0.0.0.255 host 192.168.30.10 eq 80
NetsTuts_R1(config-ext-nacl)#30 permit tcp 192.168.20.0 0.0.0.255 host 192.168.30.10 eq 443

! ── Use Case 3: Deny ICMP echo from Guest to Server VLAN ─
NetsTuts_R1(config-ext-nacl)#40 deny icmp 192.168.20.0 0.0.0.255 192.168.30.0 0.0.0.255 echo

! ── Permit all other IP traffic from Guest ───────────────
NetsTuts_R1(config-ext-nacl)#50 permit ip 192.168.20.0 0.0.0.255 any

! ── Implicit deny catches everything else ────────────────
NetsTuts_R1(config-ext-nacl)#exit

! ── Apply inbound on Gi0/2 — close to Guest source ───────
NetsTuts_R1(config)#interface GigabitEthernet0/2
NetsTuts_R1(config-if)#ip access-group GUEST-POLICY in
NetsTuts_R1(config-if)#exit

Rule order matters here: rule 10 (deny Telnet) must come before rule 50 (permit ip any) — otherwise all Guest TCP traffic including Telnet would be permitted by rule 50 first. Rules 20 and 30 explicitly permit HTTP and HTTPS to the web server — all other TCP destinations for Guest are implicitly denied by the final permit ip not covering TCP to other servers (TCP to non-.30.10 destinations falls through to the implicit deny). The log on rule 10 records every Telnet attempt in syslog.

5. Step 3 — Named Extended ACL: STAFF-POLICY

The STAFF-POLICY ACL blocks FTP (TCP ports 20 and 21) from Staff hosts to the FTP server while permitting all other Staff traffic. Staff should not be sending unauthorised files to the FTP server — only the IT team's dedicated IP range should have FTP access:

NetsTuts_R1(config)#ip access-list extended STAFF-POLICY
NetsTuts_R1(config-ext-nacl)#remark Staff VLAN policy — applied inbound Gi0/1

! ── Block FTP data and control to FTP Server ─────────────
NetsTuts_R1(config-ext-nacl)#10 deny tcp 192.168.10.0 0.0.0.255 host 192.168.30.11 eq 21
NetsTuts_R1(config-ext-nacl)#20 deny tcp 192.168.10.0 0.0.0.255 host 192.168.30.11 eq 20

! ── Permit IT team (10.x.x.x) FTP access to FTP Server ──
NetsTuts_R1(config-ext-nacl)#15 permit tcp host 192.168.10.50 host 192.168.30.11 range 20 21

! ── Permit all other Staff traffic ───────────────────────
NetsTuts_R1(config-ext-nacl)#30 permit ip 192.168.10.0 0.0.0.255 any

NetsTuts_R1(config-ext-nacl)#exit

! ── Apply inbound on Gi0/1 — close to Staff source ───────
NetsTuts_R1(config)#interface GigabitEthernet0/1
NetsTuts_R1(config-if)#ip access-group STAFF-POLICY in
NetsTuts_R1(config-if)#exit

NetsTuts_R1(config)#end
NetsTuts_R1#wr
Building configuration...
[OK]
NetsTuts_R1#

Sequence number 15 was inserted between rules 10 and 20 to permit the IT admin (192.168.10.50) FTP access to the FTP server — using range 20 21 to cover both FTP data and FTP control ports in a single rule. Note how the IT admin permit (seq 15) comes between the general deny for port 21 (seq 10) and port 20 (seq 20) — this works because the IT admin's specific permit at seq 15 is evaluated before the broader deny at seq 20 for port 20. After verifying the ACL save the configuration with write memory.

6. Step 4 — Controlling ICMP Traffic

ICMP filtering is more nuanced than TCP/UDP — ICMP has no port numbers, but it has type/code values. IOS supports named ICMP types in ACL rules, enabling precise control over which ICMP messages are permitted versus blocked:

NetsTuts_R1(config)#ip access-list extended ICMP-POLICY
NetsTuts_R1(config-ext-nacl)#remark ICMP control policy

! ── Permit ping from NOC (Network Operations Centre) ─────
NetsTuts_R1(config-ext-nacl)#10 permit icmp host 192.168.10.100 any echo
NetsTuts_R1(config-ext-nacl)#20 permit icmp host 192.168.10.100 any echo-reply

! ── Permit traceroute replies (unreachable messages) ─────
NetsTuts_R1(config-ext-nacl)#30 permit icmp any any unreachable
NetsTuts_R1(config-ext-nacl)#40 permit icmp any any time-exceeded

! ── Deny all other ICMP (block ping from untrusted hosts)
NetsTuts_R1(config-ext-nacl)#50 deny icmp any any echo log
NetsTuts_R1(config-ext-nacl)#60 deny icmp any any echo-reply log

! ── Permit all non-ICMP IP traffic ───────────────────────
NetsTuts_R1(config-ext-nacl)#70 permit ip any any
NetsTuts_R1(config-ext-nacl)#exit

This ACL permits ping only from the NOC host (192.168.10.100) while blocking it from all other sources. ICMP unreachable and time-exceeded messages are permitted globally — these are required for traceroute to function and for TCP applications to receive "destination unreachable" notifications. Blocking all ICMP would break traceroute, Path MTU Discovery, and some application error handling.

Common ICMP Type Keywords

Keyword	ICMP Type	Description	Block Impact
`echo`	Type 8	Ping request — sent by the source	Blocks outbound ping initiation
`echo-reply`	Type 0	Ping reply — sent by the destination	Blocks ping responses — source gets no reply
`unreachable`	Type 3	Destination unreachable — network/host/port not reachable	Blocks error messages — applications may hang waiting for response
`time-exceeded`	Type 11	TTL expired — used by traceroute	Blocks traceroute from working
`redirect`	Type 5	Router redirects — tells host to use a better next-hop	Prevents routing optimisation — generally safe to block

7. Step 5 — The `established` Keyword (Stateless TCP Inspection)

Extended ACLs are stateless — they evaluate each packet independently without tracking connection state. This creates a challenge: if you block inbound TCP traffic to protect internal hosts, you also block the return traffic for outbound connections your hosts initiate. The established keyword provides a partial solution — it matches TCP packets that have the ACK or RST flag set, which are characteristics of return traffic from an already-established connection:

! ── Applied on WAN interface (Gi0/0) INBOUND ─────────────
! ── Blocks unsolicited inbound TCP but allows return traffic
NetsTuts_R1(config)#ip access-list extended WAN-INBOUND
NetsTuts_R1(config-ext-nacl)#remark WAN inbound policy — stateless return traffic

! ── Permit TCP return traffic (ACK or RST flag set) ──────
NetsTuts_R1(config-ext-nacl)#10 permit tcp any any established

! ── Permit ICMP unreachable and time-exceeded (needed) ───
NetsTuts_R1(config-ext-nacl)#20 permit icmp any any unreachable
NetsTuts_R1(config-ext-nacl)#30 permit icmp any any time-exceeded

! ── Permit inbound traffic to the Web Server (public-facing)
NetsTuts_R1(config-ext-nacl)#40 permit tcp any host 203.0.113.10 eq 80
NetsTuts_R1(config-ext-nacl)#50 permit tcp any host 203.0.113.10 eq 443

! ── Deny everything else inbound from WAN ─────────────────
NetsTuts_R1(config-ext-nacl)#60 deny ip any any log
NetsTuts_R1(config-ext-nacl)#exit

NetsTuts_R1(config)#interface GigabitEthernet0/0
NetsTuts_R1(config-if)#ip access-group WAN-INBOUND in
NetsTuts_R1(config-if)#exit

Rule 10 (permit tcp any any established) allows TCP packets with ACK or RST flags — these are responses to outbound connections your internal hosts initiated. New inbound TCP connections (SYN only, no ACK) do not match established and fall through to the deny at rule 60. This provides basic inbound protection while keeping outbound-initiated sessions working. For true stateful inspection (tracking full connection tables), a firewall with Zone-Based Policy Firewall (ZPF) is required — established is a lightweight approximation. See Zone-Based Firewall Basics for the full stateful solution.

established vs stateful inspection: established only checks for ACK/RST flags — a crafted packet with the ACK flag set can bypass it without a real connection. True stateful firewalls track the full TCP three-way handshake state. For CCNA purposes, established is the IOS solution for permitting return traffic in an inbound ACL on the WAN interface.

8. Verification

show ip access-lists GUEST-POLICY

NetsTuts_R1#show ip access-lists GUEST-POLICY
Extended IP access list GUEST-POLICY
    10 deny tcp 192.168.20.0 0.0.0.255 any eq telnet log (17 matches)
    20 permit tcp 192.168.20.0 0.0.0.255 host 192.168.30.10 eq www (284 matches)
    30 permit tcp 192.168.20.0 0.0.0.255 host 192.168.30.10 eq 443 (156 matches)
    40 deny icmp 192.168.20.0 0.0.0.255 192.168.30.0 0.0.0.255 echo (8 matches)
    50 permit ip 192.168.20.0 0.0.0.255 any (621 matches)

Match counters confirm the ACL is active and filtering correctly. Rule 10 has blocked 17 Telnet attempts from Guest hosts — each generated a syslog message. Rules 20 and 30 show 440 combined HTTP/HTTPS connections permitted to the web server. Rule 40 has blocked 8 ping attempts from Guest to the Server VLAN. Rule 50 has permitted 621 other packets (DNS queries, NTP, etc.) from Guest.

show ip access-lists STAFF-POLICY

NetsTuts_R1#show ip access-lists STAFF-POLICY
Extended IP access list STAFF-POLICY
    10 deny tcp 192.168.10.0 0.0.0.255 host 192.168.30.11 eq ftp (0 matches)
    15 permit tcp host 192.168.10.50 host 192.168.30.11 range ftp-data ftp (4 matches)
    20 deny tcp 192.168.10.0 0.0.0.255 host 192.168.30.11 eq ftp-data (0 matches)
    30 permit ip 192.168.10.0 0.0.0.255 any (1247 matches)

Rules 10 and 20 show 0 matches — because rule 15 is catching the IT admin's FTP traffic (4 matches) before it reaches rule 20. For all non-IT-admin Staff FTP attempts, rule 10 would match (port 21 first). The 0 matches on rule 20 confirm no FTP data connections from unauthorised Staff have been attempted yet.

show ip interface — Verify ACL Applied

NetsTuts_R1#show ip interface GigabitEthernet0/2
GigabitEthernet0/2 is up, line protocol is up
  Internet address is 192.168.20.1/24
  Inbound  access list is GUEST-POLICY
  Outgoing access list is not set
  ...

NetsTuts_R1#show ip interface GigabitEthernet0/1
GigabitEthernet0/1 is up, line protocol is up
  Internet address is 192.168.10.1/24
  Inbound  access list is STAFF-POLICY
  Outgoing access list is not set
  ...

debug ip packet — Live Per-Packet ACL Trace

! ── CAUTION: high CPU on busy routers — use with ACL filter
! ── Create a debug ACL to limit output to one source ─────
NetsTuts_R1(config)#access-list 199 permit ip host 192.168.20.10 any
NetsTuts_R1(config)#end
NetsTuts_R1#debug ip packet 199 detail
IP packet debugging is on (detailed) for access list 199

IP: s=192.168.20.10 (GigabitEthernet0/2), d=192.168.30.10, len 44,
    access denied
IP: s=192.168.20.10 (GigabitEthernet0/2), d=192.168.30.10, len 44,
    input feature, TCP Src=49512, Dst=80, ACL GUEST-POLICY, permitted

NetsTuts_R1#undebug all

debug ip packet [ACL-number] detail shows live per-packet ACL decisions. The output confirms packets from 192.168.20.10 to the web server on port 80 are being permitted by GUEST-POLICY, while other packets are denied. Always use a filter ACL with debug to limit output to a specific source — unfiltered debug ip packet on a busy router will flood the console. Disable immediately after testing: undebug all.

Verification Command Summary

Command	What It Shows	Primary Use
`show ip access-lists [name/number]`	All ACL rules with match counters — protocol, port, source, destination, hits	Primary verification — confirm correct rules are matching expected traffic
`show ip interface [int]`	Inbound and outbound ACL name applied to interface	Confirm ACL is applied to the correct interface and direction
`clear ip access-list counters [name]`	Resets match counters — rules remain unchanged	Reset counters before a test to get clean baseline data
`show running-config \| section access-list`	Complete ACL config — all rules, sequence numbers, remarks	Audit full ACL configuration including rule order
`debug ip packet [acl] detail`	Real-time per-packet ACL decisions — permit/deny with source, dest, protocol, port	Deep troubleshooting — confirm specific packet treatment. Always filter with ACL number
`show ip access-lists` (no name)	All ACLs on the router — standard and extended — with all match counters	Full ACL audit across all policies on the device

9. Troubleshooting Extended ACL Issues

Problem	Symptom	Cause	Fix
Intended traffic being blocked	HTTP to web server fails from Guest — but ACL has `permit tcp ... eq 80`	A deny rule earlier in the ACL matches before the permit. Or the ACL is applied in the wrong direction — outbound instead of inbound	Check `show ip access-lists` match counters — which rule is incrementing? Verify direction with `show ip interface`. Use `debug ip packet [filter] detail` to trace the packet decision
ACL blocks established return traffic	Internal hosts can initiate connections but receive no replies — outbound works but inbound ACL on WAN drops return packets	Inbound ACL on WAN interface lacks `permit tcp any any established` — return TCP traffic (ACK flag) is dropped by the deny rule	Add `permit tcp any any established` as the first rule in the inbound WAN ACL. This permits TCP packets with ACK/RST flags which are return traffic from outbound sessions
Traceroute broken but ping works	Traceroute shows * * * for all hops — no ICMP time-exceeded messages returning	ACL is blocking `icmp time-exceeded` messages — required for traceroute to display intermediate hops	Add `permit icmp any any time-exceeded` to the ACL. Also add `permit icmp any any unreachable` to support Path MTU Discovery and destination-unreachable notifications
FTP control works but data transfer fails	FTP login succeeds (port 21) but file transfer hangs or fails (port 20)	ACL permits port 21 (FTP control) but blocks port 20 (FTP data). Both ports must be permitted. In active FTP, the server initiates the data connection — `established` may not help here	Use `range 20 21` in the ACL to permit both FTP ports in one rule. Consider switching to passive FTP where the client initiates both connections (data channel uses ephemeral port)
ACL applied but no match counters incrementing	`show ip access-lists` shows all counters at 0 despite active traffic	ACL applied to wrong interface, wrong direction, or traffic takes a different path not passing through the ACL interface	Verify with `show ip interface [int]` — confirm ACL name appears. Trace the actual traffic path with `show ip route [dest]` to confirm which interface traffic uses
OSPF adjacency drops after extended ACL applied	OSPF neighbours drop on an interface where an extended ACL was applied	ACL lacks an explicit `permit ospf any any` or `permit ip host [neighbour] any` rule — OSPF Hellos (IP protocol 89, multicast 224.0.0.5/6) are dropped by the implicit deny	Add `permit ospf any any` before any deny rules. Alternatively permit the OSPF neighbour source: `permit ip host [neighbour-IP] any`. Verify adjacency recovers with `show ip ospf neighbor`. See Troubleshooting ACL Misconfigurations and OSPF Configuration

Key Points & Exam Tips

Extended ACLs match on up to four criteria: source IP, destination IP, protocol (tcp/udp/icmp/ip/ospf), and port number (eq/neq/lt/gt/range). All specified criteria must match for the rule to fire.
Extended ACLs should be placed close to the source — they specify the destination, so dropping traffic at the source prevents it from wasting bandwidth across the network. This is the opposite of standard ACL placement.
The protocol keyword ip matches all IP protocols — use it in the final permit rule as the equivalent of "allow everything else." Use tcp, udp, or icmp for specific protocol filtering.
Port operators: eq (exactly), neq (all except), lt (below), gt (above), range [start] [end] (inclusive). Ports can be named (eq www, eq ssh) or numbered (eq 80, eq 22).
The established keyword matches TCP packets with ACK or RST flags — used in inbound WAN ACLs to permit return traffic from outbound sessions without allowing unsolicited inbound connections.
Always permit icmp unreachable and icmp time-exceeded — blocking them breaks traceroute and Path MTU Discovery even when other ICMP is denied.
When filtering FTP, both TCP/21 (control) and TCP/20 (data) must be covered. Use range 20 21 in a single rule to handle both. Active FTP data connections are server-initiated — established alone will not help.
OSPF and EIGRP can be explicitly permitted in extended ACLs using the ospf and eigrp protocol keywords — more precise than permitting by source IP since it matches the routing protocol specifically regardless of source address.
show ip access-lists match counters are the primary verification tool — confirm traffic is hitting the expected rules and counters are incrementing. Use clear ip access-list counters [name] to reset before testing.
On the CCNA exam: know extended ACL number ranges (100–199, 2000–2699), the full syntax order (permit/deny + protocol + src + dst + port), placement near source, the established keyword, and how to read extended ACL output from show ip access-lists.

Next Steps: Extended ACLs provide per-protocol and per-port filtering. For protecting router management access with a simple source-based ACL, revisit Standard ACL Configuration. For securing remote access sessions that the ACL protects, see SSH Configuration and SSH Overview. For verifying denied packet log entries generated by the log keyword, review show logging. For full stateful firewall functionality beyond the established keyword, see Zone-Based Firewall Basics. For troubleshooting ACL misconfigurations see Troubleshooting ACL Misconfigurations. For using ACLs in NAT/PAT context see Dynamic NAT & PAT and Static NAT Configuration.

TEST WHAT YOU LEARNED

1. Why should extended ACLs be placed close to the source rather than close to the destination?

A. Extended ACLs can only be applied inbound — and inbound is always closest to the source B. Extended ACLs specify both source and destination — dropping traffic at the source prevents it from consuming bandwidth across the entire network path. Standard ACLs only specify source, so they must be placed near the destination to avoid over-blocking C. Routers process inbound ACLs before making routing decisions — placing extended ACLs near the source ensures faster processing D. Extended ACLs cannot be applied outbound — only inbound is supported

Correct answer is B. Placement rules are determined by the filtering capability of the ACL type. Standard ACLs only match source IP — placing them near the source would block the source from all destinations (too broad). Extended ACLs specify both source and destination — they can safely be placed near the source because unwanted traffic is dropped early, saving bandwidth across all intermediate links. If an extended ACL on R1 denies Guest TCP/80 to server A, that traffic is dropped at R1's input and never traverses the R1→R2 link. Placed near the destination (R2), the traffic would still consume the R1→R2 bandwidth before being dropped.

2. An extended ACL contains: `deny tcp 192.168.20.0 0.0.0.255 any eq 23` followed by `permit ip any any`. A Telnet packet from 192.168.20.50 to 10.0.0.1 arrives. What happens?

A. The packet is permitted — permit ip any any matches all protocols including TCP/23 B. Both rules match — the router picks the most specific rule (deny), so the packet is dropped C. The packet is permitted because 10.0.0.1 is not in the deny rule's destination field D. Rule 1 (deny tcp ... eq 23) matches first — source 192.168.20.50 is in 192.168.20.0/24 (matches wildcard 0.0.0.255), protocol is TCP, destination is any, and port is 23. First match wins — packet is dropped. The permit ip any any rule is never evaluated

Correct answer is D. The first rule matches all four criteria: (1) source 192.168.20.50 falls within 192.168.20.0 with wildcard 0.0.0.255, (2) protocol is TCP, (3) destination is "any" which matches 10.0.0.1, and (4) destination port is 23 (Telnet). All criteria match — first-match processing stops here and the packet is dropped. The permit ip any any rule is only reached if the first rule does not match. A Telnet packet from 192.168.20.50 would never reach the permit rule. A non-Telnet packet from the same source would miss rule 1 (wrong port) and be permitted by rule 2.

3. What does the `established` keyword match in a TCP extended ACL rule, and what is its primary use case?

A. Matches TCP packets with the ACK or RST flag set — used in inbound WAN ACLs to permit return traffic from outbound TCP sessions without allowing unsolicited new inbound connections (which start with SYN only, no ACK) B. Matches only TCP sessions that have completed a full three-way handshake — provides true stateful inspection C. Matches any packet that belongs to a session already listed in the NAT translation table D. Matches TCP sessions that have been active for more than 60 seconds — filters out short-lived port scans

Correct answer is A. The established keyword is a stateless approximation — it checks for the presence of the ACK bit (or RST bit) in the TCP header. All TCP packets after the initial SYN carry the ACK flag (SYN-ACK, ACK, data packets). A new inbound connection attempt starts with just SYN (no ACK), so it does not match established. This allows return traffic from outbound sessions (which have ACK set) while blocking new inbound TCP connection attempts. It is not true stateful inspection — a crafted TCP packet with the ACK flag set can bypass it. For full stateful inspection, Cisco's Zone-Based Policy Firewall (ZPF) maintains connection state tables.

4. An ACL permits FTP control with `permit tcp any host 192.168.30.11 eq 21` but FTP file transfers fail. No other rules block port 20. What is missing?

A. FTP uses UDP for data transfer — add a permit udp any host 192.168.30.11 eq 20 rule B. The ACL needs a permit ip any any established rule before the FTP permit C. Port 20 (FTP data) must also be explicitly permitted — FTP uses TCP/21 for control (login, commands) and TCP/20 for data transfer (actual file content). Add permit tcp any host 192.168.30.11 eq 20 or replace with range 20 21 D. FTP data uses ephemeral ports above 1024 — add permit tcp any host 192.168.30.11 gt 1023

Correct answer is C. FTP uses two separate TCP connections: the control channel on port 21 handles authentication, directory listing commands, and transfer initiation. The data channel on port 20 (in active mode) handles the actual file content transfer. An ACL that only permits port 21 allows login and commands but blocks the data channel — the user can log in and list files but any file transfer hangs or fails. The fix is to permit port 20 as well, either with a separate rule or using range 20 21 in a single rule. Note: in passive FTP mode, the data channel uses an ephemeral port negotiated during the control session — this is why passive FTP often requires permit tcp any host [server] gt 1023.

5. What is the difference between `deny icmp any any` and `deny icmp any any echo` in an extended ACL?

A. They are identical — echo is the default ICMP type and applies when no type is specified B. deny icmp any any only blocks IPv4 ICMP — deny icmp any any echo also blocks ICMPv6 C. deny icmp any any echo only matches outbound pings — deny icmp any any matches all ICMP in both directions D. deny icmp any any blocks ALL ICMP types — including echo-reply, unreachable, and time-exceeded. This breaks traceroute and Path MTU Discovery. deny icmp any any echo only blocks ICMP type 8 (ping requests) — echo-reply, unreachable, and time-exceeded remain permitted, keeping traceroute and error messages functional

Correct answer is D. This distinction is critical for network operation. deny icmp any any without a type specifier blocks every ICMP message — ping requests, ping replies, destination unreachable messages, TTL expired messages, and redirect messages. Blocking ICMP unreachable and time-exceeded breaks traceroute (no TTL-expired responses), breaks Path MTU Discovery (no fragmentation-needed responses), and prevents TCP applications from receiving "host unreachable" notifications. deny icmp any any echo only blocks ICMP type 8 (ping initiation) — the necessary operational messages remain functional. Best practice: deny only echo and echo-reply to block ping while explicitly permitting unreachable and time-exceeded.

6. An OSPF adjacency drops after applying an extended ACL inbound on an interface. The ACL has `permit tcp any any` and `deny ip any any`. Why did OSPF break?

A. OSPF uses IP protocol 89 — neither TCP nor UDP. The permit tcp any any rule does not match OSPF packets. OSPF Hellos fall through to deny ip any any and are dropped. Fix: add permit ospf any any before the deny rule B. OSPF uses UDP/89 — add permit udp any any eq 89 to fix C. OSPF Hellos use port 520 — add permit udp any any eq 520 D. OSPF is blocked by permit tcp because TCP and OSPF share protocol number 6

Correct answer is A. OSPF is an IP routing protocol that runs directly over IP — it uses protocol number 89, not TCP (6) or UDP (17). OSPF packets have no port numbers. The ACL rule permit tcp any any matches only TCP — OSPF packets do not match it. These OSPF Hello packets fall through the ACL to the deny ip any any rule, which blocks them. The adjacency drops when Hellos stop arriving. The fix is to add permit ospf any any before any deny rules — this explicitly permits OSPF (protocol 89) packets. Alternatively use permit ip host [neighbour-IP] any to permit all traffic from the OSPF neighbour's source address.

7. Which of the following ACL rules correctly permits HTTP and HTTPS traffic from any source to a web server at 192.168.30.10 in a single rule?

A. permit tcp any host 192.168.30.10 eq 80 443 B. permit tcp any host 192.168.30.10 range 80 and 443 C. Two separate rules are required: permit tcp any host 192.168.30.10 eq 80 and permit tcp any host 192.168.30.10 eq 443. The eq operator only accepts one port number — multiple discrete ports require separate rules. range covers contiguous ranges only (80–443 would include hundreds of unwanted ports) D. permit tcp any host 192.168.30.10 eq www https

Correct answer is C. The eq operator accepts exactly one port number or named port. You cannot write eq 80 443 — IOS will reject this syntax. The range operator covers contiguous port ranges (e.g., range 20 21 for FTP) — using range 80 443 would permit ports 80 through 443 (364 ports), far more than intended. For two non-contiguous ports like 80 and 443, the correct approach is two separate permit rules — one for each port. In a named ACL, these would be assigned different sequence numbers (e.g., 20 for port 80 and 30 for port 443).

8. An extended ACL on R1's Gi0/2 (inbound) blocks Guest from reaching the Server VLAN. A Guest host at 192.168.20.10 pings the web server at 192.168.30.10 — the ping fails as expected. But a Staff host at 192.168.10.10 (on Gi0/1) also cannot reach the web server. Why?

A. The ACL on Gi0/2 inbound also filters traffic from Gi0/1 — all inbound ACLs apply globally B. The GUEST-POLICY ACL's final rule is deny ip any any instead of permit ip any any — when Staff traffic exits through Gi0/2 toward the servers (outbound), the ACL also applies outbound on Gi0/2 and blocks it, OR there is a separate issue with routing/ACL on Gi0/1 C. Extended ACLs block all traffic from all VLANs when applied to any interface — only standard ACLs are VLAN-specific D. The ACL is applied to both inbound and outbound on Gi0/2 simultaneously — inbound ACLs automatically mirror to outbound

Correct answer is B. An ACL applied inbound on Gi0/2 only filters packets arriving on Gi0/2 — it has no effect on packets arriving on Gi0/1 (Staff VLAN). Staff traffic from Gi0/1 is not filtered by the Gi0/2 inbound ACL. If Staff cannot reach servers, the problem is separate: either the ACL final rule on GUEST-POLICY is deny ip any any (not permit ip any any) and it is also applied outbound on Gi0/2 where Staff traffic exits toward the servers, or there is an ACL on Gi0/1 or a routing issue. Check show ip interface Gi0/1 and show ip interface Gi0/2 to see which ACLs are active in which direction on each interface.

9. What does the rule `permit tcp 192.168.10.0 0.0.0.255 192.168.30.0 0.0.0.255 range 1024 65535` match?

A. All TCP traffic from the 192.168.10.0/24 subnet to the 192.168.30.0/24 subnet on any port B. TCP traffic where the source port is between 1024–65535 from 192.168.10.0/24 to 192.168.30.0/24 C. TCP traffic from 192.168.10.0/24 to 192.168.30.0/24 on system ports only (below 1024) D. TCP traffic from 192.168.10.0/24 to any host in 192.168.30.0/24 where the destination port is between 1024 and 65535 — this matches ephemeral/dynamic ports. When a port operator follows the destination address, it matches the destination port. Used to permit return traffic to high-numbered client source ports

Correct answer is D. In extended ACL syntax, port operators after the source address apply to the source port, and port operators after the destination address apply to the destination port. In this rule, range 1024 65535 appears after the destination wildcard (192.168.30.0 0.0.0.255) — so it filters on the destination port. This matches TCP packets going to ports 1024–65535 on hosts in 192.168.30.0/24. This pattern is commonly used to permit return traffic to ephemeral (client-assigned) ports when a server in 192.168.30.0/24 is responding to requests initiated from 192.168.10.0/24. The source port in this rule has no restriction — any source port is matched.

10. An engineer needs to block all traffic from the Guest VLAN (192.168.20.0/24) to the Server VLAN (192.168.30.0/24) while allowing all other Guest traffic. Which extended ACL and placement correctly achieves this with minimum configuration?

access-list 100 deny ip 192.168.20.0 0.0.0.255 192.168.30.0 0.0.0.255
access-list 100 permit ip any any
Applied outbound on R2 Gi0/1 (close to Server VLAN destination)

access-list 100 deny ip any 192.168.30.0 0.0.0.255
access-list 100 permit ip any any
Applied inbound on R1 Gi0/2 (Guest interface)

access-list 100 deny ip 192.168.20.0 0.0.0.255 192.168.30.0 0.0.0.255
access-list 100 permit ip any any
Applied inbound on R1 Gi0/2 (Guest interface — close to source)

access-list 1 deny 192.168.20.0 0.0.0.255
access-list 1 permit any
Applied outbound on R2 Gi0/1 (Server VLAN interface)

Correct answer is C. This correctly uses an extended ACL (number 100) with both source and destination specified, placed close to the source (inbound on R1 Gi0/2 — the Guest VLAN interface). Option A has correct ACL rules but wrong placement — outbound on the server-side is the standard placement but extended ACLs should go near the source to save bandwidth. Option B's ACL (deny ip any 192.168.30.0) would block ALL sources to the Server VLAN, not just Guest — collateral damage to Staff traffic. Option D uses a standard ACL (number 1) which cannot specify a destination — it would block Guest from all destinations, not just the Server VLAN. Option C: right ACL type, right rules, right placement.

Back to Home