Skip to main content
Back to path

Welcome to a Grasp lesson

Create a free account to keep studying and create your own study path.

Lesson 27

Filtering Traffic with ACLs on SVIs

Recommended resources

Introduction

Welcome back! In our last few lessons, we've successfully built a multi-VLAN network and configured the Layer 3 switches to route traffic between them using Switched Virtual Interfaces (SVIs). As it stands, your Sales VLAN can communicate freely with the Engineering VLAN, and vice-versa. While this proves our routing works, it represents a significant security gap. In a real-world enterprise network, you don't want unrestricted access between all departments.

This lesson introduces the first line of defense in a segmented network: Access Control Lists (ACLs). Our learning outcome is to explain how Access Control Lists (ACLs) filter traffic between subnets at the SVI. We'll transform the SVIs from simple gateways into intelligent security checkpoints that inspect and control the traffic passing between your VLANs.

The Fundamentals of an Access Control List

At its core, an ACL is simply a list of rules that a switch or router processes in sequential order. Think of it as a bouncer's guest list for your network traffic. When a packet arrives at an interface with an ACL applied, the device checks the packet against each rule, one by one, from top to bottom.

Here are the three unbreakable laws of ACLs:

  1. Top-Down Processing: The device checks the first rule. If the packet matches, the rule's action (permit or deny) is taken, and the process stops. The device doesn't look at any other rules in the list.
  2. First Match Wins: As soon as a packet matches a rule, that's it. No further rules are consulted. This makes the order of your ACL statements critically important.
  3. The Implicit Deny: If a packet makes it all the way to the end of the list without matching any of your rules, it is automatically dropped. This is called the "implicit deny all." If you don't explicitly permit something, it will be denied.

For a concise summary of these core principles, please read the following section from the "ACLs Demystified" article.

Access Control Lists (ACLs) Demystified for the CCNP 350-401 ...

This section lays out the fundamental processing logic of ACLs, including the top-down evaluation, the 'first match wins' principle, and the all-important implicit deny rule.

Read the section titled 'ACL Fundamentals'. Pay close attention to the explanation of top-down processing and the concept of the implicit deny.

Standard vs. Extended ACLs

While there are several types of ACLs, our focus will be on Extended ACLs.

  • Standard ACLs: Basic filters that only look at the source IP address. They are less common in modern networks because they are not very granular.
  • Extended ACLs: Powerful filters that can inspect multiple criteria:
    • Source IP address
    • Destination IP address
    • Protocol (e.g., TCP, UDP, ICMP)
    • Source and Destination Port numbers (e.g., TCP port 80 for HTTP, TCP port 22 for SSH)

This level of detail allows us to create highly specific security policies, which is exactly what we need for controlling inter-VLAN traffic.

The SVI as a Security Checkpoint

In our network design, for a packet to get from a host in VLAN 10 to a host in VLAN 20, it must be routed by the Layer 3 switch. The packet's journey looks like this:

  1. PC in VLAN 10 sends the packet to its default gateway (the SVI for VLAN 10).
  2. The Layer 3 switch receives the packet on the logical interface Vlan10.
  3. The switch performs a routing lookup and determines the packet needs to be sent to VLAN 20.
  4. The switch forwards the packet out of the logical interface Vlan20 to the destination host.

The critical insight here is that the traffic transits the SVI. This makes the SVI the perfect place to apply an ACL to filter traffic as it's being routed between subnets.

ACLs on Switches: Inter-VLAN Filtering
This diagram illustrates how traffic from Host A in VLAN A must pass through the logical SVI to be routed to Host B in VLAN B. The ACL is applied directly to this SVI, acting as a filter for any traffic being routed through it.

Inbound vs. Outbound: A Critical Distinction

When you apply an ACL to an interface, you must specify a direction: in or out. On a logical SVI, this can be tricky, but it follows a clear logic:

  • Inbound (in): Filters traffic coming from hosts within that VLAN, as it enters the SVI to be routed elsewhere.
  • Outbound (out): Filters traffic coming from other networks, as it exits the SVI to be delivered to a host within that VLAN.

The article below provides an excellent explanation of this concept, which often trips up even experienced engineers.

Back to Basics - Access List, a tale as old as time. - LookingPoint

This article specifically addresses the common confusion around applying ACLs to SVIs. It clearly defines what 'inbound' and 'outbound' mean in this context.

Read the section that begins with 'Simple put, if you’re trying to filter traffic sourced from the vlan...'. Focus on understanding the traffic flow relative to the SVI.

A core best practice is to place extended ACLs as close to the source of the traffic as possible. This is efficient; you deny unwanted traffic early, so the switch doesn't waste resources routing a packet that will just be dropped later.

For inter-VLAN filtering, this means we will typically apply an inbound ACL on the source VLAN's SVI.

Practical Application: Configuring an Extended ACL on an L3 Switch

Now let's see how this all comes together. The following video provides a step-by-step demonstration of creating and applying an extended ACL on a Cisco L3 switch to filter traffic between two VLANs.

The scenario in the video is:

  • Goal: Allow PCs in VLAN 10 to ping PCs in VLAN 20, but block them from using SSH to connect to PCs in VLAN 20.
  • Source: VLAN 10
  • Destination: VLAN 20

Watch how the presenter translates this policy into ACL rules, applies it to the correct SVI in the correct direction, and then tests it. Pay special attention to the troubleshooting segment—it highlights a very common configuration mistake.

How to Set up Extended ACLs on a Cisco L3 Switch | CCNA Security | Access Control List Configuration

This video by Paolo Reyes walks through the entire process of configuring an extended ACL on an L3 switch to filter traffic between two VLANs. This is a direct, practical application of the concepts we've discussed.

Watch the video from the beginning to 10:44. Focus on these key steps: The explanation of how extended ACLs work (0:00 - 1:39). The logic for placing the ACL close to the source (3:00 - 4:16). The CLI commands used to build the permit/deny statements, including the use of protocol and port numbers (5:46 - 8:59). The troubleshooting step where a wildcard mask is corrected. This is a valuable lesson in itself (8:59 - 10:44).

As you saw, the logic follows our principles exactly:

  1. Rule 1: permit icmp (Ping) from VLAN 10's subnet to VLAN 20's subnet.
  2. Rule 2: deny tcp (SSH) from VLAN 10's subnet to VLAN 20's subnet with a destination port of 22.
  3. Rule 3: permit ip any any to allow all other traffic and override the implicit deny.
  4. Application: The ACL is applied inbound on interface Vlan10, the SVI for the source traffic.

Practical Exercise

Now it's your turn. Let's use the network plan we've been developing. Imagine you have a new security requirement:

Policy: Hosts in the Sales VLAN (10) should be blocked from accessing a web server in the Engineering VLAN (20). All other traffic between the VLANs is currently allowed.

  • Sales VLAN Subnet: 172.20.0.0/23
  • Engineering Web Server IP: 172.20.2.100
  • Web traffic uses HTTP (TCP port 80).

Your task is to design the ACL. Write down the following:

  1. The Cisco IOS commands for the access-list statements in the correct order. Use a named ACL called SALES_FILTER.
  2. The interface where you would apply this ACL.
  3. The full command used to apply the ACL to the interface, including the direction.
Click to see the solution

  1. ACL Statements:
    The key is to deny the specific traffic first, then permit everything else. The wildcard mask for a /23 is 0.0.1.255.

    ip access-list extended SALES_FILTER
 10 deny tcp 172.20.0.0 0.0.1.255 host 172.20.2.100 eq 80
 20 permit ip any any
    • Line 10: This rule specifically denies TCP traffic coming from any host in the Sales subnet (172.20.0.0/23) destined for the single Engineering web server (172.20.2.100) on port 80 (HTTP).
    • Line 20: This is the crucial "permit all else" rule. Without this, the implicit deny would block all traffic from Sales, including pings, DNS, etc.

  2. Interface:
    To filter the traffic as close to the source as possible, you would apply the ACL to the SVI for the source network: interface Vlan10.

  3. Application Command:
    The traffic is coming from the Sales VLAN and entering the SVI to be routed. Therefore, the direction is inbound.

    interface Vlan10
 ip access-group SALES_FILTER in

Conclusion

In this lesson, we've explored how ACLs function as the primary tool for filtering traffic between the subnets and VLANs we've designed. By applying extended ACLs to the SVIs that act as default gateways, you gain granular control over exactly what communication is permitted.

Key Takeaways:

  • ACLs are sequential lists of permit/deny rules that are processed from top to bottom.
  • The "implicit deny all" at the end of every ACL means that any traffic not explicitly permitted is blocked. Always remember to add a permit ip any any at the end of your list if you don't want to break connectivity.
  • Extended ACLs provide granular control by filtering on source/destination IPs, protocols, and port numbers.
  • The SVI is the logical enforcement point for inter-VLAN security.
  • Applying an ACL inbound on the source VLAN's SVI is the most efficient way to enforce a security policy.

Next Steps

You now understand the mechanics of how an ACL filters traffic. The next step is to move from a single rule to a complete security policy. In our next lesson, we will focus on how to translate a written security policy into a sequence of ACL permit/deny statements, allowing you to build comprehensive rule sets that match your organization's security requirements.