Cisco Extended ACLs: Configuration and Verification

An extended IPv4 access control list can filter Cisco IOS traffic by protocol, source and destination addresses and selected transport ports. It is more specific than a standard ACL, but still requires correct ordering, interface selection and understanding of what traffic actually passes through the router.

This example uses the RFC 5737 documentation networks 192.0.2.0/24 and 198.51.100.0/24. Adjust it to a controlled lab and the actual IOS or IOS XE feature set before applying any configuration to production.

Write the requirement before the command

Suppose user hosts in 192.0.2.0/24 should reach the HTTPS server 198.51.100.10 at TCP port 443. The lab will block other IP connections originating in the user subnet at its ingress router interface, while other interface traffic must be considered separately.

Document the traffic matrix and management requirements first. Filtering at the wrong interface can block device access or catch flows unrelated to the intended protection.

Understand source, destination and wildcard masks

A standard IPv4 ACL commonly matches source address, whereas an extended ACL can match source, destination, protocol and ports when relevant. A subnet prefix /24 corresponds to wildcard 0.0.0.255; the wildcard marks address bits that do not need to match.

The host keyword expresses one exact address. Ports such as eq 443 apply to TCP or UDP statements, not an arbitrary IP protocol match. IPv6 ACLs use distinct syntax and do not adopt IPv4 wildcard masks.

Create an extended named list

Use configuration commands appropriate to the platform. A representative rule is permit tcp 192.0.2.0 0.0.0.255 host 198.51.100.10 eq 443 within ip access-list extended USERS_TO_APP. This permits a particular TCP flow; it does not inspect the authenticity or contents of HTTPS traffic.

A rule such as deny ip 192.0.2.0 0.0.0.255 any can explicitly restrict other traffic from that subnet. After considering all other legitimate traffic entering this interface, add needed permits. The ACL’s implicit final deny blocks unmatched packets.

Apply the correct direction

On the ingress interface facing the user LAN, a configuration such as ip access-group USERS_TO_APP in filters packets as they enter the router. The words in and out are relative to the router interface, not to the final destination.

Do not apply this demonstration list blindly to an interface carrying routing or management traffic. Plan a rollback, keep administrative connectivity and test changes during a suitable maintenance window.

Order and sequence affect results

IOS processes entries in order and stops at the first match. A broad permit placed above a specific deny can prevent the deny from ever taking effect. A descriptive named list and sequence numbers help with precise changes.

Inspect the policy with show ip access-lists and verify its order. Change one rule at a time and retain a working previous configuration for recovery.

Verify both permitted and denied flows

Use a TCP client to test the intended HTTPS connection, then attempt a disallowed flow. Inspect show ip access-lists counters and show ip interface for applied interface directions. Counters may vary by platform and traffic processing path.

If a test fails, investigate routes, NAT, a host firewall and other security controls rather than assuming every problem is caused by this one ACL. Logging can assist diagnosis but excessive log statements can create operational overhead.

Know the limits of router ACLs

An extended ACL matches network attributes; it is not equivalent to a stateful next-generation firewall, malware inspection engine or application access control. Use additional identity and application-level safeguards where the threat model demands them.

Get Cisco virtual images only through licensed routes. The Cisco virtual-image licensing guide explains why importing an image into an emulator does not automatically authorize that use.

Close with a policy review

Compare the final permit/deny behavior with the original requirement and document the interface, direction, service ports and expected change. Remove obsolete entries and investigate broad exceptions.

Good ACL work is not a long command list. It is a measured access policy that can be explained, tested and safely modified.