A network ACL (access control list) is an ordered list of permit and deny rules that a router, Layer 3 switch, firewall or cloud network applies to packets crossing an interface or subnet boundary. In network security, it is the most basic form of traffic filtering: each packet is compared with the rules from top to bottom, and the first matching rule decides whether the packet is forwarded or dropped.
Network ACLs match on header fields such as source and destination address, protocol and port number. They do not inspect application content, and in their classic form they are stateless, which makes them fast and predictable but also demands careful rule design for return traffic.
How a network ACL evaluates packets
A network ACL is evaluated sequentially, in rule order. The device compares the packet with the first entry; if all match criteria fit, the action of that entry applies and evaluation stops. If no entry matches, an implicit deny at the end drops the packet. This first-match logic means that the order of rules matters as much as their content: a broad permit placed above a specific deny makes the deny unreachable.
Each ACL is bound to an interface and a direction. An inbound ACL filters packets as they arrive, before the routing decision; an outbound ACL filters packets as they leave. Most platforms allow one ACL per interface, per direction and per protocol family, so IPv4 and IPv6 need separate lists.
Because a classic ACL is stateless, it treats every packet independently. A rule that permits outbound requests to a web server does not automatically permit the replies. The administrator must also allow the return traffic, typically by permitting the ephemeral port range used by clients, or by using an established keyword that matches TCP segments with the ACK or RST flag set.
Match criteria and ACL types
ACLs differ mainly in how many header fields they can match. Standard lists filter only by source address, extended lists add destination, protocol and ports, and named or object-based lists make large rule sets easier to maintain. The table compares the common forms.
| ACL type | Match fields | Typical placement | Typical use |
|---|---|---|---|
| Standard ACL | Source address only | Close to the destination | Simple allow lists for management access |
| Extended ACL | Source, destination, protocol, ports, flags | Close to the source | Precise filtering between subnets |
| Named ACL | Same as extended, with editable entries | Any interface | Maintainable production rule sets |
| Reflexive or dynamic ACL | Session entries created on the fly | Edge interfaces | Basic return-traffic handling |
| Cloud subnet ACL | Addresses, protocol, port ranges | Subnet boundary in a virtual network | Coarse guardrails around subnets |
Addresses are usually written as prefixes, such as 10.20.0.0/16, while some platforms use wildcard masks, the bitwise inverse of a subnet mask: 0.0.255.255 matches the same /16 range. Ports can be single values, ranges or keywords, and TCP rules can also match flags to separate new connection attempts from established traffic.
Network ACLs compared with stateful firewalls and security groups
Network ACLs sit at the simplest end of the filtering spectrum. Stateful firewalls track connections, and cloud security groups attach rules to individual workloads instead of subnets. Knowing where each fits prevents both gaps and duplicated effort.
| Control | State tracking | Rule logic | Attachment point |
|---|---|---|---|
| Network ACL | Stateless | Ordered, first match, permit and deny | Interface or subnet |
| Stateful firewall | Tracks sessions | Ordered policies with return traffic allowed | Network perimeter or zone boundary |
| Cloud security group | Stateful | Allow rules only, all evaluated | Instance or network interface |
| Host firewall | Usually stateful | Ordered chains on the host | Operating system |
In practice, these controls are layered rather than chosen. A network ACL provides a coarse subnet-level guardrail, a security group or host firewall enforces precise per-workload rules, and a perimeter firewall handles inspection and logging. Network ACLs are also a building block of network segmentation, while VPN technologies such as IPsec and WireGuard protect traffic in transit rather than filter it.
Designing and placing ACL rules
A good ACL starts from a default-deny policy and permits only the traffic that a documented requirement needs. Rules run from most specific to most general, and frequently matched rules can be placed higher on software-based platforms to reduce evaluation cost. Hardware platforms evaluate ACLs in TCAM, where rule order affects the result but not the speed.
| Situation | Recommended approach | Reason |
|---|---|---|
| Protecting a server subnet | Extended ACL inbound on its gateway interface | Filters before traffic reaches hosts |
| Restricting device management | Standard ACL on management access lines | Limits who can reach SSH or SNMP |
| Cloud subnet guardrail | Numbered rules with explicit deny entries | Blocks known bad ranges for all instances |
| Return traffic for clients | Permit ephemeral ports or established TCP | Stateless filters need explicit replies |
| Frequent rule changes | Named ACL with sequence numbers | Entries can be inserted without rewriting |
Leave gaps in sequence numbers, for example steps of 10, so that new entries can be inserted later. Add a description or remark to each block of rules, and enable logging on deny entries selectively, because logging every match can overload the control plane of a router.
Common mistakes and limitations
Most ACL incidents come from ordering errors and forgotten return traffic, not from missing features. The following problems appear repeatedly in audits and outage reviews:
- Shadowed rules: a broad permit or deny above a specific entry makes the specific entry dead code.
- Forgetting the implicit deny: an ACL with only deny entries blocks all traffic, including legitimate flows.
- Blocking return traffic: permitting requests without permitting the ephemeral port range of replies breaks connections.
- Missing IPv6 rules: an IPv4 ACL does nothing for IPv6 traffic on a dual-stack interface.
- Locking out management: applying a new ACL remotely without a rollback timer can cut off the administrator’s own session.
- Treating ACLs as a full firewall: they cannot inspect payloads, detect attacks or follow protocols that negotiate ports dynamically.
ACLs also grow hard to audit over time. Long lists accumulate obsolete entries for decommissioned servers, so a periodic rule review with hit counters is essential to keep the list accurate and short.
The short version
A network ACL works like a guest list at the door of a network segment. Every arriving packet is checked against the list from the top, and the first line that matches decides whether it may enter. If no line matches, the packet is turned away.
The list only looks at the label on each packet, such as where it comes from, where it goes and which service it wants. It does not open the package. It is a fast first filter, not a complete security system.
Where it makes a difference
A hospital network team separates its medical device subnet from the general office network. The devices need to send data only to one records server on TCP port 443 and receive time updates from two internal NTP servers.
The team applies an extended inbound ACL on the router interface facing the device subnet. It permits HTTPS to the records server, NTP to the two time servers, and return traffic for those flows, then ends with an explicit deny with logging. A matching outbound ACL allows only the records server and the monitoring system to reach the devices.
Weeks later, an infected office laptop starts scanning internal ranges. The scan never reaches the medical devices: the router drops the probes at the subnet boundary, and the deny log gives the security team the source address within minutes.