ACL vs Firewall: What's the Difference and When to Use Each

They Are Not Interchangeable

Network engineers use both ACLs and firewalls — often on the same network, sometimes on adjacent devices. The question of which to use comes up constantly in design reviews, and the answer is almost always "both, but for different things."

The confusion exists because both can permit or deny traffic based on IP addresses and ports. Stop there and they look identical. Go one level deeper and they're fundamentally different tools solving different problems. Using an ACL when you need a firewall is a security mistake. Using a firewall when an ACL would suffice is an architecture mistake.

What an ACL Is

An ACL — Access Control List — is a stateless packet filter. It's a sequential list of permit and deny statements applied to an interface, evaluated top to bottom, with an implicit deny all at the end.

Stateless means it evaluates each packet individually. It has no memory of what came before. Every packet is assessed purely on its own headers — source IP, destination IP, protocol, ports — against the rules in the list, in order, until a match is found.

ip access-list extended BLOCK-TELNET
 deny   tcp any any eq 23 log
 permit ip any any
!
interface GigabitEthernet0/0
 ip access-group BLOCK-TELNET in

This ACL blocks all inbound Telnet and permits everything else. Simple, fast, and effective for exactly that purpose. The router doesn't care whether that TCP port 23 packet is part of an established connection or a new one — it just checks the rule and acts.

That simplicity is the ACL's strength and its limitation. It runs in hardware on most platforms using TCAM (ternary content-addressable memory), which means it filters traffic at line rate with essentially zero performance impact. A router can apply ACLs to millions of packets per second without issue.

But it knows nothing about sessions. It cannot distinguish between a legitimate return packet for an established connection and a spoofed packet with the same headers. It cannot track whether a TCP handshake completed. It cannot understand Layer 7.

What a Firewall Is

A stateful firewall maintains a connection state table. When a packet initiates a new connection, the firewall records that session — source IP, destination IP, ports, protocol, TCP flags, sequence numbers. Every subsequent packet for that session is checked against the state table, not just against a static rule list.

This means a stateful firewall can do something an ACL fundamentally cannot: automatically permit return traffic for connections legitimately initiated from the inside, without requiring explicit rules for the return direction.

With an ACL trying to achieve the same result, you'd need to permit return traffic explicitly — or use the established keyword on Cisco IOS, which checks ACK/RST bits in TCP headers but is still a heuristic, not true stateful inspection.

A next-generation firewall (NGFW) goes further: Layer 7 application inspection, SSL/TLS decryption, user-identity-based policies, IPS signature matching, file inspection, and threat intelligence integration. An ACL can do none of these things.

The Performance Trade-off

Stateful inspection has a cost. The firewall must maintain state for every active connection — memory for the state table, CPU cycles to look up and update entries. At high connection rates, this becomes the limiting factor.

A router applying ACLs handles multi-gigabit traffic at line rate. A firewall doing stateful inspection of the same volume needs significantly more hardware. This is why you don't route everything through a firewall — much of that traffic doesn't need deep inspection, and the hardware cost would be enormous.

The practical architecture for most enterprise networks reflects this: ACLs on the router for coarse high-speed filtering, firewall at the perimeter for stateful inspection of traffic crossing security boundaries.

Where Each Belongs

Use ACLs for: blocking specific traffic at line rate (denying known-bad source ranges, blocking management protocols on untrusted interfaces, preventing RFC 1918 addresses from appearing on internet-facing interfaces), route filtering in BGP and OSPF, QoS traffic classification and DSCP marking, VTY access restriction for SSH management, NAT traffic selection, and policy-based routing.

Use a firewall for: any security boundary between trust zones (internet-to-LAN, LAN-to-DMZ, internal segmentation between departments), anywhere you need automatic return traffic handling, application-layer inspection (HTTP content filtering, DNS inspection, detecting tunneling), user-identity-based policies, threat detection via IPS signatures, and any environment subject to compliance requirements (PCI-DSS, HIPAA, SOC 2) mandating stateful inspection.

The Classic Mistake

The most common mistake in enterprise networks that grew organically: router ACLs used as the primary security control at the internet perimeter.

It looks like this: a router with a WAN interface has an inbound ACL permitting only specific ports (80, 443, 25) and denying everything else. The internal LAN interface has another ACL permitting outbound. This feels secure. It isn't.

Those permitted ports — 80 and 443 — represent the vast majority of internet traffic. An attacker who can communicate over HTTP or HTTPS can do almost anything. Without stateful inspection and application awareness, you have no visibility into what's happening within those permitted flows. A web shell, a C2 beacon, data exfiltration — all of it moves over port 443 and your ACL passes it through, because the ACL only sees "destination port 443, permit."

ACLs also can't handle fragmented packet attacks properly in all implementations, don't track TCP state, and can be confused by evasion techniques that send packets out of order or with unusual flag combinations. For a perimeter security control, these are significant exposures. The ACL is not wrong — you should have one — but it cannot be the only control.

Using Both Together

The right architecture uses ACLs and firewalls as complementary layers, not substitutes.

On the router upstream of the firewall, apply an inbound ACL to drop traffic that has no business entering your network — RFC 1918 addresses, bogons, known-malicious ranges, categorically blocked protocols. This filtering happens at hardware speed and reduces the volume of traffic the firewall must process.

The firewall then handles everything that made it through — stateful inspection, application-layer analysis, zone-based policy enforcement.

On the router downstream (if any), ACLs can enforce additional coarse policies — subnet-to-subnet reachability controls, management plane protection, QoS markings before traffic enters the LAN.

Neither replaces the other. The ACL runs fast and handles volume. The firewall runs deep and handles sophistication. Good network security design uses both for what each does well.

Quick Reference

The Bottom Line

An ACL is a fast, stateless packet filter that runs on your router. A firewall is a stateful security enforcement point that understands sessions, applications, and threats. Different tools. Different jobs.

Use ACLs for high-speed coarse filtering, route policy, QoS classification, and management plane protection. Use firewalls at every security boundary where you need to understand what a connection is actually doing, not just what its headers say.

If you want to build and test ACL logic before deploying, the ACL Builder tool on this site generates named and numbered IOS ACL syntax from a visual interface. The CLI Cheatsheet has the full ACL command reference including hit counters and verification commands.