Extended ACLs are used more than standard ACLs because of their far greater precision. Where a standard ACL can only match source address, extended ACLs check source address, destination address, protocol, and port number together — enabling filtering standard ACLs simply can’t express. An extended ACL can, for example, allow FTP traffic from a network to one specific destination while denying all other traffic, including web browsing from that same source, in a single coherent policy.
Packet Filtering Logic
Extended ACLs analyze the packet header in full: source and destination IP, protocol (TCP, UDP, ICMP, or IP as a catch-all), and port numbers where relevant. This lets a single ACL filter VoIP traffic on port 5060 differently from HTTP on port 80, even when both are heading toward the same destination.
Case Study: Securing VoIP
In an enterprise network, an extended ACL can permit SIP traffic (port 5060) from a trusted subnet specifically, while denying all other UDP traffic from that same subnet — a level of protocol- and port-specific control a standard ACL has no way to express, since it can only ever see source address.
Extended ACL Number Ranges
Extended ACLs use numbers 100 to 199, extended further by 2000 to 2699. Counting both ranges: 199 − 100 + 1 = 100 numbers in the original range, and 2699 − 2000 + 1 = 700 numbers in the extended range, for a combined total of 800 usable extended ACL numbers. The 100–199 range was historically the only option; 2000–2699 was added later and is generally preferred on modern IOS for the additional headroom it provides. Extended ACLs can also be created with names for the same manageability benefit named standard ACLs offer.
Extended ACL Syntax
Configuration follows the same two-stage pattern as standard ACLs: create the ACL, then activate it on an interface. The syntax is considerably more detailed, since it has more to match:
access-list <access-list-number> {deny | permit | remark} protocol {source source-wildcard} [operator port] {destination destination-wildcard} [operator port]- access-list-number. 100–199 or 2000–2699 for a numbered extended ACL.
- deny / permit / remark. Same meaning as in standard ACLs — deny or permit on match, remark for documentation only.
- protocol. Commonly ICMP, TCP, UDP, or the
ipkeyword, which matches any protocol. - source / source-wildcard. The sending host or network and its wildcard mask, exactly as in standard ACLs.
- destination / destination-wildcard. The packet’s destination host or network and its wildcard mask — the capability standard ACLs entirely lack.
- operator. Optional, for comparing a port:
lt,gt,eq,neq, orrange. - established. Optional, TCP-only. Matches traffic that’s part of an already-established connection — specifically, segments with the ACK or RST flag set, the same TCP mechanics covered in the three-way handshake guide.
Not every parameter is needed on every line — most real ACEs use only a handful of these fields.
Example 1: Permitting Web Browsing, Denying Everything Else
Suppose the goal is allowing web browsing only from network 192.168.2.0/24, using HTTP (port 80) and HTTPS (port 443), while also permitting the return traffic those requests generate — and denying everything else.
R3> enable
R3# configure terminal
R3(config)# access-list 101 permit tcp 192.168.2.0 0.0.0.255 any eq 443
R3(config)# access-list 101 permit tcp 192.168.2.0 0.0.0.255 any eq 80
R3(config)# access-list 102 permit tcp any 192.168.2.0 0.0.0.255 established
R3(config)# exitACL 101 permits outbound requests to port 80 and port 443 from the 192.168.2.0/24 network. ACL 102 handles the return direction, using the established keyword to permit only traffic that’s part of a connection those clients actually initiated — everything else inbound is caught by the implicit deny. Without established, clients could send requests out but would never receive the web server’s replies, since nothing would permit that return traffic back in.
Applying the ACLs to Interfaces
An ACL doesn’t filter anything until it’s linked to an interface with ip access-group. As with standard ACLs, direction matters — and extended ACLs carry an additional placement principle: because they can match destination precisely, they should be applied as close to the source as possible, the opposite of the standard-ACL guidance covered in the standard ACL configuration guide. Filtering unwanted traffic immediately at its source avoids wasting bandwidth carrying it partway across the network only to drop it later.
In this topology, Fa0/1 on R3 is the interface closest to the 192.168.2.0/24 source network. Outbound web requests leave the network through Fa0/1 heading toward the internet, and inbound return traffic from those same requests arrives back through Fa0/1. Both ACLs are applied there, matching the direction each one is meant to filter:
R3> enable
R3# configure terminal
R3(config)# interface fastethernet 0/1
R3(config-if)# ip access-group 101 in
R3(config-if)# ip access-group 102 out
R3(config-if)# exitACL 101 filters inbound traffic arriving at Fa0/1 from the 192.168.2.0/24 LAN, heading out toward the internet. ACL 102 filters outbound traffic leaving R3 through Fa0/1 back toward that same LAN, permitting only established return traffic.
Example 2: Restricting FTP While Permitting Everything Else
This ACL denies FTP traffic from the 192.168.1.0/24 subnet to a specific server, while permitting all other traffic from that subnet. FTP uses two ports — 20 for data and 21 for control — so the ACL needs to match both.
Using port name keywords:
R3(config)# access-list 103 deny tcp 192.168.1.0 0.0.0.255 host 192.168.4.2 eq ftp
R3(config)# access-list 103 deny tcp 192.168.1.0 0.0.0.255 host 192.168.4.2 eq ftp-data
R3(config)# access-list 103 permit ip any anyThe equivalent using port numbers instead of names — note that host is required before the destination address in both forms, since a destination without either host or an explicit wildcard mask isn’t valid syntax:
R3(config)# access-list 103 deny tcp 192.168.1.0 0.0.0.255 host 192.168.4.2 eq 21
R3(config)# access-list 103 deny tcp 192.168.1.0 0.0.0.255 host 192.168.4.2 eq 20Extended ACLs carry the same implicit deny any as standard ACLs, so permit ip any any is required at the end — without it, every non-FTP statement would also be silently blocked by the implicit deny, defeating the “allow everything else” intent entirely.
Apply this inbound on Fa0/1, filtering FTP traffic from the 192.168.1.0/24 LAN right as it enters the router:
R3(config)# interface fastethernet 0/1
R3(config-if)# ip access-group 103 inExample 3: Restricting Telnet to a Specific Host
This ACL denies Telnet traffic from any source to 192.168.4.2 (Server0), while permitting all other traffic. It’s configured on Router2, applied outbound on Fa0/0:
R2(config)# access-list 104 deny tcp any host 192.168.4.2 eq 23
R2(config)# access-list 104 permit ip any any
R2(config)# interface fastethernet 0/0
R2(config-if)# ip access-group 104 outThe permit ip any any statement is what keeps this ACL from blocking every other kind of traffic — without it, only the explicit Telnet-blocking statement would exist, and the implicit deny would catch everything else too, turning a narrow security rule into a total traffic blackout on that interface.
Creating Named Extended ACLs
Named extended ACLs follow the same pattern as named standard ACLs:
- Enter global configuration mode.
- Use
ip access-list extended <name>to define the name and enter named ACL configuration mode. - Enter
permit/denyconditions inside that mode. - Exit and apply the ACL to the desired interface with
ip access-group <name>. - Verify with
show access-lists <name>orshow running-config. - Save with
copy running-config startup-config. - Remove a named extended ACL with
no ip access-list extended <name>in global configuration mode.
Example: Named Version of the FTP Restriction
This is the named equivalent of Example 2 — denying the 192.168.1.0/24 LAN’s FTP access to the server while permitting everything else, applied inbound on Fa0/1 to match the numbered version exactly:
R3> enable
R3# configure terminal
R3(config)# ip access-list extended FTP_Server0_is_denied
R3(config-ext-nacl)# deny tcp 192.168.1.0 0.0.0.255 host 192.168.4.2 eq 21
R3(config-ext-nacl)# permit ip any any
R3(config-ext-nacl)# exit
R3(config)# interface fastEthernet 0/1
R3(config-if)# ip access-group FTP_Server0_is_denied in
R3(config-if)# exitVerifying Extended ACLs
Verify with show access-lists, show running-config, or show ip interface <interface> — the same core commands covered for standard ACLs, and the same techniques from the ACL statistics guide apply equally here, including the implicit deny’s invisibility unless made explicit:
R3# show access-lists 101
Extended IP access list 101
10 permit tcp 192.168.2.0 0.0.0.255 any eq 443 (12 matches)
20 permit tcp 192.168.2.0 0.0.0.255 any eq 80 (47 matches)One structural difference from standard ACLs worth knowing: extended ACLs don’t use the same internal hashing and reordering logic older standard ACL implementations sometimes applied. Statement order in the output always matches entry order exactly, and host entries are never automatically resorted ahead of range entries — what you typed is what you get, in the order you typed it. show ip interface <interface> confirms which ACL is applied and in which direction, exactly as with standard ACLs.
Editing Extended ACLs
Extended ACL editing works identically to standard ACL editing:
- Text editor. Copy the ACL out, edit it, remove the existing ACL with
no access-list <number>, and paste the corrected version back in. - Sequence numbers. Enter
ip access-list extended <name-or-number>, delete the incorrect statement withno <sequence-number>, and add the corrected one at the same sequence number. ACEs can be inserted, removed, or replaced this way without disturbing the rest of the ACL or unlinking it from its interface.
Troubleshooting Extended ACLs
- Traffic permitted on one leg but blocked on return. This almost always means the
establishedkeyword or a matching return-direction ACL is missing — check both directions were actually configured, not just the outbound request side. - FTP or other multi-port protocols only partially working. Confirm both ports are covered — FTP specifically needs both 20 and 21, and forgetting one leaves the other half of the protocol silently broken.
- A syntax error on a destination address. Confirm
hostprecedes a single destination IP, or that an explicit wildcard mask is present — a bare IP address in either the source or destination position isn’t valid extended ACL syntax. - Unexpectedly high denies after adding an explicit permit. Check statement order — a broad deny placed above a more specific permit shadows it, exactly as covered in the standard ACL configuration guide’s ordering discussion, and the same logic applies here regardless of the additional protocol and port matching.
Illustrative Scenario: FTP Half-Working After a Rule Change
Here’s a common scenario, meant to show the troubleshooting logic in action rather than describe a specific real event.
An administrator restricts FTP access from a subnet, intending to block it entirely, and adds a single statement denying port 21. Users report FTP connections still “sort of” work — the initial connection is refused as expected, but some client software behaves strangely, hanging rather than cleanly failing.
Reviewing the ACL shows only the control-port statement (eq 21) was ever added; the data-port statement (eq 20 or ftp-data) was never included. Depending on the FTP mode a client uses, blocking only the control channel can leave the data channel partially reachable or produce exactly this kind of inconsistent, half-working behavior, since FTP genuinely uses two separate ports for two separate purposes.
Adding the missing ftp-data statement resolves it, blocking both ports consistently. The lesson generalizes to any multi-port protocol: confirming a service is fully blocked (or fully permitted) means checking that every port it actually uses is covered, not just the one that’s most commonly referenced.
FAQs
What is the range of numbers for extended ACLs?
Extended ACLs use numbers 100–199 and 2000–2699, a combined total of 800 usable ACL numbers. The 2000–2699 range is generally preferred on modern IOS for the additional headroom, though which range to use ultimately depends on IOS version support and existing network conventions.
How do extended ACLs differ from standard ACLs?
Extended ACLs match source address, destination address, protocol, and port number together, while standard ACLs can only ever match source address. This lets an extended ACL express policies a standard ACL structurally can’t — like permitting FTP to one specific server while denying everything else from the same source — and is also why extended ACLs are recommended close to the source, the opposite placement guidance from standard ACLs.
What are the steps to configure an extended ACL?
Define the ACL with access-list <number> {permit|deny} <protocol> <source> <destination> [port] in global configuration mode, remembering the implicit deny means a trailing permit ip any any is usually needed unless the intent really is to block everything else. Apply it to an interface with ip access-group <number> <in|out>, generally as close to the traffic’s source as possible. Verify with show access-lists and confirm the ACL is actually seeing traffic before assuming it’s working correctly.
How can I secure VoIP traffic using extended ACLs?
Permit SIP traffic on port 5060 from a trusted subnet specifically, while denying other UDP traffic from that same source — a level of protocol- and port-specific control only extended ACLs can express. This kind of rule is a good example of why extended ACLs exist at all: a standard ACL simply has no mechanism to distinguish SIP traffic from any other traffic originating from the same source address.
What is the purpose of the established parameter in ACLs?
The established keyword, valid for TCP only, matches segments carrying the ACK or RST flag — the signature of traffic belonging to a connection that’s already open, rather than one being newly initiated. This lets a return-direction ACL permit legitimate reply traffic (a web server’s response to a client’s request, for instance) without needing to open the interface to unsolicited inbound connections generally. Without it, clients could send requests outbound but would never receive anything back, since nothing would explicitly permit the return traffic.
