VMware ESXi and vSphere Cluster Management

Cisco Extended ACLs: Configuration, Placement, and Port-Based Filtering

Learn how Cisco IOS extended ACLs filter IPv4 traffic by source, destination, protocol, and TCP ports. Configure, apply, verify, and troubleshoot extended ACLs.

An extended access control list (ACL) is a Cisco IOS rule set for filtering IPv4 packets with detailed criteria. Unlike a standard ACL, which primarily evaluates the source IPv4 address, an extended ACL can evaluate the source address, destination address, Layer 3 protocol, and transport-layer information such as TCP or UDP ports.

Extended ACLs provide precise control, but that precision increases configuration complexity. More detailed filtering can also require additional router processing. Use clear policies, careful rule ordering, and verification tests to avoid blocking required traffic.

How Extended ACLs Differ from Standard ACLs

  • Standard ACL: Primarily matches a packet's source IPv4 address.
  • Extended ACL: Can match source and destination IPv4 addresses, IP protocols, and TCP or UDP port information.

For example, a standard ACL might allow or deny everything from one source network. An extended ACL can allow that source to reach one destination only, use TCP, and access only a particular service such as HTTP.

  • Extended ACL: Matches source address, destination address, protocol, and optional port details. It offers fine-grained filtering and is normally placed close to the traffic source.
  • Standard ACL: Matches primarily the source address. It is commonly placed close to the destination so that traffic from the source is not unintentionally blocked from other destinations.

Numbered Extended IPv4 ACLs

Numbered extended IPv4 ACLs use either of these number ranges:

  • 100–199
  • 2000–2699

A single ACL is built from ordered access control entries (ACEs). An ACE is one permit or deny rule in the list. The router evaluates the ACEs in order from top to bottom.

Extended ACL Rule Structure

A general numbered extended ACL command has this structure:

access-list <ACL_NUMBER> permit|deny <PROTOCOL> <SOURCE_ADDRESS> <SOURCE_WILDCARD> [SOURCE_PROTOCOL_INFORMATION] <DESTINATION_ADDRESS> <DESTINATION_WILDCARD> [DESTINATION_PROTOCOL_INFORMATION]
  • ACL number: Identifies the numbered ACL, such as 100.
  • permit or deny: Specifies whether matching traffic is allowed or discarded.
  • Protocol: Identifies the traffic type, such as ip, tcp, udp, or icmp.
  • Source address and wildcard mask: Identify the packet origin.
  • Destination address and wildcard mask: Identify the packet target.
  • Optional protocol information: Adds criteria such as a TCP destination port.

Wildcard Masks

A wildcard mask is a Cisco IOS matching mask. A zero bit must match the corresponding address bit, while a one bit is ignored. The wildcard mask 0.0.0.0 therefore matches one exact IPv4 address.

For example, 10.0.0.1 0.0.0.0 matches only host 10.0.0.1. A wildcard mask of 0.0.0.255 matches any host in the 10.0.0.0/24 network when paired with that network address.

Protocol and Port Matching

The protocol keyword determines what kind of packet is being matched. The keyword ip matches IP traffic broadly, including traffic carried by protocols such as TCP, UDP, and ICMP. The keyword tcp restricts the ACE to TCP traffic.

TCP and UDP ACEs can include port operators. The operator eq means “equals” and requires an exact port match. In eq 80, the destination port must be TCP port 80.

access-list 101 permit tcp 10.0.0.2 0.0.0.0 192.168.0.1 0.0.0.0 eq 80

This ACE permits TCP traffic from 10.0.0.2 to 192.168.0.1 only when the destination port is 80. HTTP is commonly associated with TCP port 80 in this example.

ACL Processing Behavior

Top-Down, First-Match Processing

The router examines an ACL from the first ACE to the last. When a packet matches an ACE, the router immediately applies that ACE's permit or deny action and stops evaluating the remaining entries. This is called first-match processing.

ACE order matters when rules overlap. A broad deny placed before a more specific permit prevents the permit from ever being reached.

access-list 100 deny ip 10.0.0.2 0.0.0.0 192.168.0.1 0.0.0.0
access-list 100 permit tcp 10.0.0.2 0.0.0.0 192.168.0.1 0.0.0.0 eq 80

In this order, all IP traffic from 10.0.0.2 to 192.168.0.1 matches the first ACE. HTTP traffic is denied before the port-specific permit can be considered.

The Implicit Deny

Every ACL has an unstated final implicit deny. Traffic that does not match an earlier ACE is discarded. Therefore, an ACL with one HTTP permit rule also blocks unmatched traffic such as ICMP and TCP connections to other ports.

Applying an Extended ACL to an Interface

Use ip access-group in interface configuration mode to attach an ACL:

interface <INTERFACE>
ip access-group <ACL_NUMBER> in|out
  • Inbound: The ACL is evaluated as traffic enters the router interface.
  • Outbound: The ACL is evaluated before traffic leaves the router interface.

An interface can have an ACL applied in a selected direction. In common Cisco IOS configurations, an interface can have one IPv4 ACL applied inbound and one applied outbound, subject to platform and software behavior.

To apply ACL 100 inbound on R1's source-side FastEthernet0/0 interface:

interface FastEthernet0/0
ip access-group 100 in

Extended ACL Placement

The standard placement recommendation is to place an extended ACL as close to the traffic source as practical. Filtering early prevents unwanted packets from crossing additional links and devices.

In the example topology, the administrator and user workstations are on the source-side LAN. Packets from those hosts enter R1 through FastEthernet0/0. Applying the ACL inbound on that interface evaluates the packets immediately as they enter R1, before they travel toward the server network.

Example 1: Permit the Administrator and Deny the User

The topology contains these hosts:

  • Administrator workstation: 10.0.0.1/24
  • User workstation: 10.0.0.2/24
  • Server: 192.168.0.1/24
  • Router R1 source-side interface: FastEthernet0/0

The policy is to allow unrestricted IP traffic from the administrator host to the server and deny all IP traffic from the user host to the server.

access-list 100 permit ip 10.0.0.1 0.0.0.0 192.168.0.1 0.0.0.0
access-list 100 deny ip 10.0.0.2 0.0.0.0 192.168.0.1 0.0.0.0

interface FastEthernet0/0
ip access-group 100 in

The wildcard mask 0.0.0.0 after each host address makes each ACE host-specific. The administrator permit appears first, followed by the user deny.

  • Traffic from 10.0.0.1 to 192.168.0.1 matches the first ACE and is permitted for IP traffic.
  • Traffic from 10.0.0.2 to 192.168.0.1 does not match the first ACE, then matches the second ACE and is denied.
  • Other traffic that does not match either entry reaches the implicit deny.

The permit must precede the deny when the policy requires the administrator to be allowed while the user is blocked. These commands represent one policy. Do not append the service-specific policy below to the same ACL unless you intentionally design the combined rule order.

Example 2: Allow Only HTTP from the User Workstation

For a separate policy, the user workstation at 10.0.0.2 may access the server at 192.168.0.1 only through HTTP on TCP destination port 80.

access-list 101 permit tcp 10.0.0.2 0.0.0.0 192.168.0.1 0.0.0.0 eq 80

interface FastEthernet0/0
ip access-group 101 in

ACL 101 contains an explicit permit for the required service. All other traffic from that host to that server is unmatched and is blocked by the implicit deny.

  • HTTP to TCP port 80: Permitted because it matches the TCP protocol, both host addresses, and destination port 80.
  • ICMP ping: Denied because ICMP does not match an ACE requiring TCP.
  • TCP port 21: Denied because the destination port is 21, not 80. Port 21 is commonly associated with FTP control traffic.

Verification and Testing

Use traffic tests from the user workstation and inspect the router's ACL counters. The counters show whether packets have matched individual ACEs.

show access-lists
show ip interface FastEthernet0/0

show access-lists displays ACL entries and match counters. show ip interface FastEthernet0/0 confirms whether an ACL is attached to the interface and identifies its inbound or outbound direction.

For the HTTP-only policy, test the following from 10.0.0.2:

  • Ping 192.168.0.1 to generate ICMP traffic.
  • Attempt a TCP session to 192.168.0.1 on port 21.
  • Open an HTTP connection to 192.168.0.1 on port 80.

Expected results:

  • ICMP echo traffic is denied.
  • TCP port 21 is denied.
  • TCP port 80 is permitted, assuming the server is reachable and the web service is running.

Web-Server Filtering Test Results

  • Ping to 192.168.0.1: Protocol ICMP; expected result denied; reason: it does not match the TCP/80 permit.
  • TCP connection to 192.168.0.1:21: Protocol TCP, destination port 21; expected result denied; reason: the exact port requirement is 80.
  • HTTP connection to 192.168.0.1:80: Protocol TCP, destination port 80; expected result permitted; reason: it matches the complete ACE.

Troubleshooting Extended ACLs

The Intended Permitted Flow Is Blocked

  • A broader deny may appear before the permit ACE.
  • A source or destination wildcard mask may not match the intended host.
  • The ACL may be attached to the wrong interface or direction.
  • The permitted TCP destination port may be incorrect.

Review the ACE order and counters with show access-lists. Confirm the attachment and direction with show ip interface FastEthernet0/0. Compare the actual source address, destination address, protocol, and port with the policy.

HTTP Works but Ping and Port 21 Fail

This is the expected result for a TCP/80-only rule. ICMP does not match a TCP ACE, and TCP port 21 does not match eq 80. Check ACL counters after each test to confirm which rule handled the traffic.

Blocked Traffic Reaches the Server

  • Verify that the ACL is applied to the intended interface.
  • Verify that it is attached inbound when source-side filtering is intended.
  • Review preceding permit ACEs because first-match processing may allow the traffic.
  • Confirm that the traffic is using the expected routed path and ingress interface.

More Traffic Is Denied Than Expected

Required traffic may have no explicit permit and may therefore reach the implicit deny. A host-specific rule or port-specific rule may also be narrower than intended. Identify every required flow, validate wildcard masks and ports, add appropriately ordered permit ACEs, and retest each protocol or service.

Key Points to Remember

  • Extended IPv4 ACL numbers are 100–199 and 2000–2699.
  • Each ACL consists of ordered permit and deny ACEs.
  • Extended ACLs can match source and destination addresses, protocols, and ports.
  • The router uses top-down, first-match processing.
  • An implicit deny blocks traffic that matches no explicit permit.
  • Place extended ACLs close to the source when practical.
  • Use ip access-group to apply an ACL inbound or outbound on an interface.
  • Use show access-lists and show ip interface to verify entries, counters, attachment, and direction.

Related topic: Cisco extended ACLs.