Configuring and Verifying IPv4 ACLs

ACL Fundamentals: The Rules of Engagement

At its heart, an Access Control List is a sequence of permit and deny rules, known as Access Control Entries (ACEs), that are evaluated in order from top to bottom. When a packet arrives at an interface with an applied ACL, the device checks the packet against each ACE sequentially.

To understand these core principles, let's turn to a well-written guide that breaks them down.

Let's summarize the critical rules you just read about:

1. Top-Down Processing: The device inspects ACEs from the top of the list downwards.
2. First Match Wins: As soon as a packet matches the criteria of an ACE, the permit or deny action is taken, and no further ACEs in that list are checked.
3. Implicit Deny All: If a packet makes it to the end of the list without matching any ACE, it is automatically dropped. This is the implicit deny. Because of this, any ACL that has at least one permit statement will almost always need a final permit statement (like permit ip any any) to avoid unintentionally blocking all other traffic.

Wildcard Masks

As the resource mentioned, wildcard masks are a key concept in IPv4 ACLs. They tell the router which bits of an IP address to check. A 0 bit in the wildcard mask means "the corresponding bit in the IP address must match," while a 1 bit means "I don't care about the corresponding bit."

• To match a single host (e.g., 192.168.1.5), you use a wildcard mask of 0.0.0.0. This tells the router every bit must match.
• To match any IP address, you use 255.255.255.255. This tells the router you don't care about any of the bits.
• To match a subnet like 192.168.10.0/24, the wildcard mask is 0.0.0.255. This means the first three octets must match, but the last octet can be anything.

  255.255.255.255
- 255.255.252.  0
-------------------
    0.  0.  3.255

Standard vs. Extended ACLs

IPv4 ACLs come in two main flavors: standard and extended. The key difference lies in their granularity.

• Standard ACLs (Numbered 1-99, 1300-1999):

  • Filter traffic based only on the source IP address.
  • Best Practice for Placement: Apply them as close to the destination as possible. Why? Because they can't specify a destination or traffic type, applying them close to the source might block legitimate traffic destined for other locations.

• Extended ACLs (Numbered 100-199, 2000-2699):

  • Filter traffic based on a combination of:
    • Source and Destination IP address
    • Protocol (TCP, UDP, ICMP, EIGRP, OSPF, etc.)
    • Source and Destination Port numbers (for TCP/UDP)
  • Best Practice for Placement: Apply them as close to the source as possible. Since they are very specific, you can filter unwanted traffic right at the entry point to your network, saving bandwidth and processing resources on downstream devices.

This next video provides an excellent, concise demonstration of configuring an extended ACL and explains the "close to the source" logic.

Named ACLs

While numbered ACLs are functional, named ACLs are generally preferred in modern networks. They allow you to use a descriptive name (e.g., BLOCK_GUEST_INTERNET) instead of a number, which greatly improves readability and management. Crucially, named ACLs also allow you to delete or insert individual ACEs without having to delete and re-create the entire list.

The configuration syntax shifts slightly:

• Numbered ACL: access-list 101 permit tcp any host 10.1.1.1 eq 80
• Named ACL:

  ip access-list extended ALLOW_WEB_ACCESS
   permit tcp any host 10.1.1.1 eq 80
  

Time-Based ACLs

What if you need a policy to be active only during business hours? Time-based ACLs allow you to associate a time-range with an extended ACL entry, making it active only during specified periods. This is extremely useful for policies like restricting employee internet access after hours or allowing partner access only during a scheduled maintenance window.

The configuration is a two-step process:

1. Define the Time Range: Create a named time range and specify its periodic or absolute schedule.
2. Apply to an ACE: Reference the time range name at the end of an extended ACL statement.

Let's watch a practical demonstration of this feature.

As the video highlights, this feature depends on the device having the correct time. This is why running Network Time Protocol (NTP) is a critical best practice in any network.

Configuration and Verification Scenario

Let's put this all together. Imagine you are asked to implement a security policy based on the following topology and requirements.

Security Policy:

• A developer at PC1 (192.168.10.10) must be blocked from accessing the web servers Server1 (192.168.20.10) and Server2 (192.168.20.11) using HTTP and HTTPS.
• All other traffic from the 192.168.10.0/24 LAN should be permitted to the server segment.

Configuration Steps:

1. Create a Named Extended ACL: We'll call it LAN_TO_SERVER_POLICY.
2. Add deny Statements: Add specific rules to block PC1 from the servers on ports 80 (HTTP) and 443 (HTTPS).
3. Add a permit Statement: Add the crucial final statement to allow all other IP traffic.
4. Apply the ACL: Apply the ACL to the correct interface and in the correct direction. Following best practices, we will apply this extended ACL close to the source.

Here is the complete configuration on router R1:

! Step 1: Create the named extended ACL
R1(config)# ip access-list extended LAN_TO_SERVER_POLICY

! Step 2: Add deny statements for PC1 to Server1
R1(config-ext-nacl)# deny tcp host 192.168.10.10 host 192.168.20.10 eq 80
R1(config-ext-nacl)# deny tcp host 192.168.10.10 host 192.168.20.10 eq 443

! Step 2: Add deny statements for PC1 to Server2
R1(config-ext-nacl)# deny tcp host 192.168.10.10 host 192.168.20.11 eq 80
R1(config-ext-nacl)# deny tcp host 192.168.10.10 host 192.168.20.11 eq 443

! Step 3: Permit all other traffic to avoid unintended blocking
R1(config-ext-nacl)# permit ip any any
R1(config-ext-nacl)# exit

! Step 4: Apply the ACL inbound on the LAN interface
R1(config)# interface GigabitEthernet0/0/0
R1(config-if)# ip access-group LAN_TO_SERVER_POLICY in
R1(config-if)# end

Verification

Configuration is only half the battle. You must verify that the ACL is working as expected.

• Check the ACL configuration and hit counters: The show access-lists command is your most important tool. It shows the ACEs and how many packets have matched each line. Before testing, you can use clear access-list counters to reset them.

  R1# show access-lists LAN_TO_SERVER_POLICY
  Extended IP access list LAN_TO_SERVER_POLICY
      10 deny tcp host 192.168.10.10 host 192.168.20.10 eq www
      20 deny tcp host 192.168.10.10 host 192.168.20.10 eq 443
      30 deny tcp host 192.168.10.10 host 192.168.20.11 eq www
      40 deny tcp host 192.168.10.10 host 192.168.20.11 eq 443
      50 permit ip any any (56 matches)  <-- See matches for permitted traffic
  

  If you test access from PC1, you should see the counters on lines 10-40 increment.

• Confirm the ACL is applied: The show ip interface <interface_name> command will show you which ACLs are applied to an interface and in which direction.

  R1# show ip interface g0/0/0
  ...
  Inbound  access list is LAN_TO_SERVER_POLICY
  ...
  

For a comprehensive list of verification commands and troubleshooting tips, you can refer back to the "Access Control Lists (ACLs) Demystified" article, specifically the sections on Verification Commands and Structured Troubleshooting Flowchart.

Conclusion

In this lesson, we established a solid foundation for one of the most essential skills in network security. You now have the knowledge to design, configure, and verify IPv4 Access Control Lists to enforce network policies.

Key Takeaways:

• Standard ACLs filter on source IP only and are placed near the destination.
• Extended ACLs provide granular control (IPs, protocol, ports) and are placed near the source for efficiency.
• ACLS are processed top-down, and the implicit deny at the end makes an explicit final permit statement critical in most cases.
• Named ACLs are more manageable and should be preferred over numbered ACLs.
• Time-based ACLs add a layer of scheduling to your security policies by linking an ACE to a defined time-range.
• Verification using show access-lists to check hit counters is a crucial step to ensure your policy is working as intended.

Preview of the Next Lesson:

Now that we have a firm grasp of IPv4 ACLs, we will turn our attention to the next generation. In our next lesson, we will move on to implement and verify IPv6 ACLs. While the core concepts of filtering are the same, the syntax and some behaviors are different—for instance, there are no wildcard masks in IPv6 ACLs, and they are always named. We'll explore these differences and configure them in our next session.