Firewall ACL Best Practices: 8 Common Mistakes & How to Fix Them

Ehsan Ghasisin How To | Expert Picks | Firewall
08/28/2025 11:22am 9 minute read

Minor Access Control List (ACL) errors create major security gaps. Misconfigurations like improper rule order or overly broad permissions are common access control list errors that can expose critical assets. This article addresses these issues with tested fixes and validation steps.

Fixing firewall misconfigurations requires a systematic approach. Engineers must enforce explicit denials, ensure rule specificity, and audit ACLs regularly. This guide provides actionable steps to correct the most frequent and costly mistakes.

Key Takeaways: Fixing Common ACL Mistakes

Be Specific: Replace broad any-any rules with precise source, destination, and port definitions. Temporary rules are a significant security risk.
Enforce Explicit Denials: Always end an ACL with a “deny ip any any” rule. Never rely on a platform's default behavior.
Verify Rule Order: Place specific rules (especially denials) before general rules. High-traffic permit rules should be near the top for performance.
Audit and Clean Up: Regularly review ACLs for shadowed, redundant, or unused rules.
Use Hit Counters: Leverage hit counters and last-match timestamps to find rules that are safe to remove.
Validate Direction: Double-check that you apply ACLs to the correct interface and in the proper direction (inbound vs. outbound).

Mistake #1: Ignoring the Implicit Deny

An implicit deny is a default block of unmatched traffic that can fail if the device is misconfigured. Most firewalls default to denying traffic that isn't explicitly permitted. However, some cloud platforms or older devices can be set to allow by default, making an explicit rule a critical safeguard.

This oversight violates the principle of least privilege. An administrator might believe the network is secure. In reality, a misconfigured default could leave it wide open.

Real-World Symptom: An external vulnerability scan reveals open ports you never intended to expose.
Authoritative Principle: The principle of "deny by default" is a foundational concept in security. NIST SP 800-41 (Guidelines on Firewalls and Firewall Policy) mandates that a firewall's default action should be to deny all traffic.
Validation: Implementing an explicit deny all aligns with best practices from Cisco, Palo Alto Networks, and the Center for Internet Security (CIS) Benchmarks.

The Problem:

access-list OUTSIDE-IN permit tcp any host 192.0.2.10 eq 443

The Solution:

access-list OUTSIDE-IN permit tcp any host 192.0.2.10 eq 443
access-list OUTSIDE-IN deny ip any any log

Mistake #2: Using Overly Permissive 'Any-Any' Rules

An any-any rule is an overly permissive entry that disables meaningful filtering and invites lateral movement. This single line effectively bypasses all security filtering for that traffic flow. It transforms your state-of-the-art firewall into a simple router.

Attackers can exploit this vulnerability to gain access to your network. This is one of the most common yet damaging mistakes with firewall rules. It often originates from a rushed troubleshooting session.

Real-World Symptom: Intrusion detection systems flag anomalous traffic moving between internal subnets.
Authoritative Principle: The principle of specificity dictates that firewall rules should be as narrow as possible, defining the exact source, destination, and service required.
Validation: This approach is a core requirement for compliance frameworks. For example, PCI DSS 1.2.1 requires that firewall rules be specific and justified, permitting only traffic necessary for business functions.

The Problem:

access-list VPN-TRAFFIC permit ip any any

The Solution:

remark TICKET-12345: Allow Marketing VPN to access web server.
access-list VPN-TRAFFIC permit tcp 10.10.20.0 255.255.255.0 host 192.0.2.50 eq 443

Mistake #3: Applying ACLs in the Wrong Direction

Incorrect ACL direction occurs when a rule is applied inbound instead of outbound, or vice versa, which breaks the intended intent. This simple mistake completely negates the rule's purpose. The firewall will either block legitimate return traffic or fail to filter malicious inbound traffic.

This is a frequent source of ACL misconfiguration during initial setup. It creates connectivity problems that are difficult to diagnose. The symptoms often mimic a network outage.

Real-World Symptom: Users report that the connection times out. A packet capture shows SYN packets being sent out, but SYN-ACK replies never return because the inbound vs. outbound ACL is reversed.
Authoritative Principle: Firewall logic is directional. An ACL must be applied to the correct interface and direction (inbound or outbound) to properly inspect traffic as it crosses a security boundary.
Validation: Every major network vendor's documentation, including that of Juniper and Cisco, emphasizes the critical distinction between applying filters to ingress and egress traffic.

The Problem:

interface GigabitEthernet0/0
ip access-group OUTSIDE-IN out

The Solution:

interface GigabitEthernet0/0
ip access-group OUTSIDE-IN in

Mistake #4: Creating Shadowed Rules (Overlapping ACLs)

A shadowed rule never executes because an earlier, broader rule already matches the same traffic. Firewalls process ACLs from the top down and stop at the first match. If a general “permit ip any any” is on line 1, no deny rule below it will ever be checked.

These overlapping ACL rules can create a false sense of security and generate significant noise during compliance audits. An administrator sees a specific deny rule in the configuration. They incorrectly assume it is actively protecting the network.

Real-World Symptom: You add a rule to block SSH access, but connections succeed. Hit counters on the deny rule show zero matches, while counters on the broad permit rule above it increase.
Authoritative Principle: The ACL order of operations in firewalls is strictly sequential. This top-down, first-match logic is a fundamental aspect of packet filtering defined in documents like RFC 2993.
Validation: Firewall auditing tools, such as Tufin and FireMon, are specifically designed to detect shadowed and redundant rules, confirming this as a critical best practice.

The Problem:

access-list INSIDE-OUT line 1 permit ip 10.0.0.0 255.0.0.0 any
access-list INSIDE-OUT line 2 deny tcp any host 192.0.2.100 eq 22

The Solution:

access-list INSIDE-OUT line 1 deny tcp any host 192.0.2.100 eq 22
access-list INSIDE-OUT line 2 permit ip 10.0.0.0 255.0.0.0 any

Mistake #5: Object Group Misuse

Object-group misuse grants unintended access when a new host inherits permissions meant for a different role. Object groups simplify management, but they also introduce risk. A single change can have wide-ranging security implications.

This firewall policy misconfiguration is common in large environments. An engineer adds a new web server to the "SERVERS" group. They do not realize that groups also have a rule permitting RDP access.

Real-World Symptom: An audit reveals that a public-facing web server has RDP enabled and is accessible from an internal helpdesk network.
Authoritative Principle: Change management controls are essential for shared configuration items. NIST SP 800-53 (AC-3) requires formal review for changes to access control policies.
Validation: Using role-based object groups (e.g., WEB-SERVERS) is a recommended practice in Fortinet's and Cisco's configuration guides to prevent permission creep.

The Problem:

object-group network PRODUCTION-SERVERS
network-object host 192.0.2.50
network-object host 192.0.2.51
!
access-list MGMT-ACCESS permit tcp 10.10.50.0 255.255.255.0 object-group PRODUCTION-SERVERS eq 3389

The Solution:

object-group network PUBLIC-WEB-SERVERS
network-object host 192.0.2.50
object-group network INTERNAL-DB-SERVERS
network-object host 192.0.2.51
!
access-list DB-MGMT-ACCESS permit tcp 10.10.60.0 255.255.255.0 object-group INTERNAL-DB-SERVERS eq 1521

Mistake #6: Incorrect Port and Protocol Assumptions

Port or protocol misidentification happens when rules assume standard ports while the app uses non-standard ones. Many applications use dynamic or custom ports. This is a common firewall troubleshooting issue when engineers assume default ports.

Blocking only port 80 for HTTP traffic will not stop an application communicating on port 8080. The root cause is a faulty assumption about application behavior.

Real-World Symptom: A new application works in a test lab but fails in production. Packet captures show the firewall dropping SYN packets destined for a high-numbered, non-standard port.
Authoritative Principle: Accurate identification of network services is paramount for effective security policy. Administrators must confirm the actual protocols and ports in use before implementation.
Validation: Tools such as “netstat” on the host or using a packet analyzer like Wireshark are standard industry procedures for validating traffic flows before writing ACLs.

The Problem:

access-list APP-TRAFFIC permit tcp any host 192.0.2.75 eq 443

The Solution:

access-list APP-TRAFFIC permit tcp any host 192.0.2.75 eq 8443

Mistake #7: Inefficient Rule Ordering

Inefficient ordering places hot-path traffic late in the list, which hurts performance and increases change risk. Because the firewall must check every rule above it first, this degrades performance. In software-based firewalls running on general-purpose CPUs, the performance impact is even more severe.

Even on hardware with fast ASICs, processing hundreds of irrelevant rules can cause delays, as many pipelines still benefit from early, short-circuit matches. This is more than a performance issue; it's a stability risk.

Real-World Symptom: The firewall's CPU utilization spikes during business hours. Users report intermittent connection drops or slowness, even though network bandwidth is sufficient.
Authoritative Principle: For performance optimization, high-traffic rules should be placed as close to the top of the ACL as possible to minimize processing.
Validation: This "hot rule" optimization is a documented firewall ACL best practice in performance tuning guides from nearly every major network hardware vendor.

The Problem:

access-list OUTSIDE-IN line 10 deny tcp any any eq 135
...
access-list OUTSIDE-IN line 990 permit tcp any host 192.0.2.10 eq 443
access-list OUTSIDE-IN line 999 deny ip any any

The Solution:

access-list OUTSIDE-IN line 10 deny tcp any any eq 135
access-list OUTSIDE-IN line 20 permit tcp any host 192.0.2.10 eq 443
...
access-list OUTSIDE-IN line 999 deny ip any any

Mistake #8: Not Auditing or Removing Old Rules

ACL cruft is the accumulation of unused, temporary, or stale rules that expand the attack surface and slow operations. Over time, this results in a bloated and difficult-to-manage configuration. An old rule for a decommissioned server might grant access to a new server that later uses the same IP address.

Quarantine candidate removals by disabling rather than deleting them for one review cycle. This provides a safe rollback path. Every unnecessary rule adds complexity and a potential point of failure.

Real-World Symptom: This manifests as a list of common firewall misconfiguration symptoms: the configuration is thousands of lines long, no one knows what half the rules do, and change requests take days because engineers fear breaking something.
Authoritative Principle: Regular policy review is a core component of security lifecycle management. CIS Controls (Control 11) calls for the maintenance and review of network device configurations.

Validation: All major compliance frameworks (PCI DSS, HIPAA) require regular audits of firewall rule bases to ensure that all rules are documented, justified, and still necessary.

The Problem:

remark Rule for VendorX project from 2023. Server decommissioned.
access-list VENDOR-ACCESS permit tcp any host 192.0.2.88 eq 3389

The Solution:

remark TICKET-9876: Temp RDP for VendorY, expires 2025-12-01
access-list VENDOR-ACCESS permit tcp 203.0.113.5 host 192.0.2.90 eq 3389

Firewall ACL Audit Checklist

1. Confirm explicit final deny with logging on all external-facing ACLs.

2. List top talkers and ensure hot-path permit rules are placed early in the list.

3. Move specific denies above any broad permit rules that might overlap.

4. Verify ACL direction (in vs. out) on each assigned interface.

5. Resolve shadowed rules and remove any exact duplicate entries.

6. Validate real service ports using packet captures or host tools, rather than relying on assumptions.

7. Review object-group membership changes as part of the change control process.

8. Remove rules with zero hits over the last 90-180 days (or your business cycle).

9. Tag each rule with a ticket number, owner, and creation/review date.

10. Verify logging levels and log storage for denied traffic to ensure forensic visibility.

FAQs

1. What are common firewall ACL mistakes?

Common firewall ACL mistakes include any-any permits, wrong rule order, missing an explicit deny, and direction errors. Other frequent issues are shadowed rules that never execute and failing to remove old rules, all of which weaken network security and complicate management.

2. How do you fix ACL misconfigurations?

Fixing ACL misconfigurations requires a systematic audit, ordering specific before general, enforcing an explicit final deny, and removing unused entries. Always validate application port requirements instead of assuming defaults. This process improves security posture and operational stability.

3. Why does ACL order matter in firewalls?

ACL order matters because firewalls stop processing at the first rule that matches the traffic. A broad permit rule placed too high can completely bypass a more specific deny rule below it. Proper ordering ensures security intent is met and optimizes performance.

4. What is the most common firewall rule error?

The most common error is leaving a temporary "permit any any" rule in place after troubleshooting. This single rule effectively nullifies all other filtering for that traffic. It is a critical vulnerability that turns the firewall into a simple, insecure router.

5. How often should firewall ACLs be reviewed?

Firewall ACLs should be reviewed at least quarterly, or after major changes. Regular reviews ensure temporary rules are removed, unused entries are identified via hit counters, and compliance frameworks such as CIS Controls and PCI DSS are met.