Configure Network ACLs Across Platforms

This skill configures Network Access Control Lists across Cisco IOS/NX-OS, AWS VPC NACLs, Juniper, and other appliances - design principles, traffic filtering, security policy, and performance. Core processing logic: ACLs evaluate rules sequentially top to bottom, first match wins (an explicit deny or permit stops processing), an implicit deny-all sits at the end of every ACL, and because ACLs are stateless, return traffic needs its own explicit rules. Rule types are named directly - Standard ACLs (source IP only, ranges 1-99/1300-1999), Extended ACLs (source/dest IP, ports, protocols, ranges 100-199/2000-2699), Named ACLs (flexible, support comments), and Reflexive ACLs (basic stateful filtering).

Use it when traffic filtering needs deliberate rule ordering and layered security across network tiers, not a flat single-purpose access list.

ip access-list extended CORP_TO_DMZ
 remark === Allow essential services ===
 permit tcp 192.168.10.0 0.0.0.255 10.0.100.0 0.0.0.255 eq 80
 permit tcp 192.168.10.0 0.0.0.255 10.0.100.0 0.0.0.255 eq 443
 permit tcp 192.168.10.0 0.0.0.255 10.0.100.0 0.0.0.255 eq 22
 remark === Deny and log suspicious activity ===
 deny ip any any log

Advanced Cisco patterns include a time-range-scoped ACL restricting HTTP/HTTPS to business hours, and a layered security design pairing a broad edge-router filter (blocking known bad private-range sources, permitting established connections plus 80/443) with a granular internal firewall restricting database-tier access to specific MySQL/PostgreSQL ports. AWS VPC NACL configuration is shown as a CloudFormation JSON snippet - a subnet-level NetworkAcl with an inbound HTTPS rule (port 443) and a matching outbound ephemeral-port rule (1024-65535), reflecting that stateless NACLs need explicit return-traffic rules on both directions. Performance optimization orders rules by match frequency and specificity, places deny rules to block unwanted traffic early, and uses object-group network/object-group service to collapse repetitive host/port lists into a single readable, reusable rule.

Monitoring and troubleshooting use ip access-list log-update threshold to rate-limit logging, show access-lists/show ip access-lists <name> to check hit counts, and debug ip packet <acl> detail to trace live traffic matching.

Network engineers configuring ACLs across Cisco and AWS environments who need concrete rule-ordering, layered-security, and object-group patterns rather than a flat unordered rule list. Anti-patterns to avoid are named directly: shadow rules (specific rules placed after broader ones that already match), excessive logging of permitted high-volume traffic, overly broad wildcards matching unintended ranges, missing ephemeral-port return-traffic rules on stateless ACLs, and hardcoded IPs instead of object groups. The closing discipline: always test ACL changes in a lab first, implement during maintenance windows, and keep rollback procedures ready for quick recovery.