Inter-VLAN Security with ACLs

1. ACL Fundamentals: The "What" and "Why"

An Access Control List (ACL) is a sequence of rules, known as Access Control Entries (ACEs), that are processed in order from top to bottom. Each rule either permits or denies traffic based on a set of criteria. On a Layer 3 switch, ACLs are the mechanism we use to filter traffic as it gets routed between VLANs.

Before we start writing them, let's cover the foundational concepts.

To summarize the key takeaways:

• Standard ACLs: Filter only on the source IP address. They are less flexible and are generally used for simple tasks like restricting management access.
• Extended ACLs: Filter on source and destination IP, protocol (TCP, UDP, ICMP), and source/destination port numbers. This granular control makes them the tool of choice for implementing detailed inter-VLAN security policies. We will focus almost exclusively on extended ACLs.
• Named vs. Numbered: You can identify an ACL with a number (e.g., 101 for an extended ACL) or a descriptive name (e.g., FINANCE_OUTBOUND). Best practice, especially in a large architecture, is to use named ACLs for clarity.
• The Golden Rules:
  1. Rules are checked sequentially.
  2. The first rule that matches the packet is applied.
  3. Processing stops after the first match.
  4. If no rule matches, the packet is dropped due to the implicit deny any rule at the end.

For a quick reference, the article "Advanced IPv4 Access Control Lists" provides a solid text summary of these fundamentals.

2. Applying ACLs to Control Inter-VLAN Traffic

Now that we know what ACLs are, where do we apply them? In our L3 distribution design, the perfect place is on the Switched Virtual Interfaces (SVIs). Since the SVI is the gateway for its VLAN, any traffic attempting to leave its own VLAN to be routed to another must pass through its SVI. By placing an ACL on the SVI, we intercept and filter all inter-VLAN traffic.

When you apply an ACL to an interface, you must specify a direction: in or out.

• Inbound (in): The ACL is checked as soon as a packet arrives at the SVI, before the switch makes a routing decision.
• Outbound (out): The ACL is checked after the switch has made a routing decision and is about to send the packet out toward its destination VLAN's SVI.

Best Practice: For Extended ACLs, the rule of thumb is to apply them as close to the source of the traffic as possible. In our inter-VLAN routing scenario, this means applying the ACL inbound on the SVI of the source VLAN. This is more efficient because it filters unwanted traffic before the switch wastes CPU cycles on a routing lookup.

This next video demonstrates this principle in action.

3. Translating Policy to Configuration

This is where your work as an architect comes into play. You'll be given a set of business or security requirements, which you must translate into a precise sequence of ACL commands.

Let's use the Aperture Logistics VLAN plan to work through an example.

Scenario: We need to implement the initial security policy for the Finance and Operations departments.

• Network Info:

  • Finance VLAN 115: 10.15.0.0/23
  • Operations VLAN 120: 10.20.0.0/22
  • Servers VLAN 50: 10.50.0.0/22

• Security Policy:

  1. The Finance department must be able to access all servers in the Servers VLAN.
  2. The Finance department is strictly prohibited from accessing any resources in the Operations VLAN.
  3. All other traffic from the Finance department is permitted (for now).

We will create an ACL named FINANCE_IN and apply it inbound to interface Vlan115.

Step 1: Permit Required Traffic

The first rule should explicitly permit what is allowed. We need to allow traffic from the Finance subnet to the Servers subnet.

The wildcard mask is the inverse of the subnet mask.

• For Finance (/23 or 255.255.254.0), the wildcard is 0.0.1.255.
• For Servers (/22 or 255.255.252.0), the wildcard is 0.0.3.255.

If you need a refresher on wildcard masks, refer to the "Calculating and Using Wildcard Masks" section in the AlphaPrep article we looked at earlier.

The command would be:
permit ip 10.15.0.0 0.0.1.255 10.50.0.0 0.0.3.255

Step 2: Deny Prohibited Traffic

The second rule should deny what is forbidden. We need to block traffic from Finance to Operations.

The command would be:
deny ip 10.15.0.0 0.0.1.255 10.20.0.0 0.0.3.255

Step 3: Allow Everything Else

Finally, to override the implicit deny, we add a rule to permit all other traffic originating from the Finance VLAN.

The command would be:
permit ip any any

Putting It All Together

Here is the complete configuration block for our policy:

! Enter global configuration mode
conf t

! Create the named extended ACL
ip access-list extended FINANCE_IN

  ! Add a remark for documentation
  remark ACL for traffic originating from the Finance VLAN
  
  ! 10: Permit access to the Server VLAN
  permit ip 10.15.0.0 0.0.1.255 10.50.0.0 0.0.3.255
  
  ! 20: Deny access to the Operations VLAN
  deny ip 10.15.0.0 0.0.1.255 10.20.0.0 0.0.3.255
  
  ! 30: Permit all other traffic
  permit ip any any

! Apply the ACL to the Finance SVI
interface Vlan115
  ip access-group FINANCE_IN in

end

The case study at the end of the AlphaPrep article provides another excellent, real-world example of building ACLs from requirements for multiple VLANs.

4. Practical Design Exercise: Securing the Management VLAN

Now, let's have you design a policy. This is one of the most important security controls in any network: restricting access to the dedicated network management VLAN.

• Network Info:

  • IT Admins VLAN 110: 10.10.0.0/24
  • Network Management VLAN 99: 10.99.0.0/24

• Security Policy:

  1. Only users in the IT Admins VLAN are allowed to initiate SSH connections (TCP port 22) to devices in the Network Management VLAN.
  2. Devices in the Network Management VLAN (like monitoring servers) must be able to send ICMP echo requests (pings) to any other device on the network and receive replies.
  3. No other traffic should be allowed to be initiated from other VLANs into the Management VLAN.

Your task is to design an extended ACL named MGMT_IN that will be applied inbound on interface Vlan99. Think through the rules you would need.

ip access-list extended MGMT_IN
 remark --- ACL to protect the Network Management VLAN ---

 remark 10: Permit SSH initiated from IT Admins
 permit tcp 10.10.0.0 0.0.0.255 10.99.0.0 0.0.0.255 eq 22

 remark 20: Permit ICMP replies back into the VLAN (for pings initiated from MGMT)
 permit icmp any any echo-reply

 remark 30: Permit return traffic for any other established TCP connections
 permit tcp any any established

 remark 40: Explicitly deny and log all other traffic
 deny ip any any log

Conclusion

Today, you've taken a major step from network connectivity to network security. You've learned how to use extended Access Control Lists as a precise tool to enforce security policies in a multi-VLAN environment.

Key Takeaways:

• ACLs are the foundation of network security, acting as filters on routed interfaces.
• Extended Named ACLs are the best practice for creating clear, granular, and manageable inter-VLAN security policies.
• ACLs are applied to SVIs to control traffic between VLANs. The best practice is to apply them inbound on the source VLAN's SVI.
• A security policy is a list of requirements that you must translate into a specific sequence of permit and deny statements.
• The log and established keywords are powerful tools for troubleshooting and creating more secure, stateful-like filtering rules.

Preview of the Next Lesson:
We have designed the ACLs on paper. The next logical step is to implement and verify them. In our next lesson, we will focus on applying ACLs and verifying their operation. We will dive deeper into the importance of statement order, explore common troubleshooting scenarios, and use show commands to confirm that our security policies are working exactly as intended.