Extended and named ACLs

A real-life situation

In Standard ACLs you blocked the Sales LAN from the whole server LAN. A week later the rule changes: Sales now needs the company web app on SRV1, which runs on HTTPS (TCP port 443). They should also be able to ping it. Every other kind of traffic from Sales to the server LAN, such as file sharing, must stay blocked.

A standard ACL can't do this. It only sees the source address, so it can block Sales from everything or nothing. You need a rule that says who, to where and what kind of traffic. That is an extended ACL.

What an extended ACL is

An extended ACL follows the same basic rules as a standard one: entries are checked top-down, the first match wins, and an invisible deny any ends the list. The difference is how much of the packet each entry can look at:

• the protocol (ip, tcp, udp, icmp, ospf and others),
• the source address and wildcard,
• the destination address and wildcard,
• for TCP and UDP, the source and destination ports,
• a few extras, such as the ICMP message type or log.

If ports are new to you, see Port numbers and sockets and Common ports to know.

Numbered or named

Extended ACLs can be numbered (100-199 and 2000-2699) or named. A named ACL uses a word you choose, like SALES-IN, so anyone reading the configuration can tell what it is for. Named ACLs also make editing easy, because you work inside the list and can address each line by its sequence number. Standard ACLs can be named too; the name just goes with ip access-list standard.

Why it works that way

Place extended ACLs close to the source. An extended entry names both the source and the destination, so it can sit right next to the source without blocking anything else. Dropping unwanted packets at the first router also means they never waste bandwidth on the links behind it. Compare this with a standard ACL, which goes close to the destination because it can't see where a packet is going.

ACLs are stateless. The router checks every packet on its own and keeps no memory of connections. When SRV1 replies to PC1, the reply is a brand-new packet: source 192.168.30.10, source port 443, destination 192.168.10.10. An ACL on the return path must permit it too. This ACL is inbound on the Sales side, so the replies (which leave R1 through Gi0/0) are never checked by it. Placing it this way keeps the rules simple.

How it works step by step

Every extended entry follows the same pattern. The order of the parts matters: a port written after the source applies to the source port, and a port written after the destination applies to the destination port.

Now follow one packet from PC1 to SRV1 on TCP port 445 through this list:

1. Entry 10: protocol TCP, yes. Source in 192.168.10.0/24, yes. Destination 192.168.30.10, yes. Destination port 443? No, it is 445. No match, keep going.
2. Entry 20: protocol ICMP? No, it's TCP. No match.
3. Entry 30: protocol ip covers TCP. Source and destination networks match. The action is deny, so R1 drops the packet, writes a log message and stops checking.

A ping from PC1 to SRV1 matches entry 20 (echo is the ICMP echo request). A web request to a server on another network would pass entries 10 to 30 without a match and be permitted by entry 40.

How to configure it on Cisco IOS

⚠️ Based on Cisco IOS / IOS XE documentation, not run on a lab device.

Named extended ACL

The same list, numbered

Editing with sequence numbers

Another week, another change: the web app also needs plain HTTP (TCP 80) so it can redirect browsers to HTTPS, and management has decided that ping is no longer needed. Inside the named list you can insert a line between two others and delete a single line:

This also works for numbered lists: enter ip access-list extended 110 and edit by sequence number in the same way. That is much safer than the global no access-list 110 ..., which deletes the entire list.

A full example for R1

How to verify it

R1#show ip access-lists SALES-IN
Extended IP access list SALES-IN
    10 permit tcp 192.168.10.0 0.0.0.255 host 192.168.30.10 eq 443 (214 matches)
    15 permit tcp 192.168.10.0 0.0.0.255 host 192.168.30.10 eq www (9 matches)
    30 deny ip 192.168.10.0 0.0.0.255 192.168.30.0 0.0.0.255 log (6 matches)
    40 permit ip any any (1032 matches)

R1#show ip interface GigabitEthernet0/0
GigabitEthernet0/0 is up, line protocol is up
  Internet address is 192.168.10.1/24
  ...
  Outgoing access list is not set
  Inbound  access list is SALES-IN
  ...

Then test from both sides of the rule. From PC1, the web app should load and a file share on SRV1 should fail. If you watch the console or the log buffer (show logging), each denied packet that hits entry 30 produces a log message naming the list, the source and the destination. IOS rate-limits these messages, so you won't see one for every single packet.

What goes wrong and how to troubleshoot it

When in doubt, work through the list by hand for one packet: write down its protocol, source, destination and ports, then compare with each entry from the top. That's exactly what the router does.

Common mistakes

• Port on the wrong side. permit tcp 192.168.10.0 0.0.0.255 eq 443 host 192.168.30.10 matches packets from port 443, not packets to it.
• Using ip with a port. Ports only exist for tcp and udp entries.
• Forgetting permit ip any any when the policy is "block only this". Without it, the implicit deny blocks everything else.
• Placing it far from the source. It still works, but the unwanted traffic crosses the network before being dropped.
• Mixing up direction. "In" and "out" are from the router's point of view: in is traffic entering the router through that interface.

💡 Exam tip: expect questions that give you an extended ACL and ask which packets it permits, so read each entry in order: protocol, source, source port, destination, destination port. Know that extended ACLs go close to the source, the number ranges (100-199, 2000-2699), how to insert and delete lines with sequence numbers in a named ACL, and that a packet matching nothing is denied. Common port numbers (22, 23, 53, 80, 443) are fair game.

Key takeaways

• Extended ACLs match protocol, source, destination and TCP/UDP ports.
• A port after the source is the source port; after the destination, the destination port.
• Place extended ACLs close to the source.
• Named ACLs are easier to read and edit; sequence numbers let you insert or remove single lines.
• ACLs are stateless, and the implicit deny still applies.

Check yourself