Blog

Access lists and SVIs have been around forever, and while applying access lists to physical interfaces seems to logically sink it quite easily, access lists on SVIs interfaces seem to trip people up. This blog will cover that scenario as well as some other access list basics, hopefully by the end you’ll find the concepts cemented.

For various reasons there may be a need to restrict or isolate traffic from one network to another. Access lists are a series of permit or deny statements which are applied at boundary points in your network. You may be familiar with obvious boundary points, like physical interfaces, but you can also apply them on Switched Virtual Interfaces, which are logical interfaces commonly found on L3 switches, or as a sub-interface on a physical interface. Historically routers have been used to route between subnets/vlans, but with the advent of L3 switches, much of the inter-vlan routing was brought closer to the core or distribution layer of the network. I’ve pasted the topology for this exercise below.

First, let’s cover some of the basics and the best practices, then we’ll dive into some configuration examples.

As a rule of thumb, you’ll want to place your access list as close to the source of the traffic as possible. In our case, the switch at each site is configured as the default gateway for each access vlan. We’ll put the access lists on these devices.

ACLS (Access-lists) come in 2 flavors, standard and extended. Standard access lists are basic in the sense you can permit or deny from a single host/network, but you can’t specify Source and Destination or specific protocols. Extended ACLs will allow the granular definition of Source and Destination, as well as a protocol. This is what we’ll be using to filter ICMP from specific networks.

ACLs are processed sequentially from top down, and if no entries are matched, they hit an implicit deny at the bottom (not seen if you do a show command, just know it’s there). Therefore, my examples show a ‘permit ip any any’ entry at the end, this way matched ICMP traffic is dropped, but everything else is permitted. You don’t want to forget that, or ALL traffic would get blocked, not good if you’re applying in a production environment. 😊

Most communication between endpoints is a back-and-forth series of incoming and outgoing packets. By applying an access list in a single direction at a single site you could technically break most communication between the two endpoints. For example, in our example we intend to block ICMP, if we apply an access list filtering only ICMP traffic from SITE1-PC1 to SITE2-PC, then issue the ping command from SITE1-PC1, the traffic will never make it across to SITE2, it would be dropped right there on the SITE1 switch. However, if you were to initiate the ping from SITE2-PC to SITE1-PC1, the ICMP echo would make its way all the way to SITE1-PC1, it would attempt to reply but the reply would be dropped as soon as that packet hit the SITE1 switch. While the end goal would still be accomplished, this would be considered a bad practice as it may create unnecessary network traffic. To avoid this scenario, we will create an access list at each site. Let’s look at the ACLs for each site, notice how the source and destination are reversed?

SITE1 ACL

!

access-list 100 deny   icmp 10.0.1.0 0.0.0.255 20.0.1.0 0.0.0.255

access-list 100 permit ip any any

!

SITE2 ACL

!

access-list 100 deny   icmp 20.0.1.0 0.0.0.255 10.0.1.0 0.0.0.255

access-list 100 permit ip any any

!

Let’s consider our first objective, restricting ICMP from SITE1-PC1 to SITE2-PC. Best practice mentioned above dictates applying the access list as close to the source as possible, we can’t apply on the gi0/1 interface as it’s a L2 interface with only vlan1 assigned to it, the next closest spot would be the VLAN1 SVI on SITE1-SW. We’ll eventually apply to the SVI but first, for demonstration purposes, let’s first discuss applying the access list on a physical interface. If we apply the access list to SITE1-SW Gi0/0, we naturally might identify the direction as outbound, it’s intuitive to visualize the packet flowing from SITE1-PC1, to the SITE1-SW, then getting routed OUT gi0/0 toward its destination. We could also apply the ACL on SITE1-RTR inbound on its Gi0/0 interface, in that case the ICMP echo request would flow from SITE1-SW toward SITE1-RTR and arrive on its physical interface INBOUND. So far straight forward, right?

I’ve removed the ACL from SITE1-SW’s Gi0/0 interface, now let’s discuss access lists and SVIs. When I was a young network engineer, I couldn’t understand why my SVI applied access lists would never work. Nothing would match and it would be very frustrating, it turns out I was fundamentally wrong with my logic of their application.

Simple put, if you’re trying to filter traffic sourced from the vlan, inbound would be from traffic inside the vlan, and outbound would-be traffic being sent into the vlan from another network. For example, in my diagram, if you wanted to create an ACL at SITE1, but have the source be 20.0.1.11 and the destination be 10.0.1.11, you’d create your ACL, then apply to the SVI as OUTBOUND, out into the local vlan.

For example, in our example above, where we’re sourcing from 10.0.1.0/24, we’ll want to apply the access list to vlan 1 SVI inbound. The traffic to the SVI is coming IN to the SVI from an IP inside the vlan. 

As you can see, PC1 tries to send the echo request, it gets to SITE1-SW which then applies the access list and drops the packet. It sends an unreachable packet back to PC1. So far so good!

If you try and ping from SITE2-PC to SITE1-PC1, the ping times out, this is good, it seems like we’ve almost accomplished our goal, but hang on, we can still ping the SITE-SW1 VLAN1 SVI which is technically in the same subnet as the ACL we created, what gives?

The reason for this behavior is due to how packets are processed by the device with the ACL applied, the ICMP traffic sourced from SITE2-PC isn’t passing through the SITE1-SW, or in other words, it’s not transiting in and out of the switch, it’s hitting an address on the switch itself. That traffic is not being processed in the same fashion traffic transiting would be, it’s not subject to the ACL applied to the SVI.

To fully filter ALL traffic to a specific subnet, you should apply the ACL either at both sites or at an upstream boundary point, like the routers. Which goes against the ‘closest to the source’ best practice. Sometimes you have to compromise with where you apply the access list.

Since our network is small enough, let’s apply the access lists inbound on Gi0/0 on both SITE1-RTR and SITE2-RTR and test. I’ve removed the access list from VLAN 1 SVI. See below for configurations (note how the source/destination are inversed between the sites).

SITE1-RTR Configuration

SITE2-RTR Configuration

Let’s Test! First I’ll try to ping the other site’s SVI, then the PC.

SITE1-PC1

SITE2-PC

There you have it! We’re restricted access between 10.0.1.0/24 and 10.0.2.0/24 with access lists. I hope this has been informative and helped you with your access list needs!

As always, if you have any questions on any IT solutions set up for you and your business and would like to schedule a free consultation with us, please reach out to us at sales@lookingpoint.com and we’ll be happy to help!