Filtering Traffic with Extended ACLs

Cisco numbered access lists rely on reserved numerical identifier ranges to distinguish their filtering capabilities. Numbers 1 to 99 define Standard ACLs, whereas numbers 100 to 199 define Extended ACLs. This numbering scheme signals to the Cisco IOS parsing engine how deeply each packet must be inspected as it traverses the router backplane.

Standard ACLs examine only the Layer 3 source IPv4 address. If you attempt to stop an accounting workstation from reaching a payroll server using a standard access list, you run into an immediate structural problem: blocking the source IP drops that workstation access to every single server, web app, and printer on that destination subnet.

Extended ACLs resolve this limitation by evaluating the full 5-tuple header structure. The router checks the Source IP, the Destination IP, the transport protocol (TCP, UDP, or ICMP), the Source Port, and the Destination Port. With an extended access list, you can allow accounting computers to access port 80 on a web server while dropping unencrypted Telnet sessions on port 23 and dropping ICMP ping discovery requests.

Placement guidelines also differ sharply between standard and extended lists. Standard ACLs must be placed as close to the traffic destination as possible to prevent accidentally dropping legitimate packets along other branches. Extended ACLs, by contrast, must be placed as close to the traffic source as possible. Filtering packets right at the ingress gateway prevents unwanted traffic from consuming bandwidth across core links or wasting router memory on unnecessary routing lookups.

An extended access list statement uses a specific sequence of parameters that define matching criteria from Layer 3 through Layer 4. Each line evaluates incoming packets against sequential conditions until a match occurs.

Consider the primary rule permitting HTTP web traffic: access-list 100 permit tcp 192.168.10.0 0.0.0.255 host 192.168.30.50 eq 80. This statement defines the list number, the action, the transport protocol, the source network with its wildcard mask, the target destination host, and the matching destination port number.

We will configure rules to allow web traffic on port 80 and secure web traffic on port 443, explicitly drop unencrypted Telnet management on port 23, drop ICMP echo requests targeting the server, and permit all other general outbound traffic.

Enter global configuration mode on the Core Router and input the sequential access list statements below.

Let us examine the parameters configured in each statement:

Creating an access list in router memory has no effect on network traffic until you explicitly bind that list to an interface using the ip access-group command. Access lists are directional: you must choose whether the list inspects traffic entering the router interface or traffic exiting the interface.

Traffic direction fundamentally changes when the packet filtering engine runs relative to the Layer 3 routing engine:

Inbound (in): Packets are inspected immediately when they arrive at the interface hardware buffers, BEFORE the router looks up the destination IP in its routing table. If a packet violates a security rule, it is dropped on arrival, saving router CPU cycles and avoiding backplane switching overhead.

Outbound (out): Packets are received, processed by the routing engine, routed across the switch fabric, and only inspected as they are queued to exit the destination interface.

Because our extended access list is designed to restrict accounting client traffic, we apply it inbound directly on the accounting default gateway interface GigabitEthernet0/0/0.

Understanding interface binding syntax and execution order:

With Extended ACL 100 bound to the gateway interface, we can test our filtering policies from Accounting Workstation (`192.168.10.10`). We must verify that authorized web traffic succeeds while unauthorized management and diagnostic traffic fails.

First, open the workstation terminal and make an HTTP request to the server by executing curl http://192.168.30.50. The router inspects the packet, identifies destination TCP port 80, matches Rule 1, and permits the connection. The server replies with an HTTP 200 OK status code.

Next, send an ICMP echo request using ping 192.168.30.50. The packet matches Rule 4 (`deny icmp`), causing the router gateway to drop the packet and return a filtering notice.

Finally, attempt to open a remote Telnet shell with telnet 192.168.30.50. The TCP SYN packet targeting port 23 matches Rule 3 (`deny tcp eq 23`) and is dropped immediately.

Reviewing the terminal verification results:

To verify how the router processes traffic in real time, return to the Core Router command line and run show access-lists 100.

Cisco IOS maintains internal hit counters for every individual statement inside an access list. Each time an arriving packet matches a statement, the router increments that rule counter by one and stops checking the rest of the list.

Examining hit counters allows administrators to confirm which rules are actively protecting the network and determine whether unwanted traffic is hitting the intended deny statements.

Analyzing the match counters in the command output:

Remember that access lists evaluate rules sequentially from top to bottom. As soon as a packet matches an entry, the router applies the action and exits the evaluation process.