Understanding ACL Hierarchy on Digi Devices.

Access Control Lists (ACLs) are essential for securing Digi devices, especially when restricting access to services like the Web User Interface (Web UI). However, many users encounter issues where ACLs appear to be misbehaving—such as allowing access from IPs that should be blocked. This is often due to a misunderstanding of the hierarchical structure that governs how ACLs are applied.

This article focuses on the three-tier hierarchy used by Digi devices to evaluate and enforce ACLs:

1. Zones
2. Interfaces
3. IP Addresses

Understanding and correctly applying this hierarchy is key to effective access control.

Step-by-Step: ACL Hierarchy Explained

🔹 1. Zones – The Primary Layer

Zones are the top-level organizing principle in Digi’s firewall model. Every interface is assigned to a zone, and firewall rules are applied at the zone level.

On zone level, when a zone is selected during configuration traffic will be filtered base on the specified zone lists. for example if External zone is selected all external traffic will be allowed through  to access the web ui.

Common Zones:

• external: Typically for WAN or public-facing interfaces.
• internal: For trusted LAN interfaces.
• edge: For perimeter networks.
• setup: For setup or provisioning interfaces.
• ipsec: For VPN-related traffic.

🔐 Tip: Always start by reviewing which zone your interface belongs to. Zone-level rules will override any service-specific ACLs. if you dont want  you acl to be zone based you can delete all the zones from the configurations section.

🔹 2. Interfaces – The Secondary Layer

Once zones are defined, interfaces (e.g., eth0, eth1, modem, bridge) are assigned to those zones. ACLs can be refined based on which interface traffic is coming from.

Interfaces will generally tie web services access to a certain interface. this means only the specified interfaces will ballowed to access this services.

Example:

If  only eth1 is assigned to web services . only this interfaces will be allowed to access service and other interfaces will be blocked from this service.

⚠️ Note: If the zone allows broad access, interface-level ACLs may not be effective unless the zone itself is restricted.

🔹 3. IP Addresses – The Final Layer

Finally, ACLs can specify IP address ranges to allow or deny access. This is the most granular level of control.

Example:

You might configure the Web UI to allow access only from 192.168.1.0/24. However, if the zone or interface allows broader access, this ACL may be bypassed.

✅ Best Practice: Always ensure that zone and interface rules are aligned with your IP-based ACLs.

🛡️ Why ACLs May Fail: A Common Scenario

❌ Problem:

You configure the Web UI to allow only 192.168.1.0/24, but other IPs still access it.

✅ Root Cause:

• The interface (eth0) is assigned to the external zone.
• The external zone has permissive firewall rules.
• The ACL on the Web UI is overridden by zone-level access.

🔍 How to Fix It

1. Review Zone Assignments

   • Go to the firewall settings and check which zone each interface belongs to.

2. Restrict Zone-Level Firewall Rules

   • Apply strict rules at the zone level to block unwanted traffic.

3. Apply Interface-Level ACLs

   • Refine access based on the interface handling the traffic.

4. Configure IP-Based ACLs

   • Finally, specify allowed IP ranges for each service.

5. Test and Validate

   • Use diagnostic tools or logs to verify that ACLs are working as expected.

📌 Final Reminder: Firewall Rules Take Priority

Even if you configure ACLs for a specific service, zone-level firewall rules will take precedence. Always start with zone configuration before applying service-specific ACLs.

ny links to supporting documentation or final information for the user]