What an ACL is
An access control list is an ordered set of rules that matches traffic and applies an action such as permit or deny. ACLs are used on routers, Layer 3 switches, firewalls, and other systems for traffic filtering, infrastructure protection, routing policy, or classification.
An ACL does not understand business intent by itself. Its behavior depends on the fields it can inspect, the order of entries, the interface or feature where it is applied, and the direction in which packets are evaluated.
What a rule can match
Depending on platform and ACL type, rules may match source and destination addresses, protocols, TCP or UDP ports, ICMP types, DSCP values, or other header fields. The more specific the match, the easier it is to express least-privilege requirements.
Translate requirements into flows before writing syntax: source, destination, protocol, service, direction, and expected action.
Order and first match
Many ACL implementations evaluate entries from top to bottom and stop at the first matching rule. A broad permit placed before a specific deny can make the deny unreachable. A broad deny placed too early can block required traffic.
Design order intentionally and remember the platform's default behavior when no explicit rule matches. Many classic ACL models end with an implicit deny.
Inbound, outbound, and placement
An inbound ACL evaluates packets as they enter an interface; an outbound ACL evaluates packets before they leave. Placement determines which traffic the list sees. A correct rule set applied in the wrong direction can appear completely ineffective.
Choose a point where the policy is clear and where unwanted traffic can be stopped without accidentally affecting unrelated flows. Verify the actual forwarding path first.
Standard and extended ACLs
Traditional standard ACLs match a narrower set of fields, often source IPv4 address, while extended ACLs can include source, destination, protocol, and ports. Platform terminology varies, but the design principle is stable: use enough context to express the requirement precisely.
A more specific ACL can often be placed closer to the source because it can distinguish destinations and services without blocking everything from that source.
Wildcard masks and prefixes
Some IPv4 ACL syntaxes use wildcard masks rather than prefix lengths. A wildcard indicates which address bits must match and which may vary. It is not simply another way to display a subnet mask; its semantics are match-oriented.
Convert carefully and validate edge cases. SubnetMaster's wildcard and CIDR tools can help check values before configuration.
Stateless ACL vs stateful firewall
A stateless ACL evaluates each packet against header fields without automatically tracking the full connection state. A stateful firewall records sessions and can allow return traffic based on an established flow.
This distinction matters for bidirectional applications and dynamic behavior. An ACL can still provide strong, simple policy, but it should not be assumed to offer the same session awareness as a firewall.
Design from requirements
Start with a flow matrix, not with device syntax. Write which sources need which destinations and services, then create the minimum set of rules that expresses those requirements. Group related entries, use clear object names when supported, and avoid unnecessary any-any policy.
Consider infrastructure traffic such as routing protocols, DHCP relay, DNS, NTP, monitoring, and management so the ACL does not accidentally break the network itself.
Validation and counters
After deployment, check rule counters and logs. A rule with no matches may be unused, applied in the wrong place, shadowed by an earlier entry, or simply waiting for traffic. A rapidly increasing deny counter can explain a service failure immediately.
Test positive and negative cases. Required traffic should pass, and traffic that the policy intends to block should fail.
ACL troubleshooting
Confirm the actual path, interface, direction, address after any NAT stage, rule order, and match criteria. Inspect counters before changing policy. If a flow never reaches the ACL, the problem is elsewhere.
Packet captures on either side of the enforcement point can verify whether packets enter and leave, while logs can identify the matched rule.
ACLs and IPv6
IPv6 ACLs operate on IPv6 addresses and protocol fields, but do not copy IPv4 policy blindly. Neighbor Discovery and ICMPv6 perform essential functions, and overly broad ICMPv6 blocking can break address resolution, Path MTU Discovery, and normal operation.
Design IPv6 policy with the protocol's control traffic in mind.
Common mistakes
Common ACL mistakes include reversed source and destination, wrong wildcard mask, wrong interface or direction, broad rules shadowing specific ones, forgetting the implicit action, filtering before or after NAT incorrectly, and changing multiple rules without a rollback plan.
Use comments or descriptions where the platform supports them so the intent remains visible.
Conceptual design example
Suppose user VLANs may reach an internal application on TCP 443 and internal DNS on TCP/UDP 53, but may not initiate connections to the management subnet. Express those three requirements separately, then place the policy where all relevant user flows cross the same routed boundary.
Validate application access, DNS resolution, and the blocked management attempt, and confirm the corresponding counters.
Safe changes and rollback
ACL changes can cut off management or production traffic. Save the current configuration, review the diff, define rollback steps, and use out-of-band access for high-risk changes when available. Schedule changes appropriately for critical paths.
After the change, verify counters and the original service tests before declaring success.
Document and review an ACL
Record each rule's owner, purpose, related service, and expected lifetime. Periodically review stale entries and rules with no useful matches. Removing obsolete policy reduces complexity and the chance that future entries interact unexpectedly.
Documentation also makes security reviews faster because the business or operational reason is available beside the technical match.
Next step
Continue with VPN and IPsec to see how access policy interacts with encrypted tunnels, routing, NAT, and traffic selectors.