What is ACL (Access Control Lists)?
Updated: 3 days ago
An ACL, or Access Control List, is an ordered set of rules used by network devices and security systems to decide which traffic matches a policy. In a common traffic-filtering ACL, each packet is compared with entries in sequence. The first matching entry determines whether that traffic is permitted or denied. Rule order therefore matters just as much as the rules themselves.
ACLs can be applied at different points in a network and can match different information depending on the platform. Source and destination IP addresses, IP protocol and TCP or UDP ports are common criteria. ACL is a broad networking term, so exact syntax and behaviour vary between routers, switches, firewalls, cloud platforms and operating systems.
How does an Access Control List work?
An ACL is normally made from individual Access Control Entries, often shortened to ACEs. Each ACE describes traffic to match and the action associated with that match. For traffic-filtering ACLs, the device evaluates entries in their configured order. Once a match is found, later entries are not considered.
Traffic arrives at the device or interface where the ACL is applied.
The device evaluates the first relevant ACL entry.
If the packet does not match, evaluation continues to the next entry.
When an entry matches, its permit or deny action is applied.
If no explicit entry matches, many traffic-filtering ACL implementations use an implicit deny at the end.
Cisco documents this first-match behaviour and the importance of rule order in its ACL configuration guidance. The important practical lesson is that a broad rule placed too early can make a later, more specific rule unreachable.
What can an ACL match?
Source IP address or network: identifies where the traffic originates.
Destination IP address or network: identifies where the traffic is going.
Protocol: for example IP, TCP, UDP or ICMP where supported.
Source or destination port: commonly available in extended rules for TCP or UDP.
Direction and attachment point: the same rule set can behave differently depending on where and in which direction it is applied.
Other fields: some platforms support additional criteria such as DSCP, TCP flags, ICMP types, time ranges or interface context.
Do not assume that every ACL implementation supports the same fields. An ACL on a home or business router, a managed switch, a Linux host and a cloud network can share the same basic policy idea while using different syntax and processing models.
Standard ACL vs extended ACL
On Cisco IPv4 platforms, a standard ACL normally matches source addressing, while an extended ACL can make a more granular decision using source and destination addresses plus protocol information and, where appropriate, TCP or UDP ports. This standard-versus-extended distinction is strongly associated with Cisco-style ACL terminology rather than a universal naming scheme used identically by every vendor.
Standard ACL: useful when a decision only needs to identify the source address or source network.
Extended ACL: useful when the policy must distinguish both ends of a flow or specific protocols and services.
Named or numbered ACL: a configuration and identification choice on platforms that support both forms.
Why ACL rule order matters
ACL evaluation is not a search for the most specific rule. In first-match implementations, the device stops at the first entry that matches. A general permit placed before a specific deny can therefore permit traffic that the administrator intended to block.
Practical example: suppose rule 10 permits the entire 10.0.0.0/24 network and rule 20 denies host 10.0.0.50. If rule 10 is evaluated first and matches 10.0.0.50, the later deny is never reached. Put the specific exception before the broader rule when that is the intended policy.
What is an implicit deny?
Many traffic-filtering ACLs behave as though a final deny rule exists after the visible entries. If traffic reaches the end without matching an earlier permit, it is denied. This is commonly called an implicit deny.
This is one reason an incomplete ACL can cause an outage. Adding a rule that permits one required flow does not automatically permit everything else. Whether an implicit deny applies, and exactly how it behaves, depends on the platform and the feature using the ACL. ACLs used to select traffic for another service can interpret permit and deny differently from an ACL used directly to allow or block forwarded traffic.
Inbound vs outbound ACLs
Direction describes where the packet is in relation to the interface or policy point. An inbound ACL evaluates traffic as it arrives. An outbound ACL evaluates traffic before it leaves through the relevant interface. Applying a correct rule set in the wrong direction can make it ineffective or block unintended traffic.
Always read direction from the perspective of the device interface, not from the perspective of the person configuring it. On a router with several interfaces, the same packet can be inbound on one interface and later outbound on another.
ACL vs firewall
An ACL and a firewall are related but not identical concepts. An ACL is fundamentally a list of matching rules. A firewall can use rule lists but may also maintain connection state, inspect protocols, apply application-aware policy, perform NAT and provide logging or threat-prevention functions.
For a deeper look at how traffic fields can be examined, see packet inspection. ACL matching is often much narrower than deep inspection.
ACLs, VLANs and network segmentation
ACLs are often used alongside VLANs and network segmentation. A VLAN can separate broadcast domains, while an ACL can control which routed traffic is permitted between networks or towards particular services.
Segmentation without an enforcement policy may still allow routed communication between segments. Conversely, an ACL cannot create a VLAN. They solve different parts of the network-control problem and are frequently combined.
ACLs with IPv4, IPv6 and NAT
ACLs can be used with both IPv4 and IPv6, but the syntax and supported features can differ. Do not assume an IPv4 ACL automatically controls equivalent IPv6 traffic.
NAT can also affect which address a rule needs to reference. The correct pre-NAT or post-NAT address depends on the platform and where ACL evaluation occurs in its packet-processing order. This is a vendor-specific implementation detail that should be checked before changing a live policy.
Where might a broadband user encounter ACLs?
A prosumer or business router controlling traffic between LANs or VLANs.
A managed switch applying port, VLAN or routed-interface policy.
A firewall or security gateway restricting inbound or outbound flows.
A cloud network controlling which systems can communicate.
A server or network operating system using rule lists for packet filtering.
A home-lab network separating trusted devices, IoT equipment, guest networks and management interfaces.
Most ordinary UK broadband customers will not need to configure router ACLs manually. They become more relevant when using advanced routers, managed switches, multiple VLANs, static addressing, self-hosted services or business networks. Your FTTP, FTTC, cable or mobile access technology does not itself determine whether an ACL is required.
Techie Broadband example: designing a least-access policy
Practical example: imagine a home lab with a trusted LAN, an IoT VLAN and a management network. The objective is to let IoT devices reach DNS and required internet services while preventing them from initiating connections to the trusted LAN or router-management interface.
Write down the required flows before writing rules.
Place specific management and security exceptions before broad permits.
Permit only the inter-network traffic that is actually required.
Decide what should happen to unmatched traffic and account for the platform's default behaviour.
Apply the ACL at the correct interface or policy point and in the correct direction.
Test required services and blocked paths separately.
Review counters and logs where the platform provides them.
The value of this exercise is not the exact syntax. It is the policy model: define required communication first, translate it into ordered rules second, then test both the traffic that should work and the traffic that should fail.
Common ACL mistakes
Putting a broad permit before a specific deny.
Forgetting that unmatched traffic may be denied implicitly.
Applying the ACL to the wrong interface.
Applying it in the wrong direction.
Using the wrong source or destination network.
Confusing wildcard masks with subnet masks on platforms that use wildcard notation.
Assuming IPv4 rules also cover IPv6.
Changing a remote-management ACL without preserving your own management access.
Assuming an ACL is stateful simply because a firewall uses ACL-like rules.
How to troubleshoot an ACL problem
Identify the exact source IP, destination IP, protocol and destination port of the failing traffic.
Confirm which interface, VLAN or policy point the traffic crosses.
Confirm whether the ACL is evaluated inbound or outbound.
Read the entries from top to bottom and find the first rule that should match.
Check for an earlier broader rule that shadows the intended rule.
Check the end-of-list behaviour, including any implicit deny.
Verify whether NAT changes which address should be referenced at that stage.
Check IPv4 and IPv6 separately where both are enabled.
Use rule counters, logs or packet capture where available to confirm what actually matched.
Make one controlled change at a time and retest both permitted and denied traffic.
When changing ACLs remotely, take particular care not to remove the path used to administer the device. A technically correct security rule can still lock you out if it blocks your own management session.
ACL FAQs
Does ACL mean Access Control List?
Yes. In networking, ACL commonly means Access Control List: an ordered collection of entries used to identify traffic and apply a policy.
Does an ACL always block traffic?
No. ACL entries can permit or deny matching traffic, and ACLs can also be used by some platforms to classify traffic for another feature rather than directly block it.
Is an ACL the same as a firewall?
No. An ACL is a rule list or policy mechanism. A firewall can use rule lists while also providing state tracking, NAT, application inspection and other security functions.
What happens if no ACL rule matches?
In many traffic-filtering ACL implementations, unmatched traffic reaches an implicit deny and is dropped. This is not a safe universal assumption for every feature or platform, so verify the implementation you are configuring.
Can ACLs filter ports?
Extended or similarly capable ACLs can commonly match TCP or UDP ports. A basic or standard ACL may only match addressing information.
Key takeaway
An Access Control List is simple in concept but unforgiving in implementation. It is an ordered policy. The first matching rule matters, direction and placement matter, and unmatched traffic may be denied. Design the required communication first, make specific rules precede broader rules, verify IPv4 and IPv6 separately, and test both the allowed and denied paths before treating the policy as complete.
To explore the related technical concepts used in this ACL (Access Control Lists) guide, visit our broadband terminology guide.
