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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
Use configuration commands appropriate to the platform. A representative rule is A rule such as On the ingress interface facing the user LAN, a configuration such as 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.<\/p>\n 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.<\/p>\n Inspect the policy with Use a TCP client to test the intended HTTPS connection, then attempt a disallowed flow. Inspect 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.<\/p>\n 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.<\/p>\npermit tcp 192.0.2.0 0.0.0.255 host 198.51.100.10 eq 443<\/code> within ip access-list extended USERS_TO_APP<\/code>. This permits a particular TCP flow; it does not inspect the authenticity or contents of HTTPS traffic.<\/p>\ndeny ip 192.0.2.0 0.0.0.255 any<\/code> 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.<\/p>\nApply the correct direction<\/h2>\n
ip access-group USERS_TO_APP in<\/code> filters packets as they enter the router. The words in and out are relative to the router interface, not to the final destination.<\/p>\nOrder and sequence affect results<\/h2>\n
show ip access-lists<\/code> and verify its order. Change one rule at a time and retain a working previous configuration for recovery.<\/p>\nVerify both permitted and denied flows<\/h2>\n
show ip access-lists<\/code> counters and show ip interface<\/code> for applied interface directions. Counters may vary by platform and traffic processing path.<\/p>\nKnow the limits of router ACLs<\/h2>\n