Standard and Extended ACLs

It seems odd that this would even really be a concept I would be covering for IE studies.  However, there are some interesting nuances in access-lists that I still mess up from time to time.  Let’s do a quick review of the both standard as well as extended ACLs and provide some examples.

A couple of quick notes that I want to start off
-ACLs are processed top down, lowest sequence number to highest until a match for the traffic is located.  This means it’s best practice to put the most restrictive entries at the top of the ACL so they get hit earlier on in the process. 
-ACLs ALWAYS end with an implicit deny (so long as at least one other sequence is defined).  One can make the last sequence something like ‘permit ip any any’ which should match all traffic, but the implicit deny is still there

Standard ACLs
Standard ACLs ONLY match the source IP address.  Another simple concept here but one that’s worth remembering.  Note that I specify ‘IP address’ as part of that definition.  There are no other features of an IP packet or frame that a standard ACL can match on. 

Standard ACLs can be defined either by name or by number…

When defining them by number, there are two possible number ranges that can be used.  1 through 99 or 1300 through 1999.  A curious mind might ask why there’s a gap.  The output of this command explains why…

Here we can see that there are actually quite a few ACL number ranges used for other types of traffic.  It’s important to note here that this means there are two different ways to configure an ACL.  For instance, take a look at this configuration of a standard IP ACL…

Here you can see in the red box that I’m using the ‘ip access-list standard’ syntax to define the ACL.  In that method, you define the ACL and enter the NACL sub configuration mode.  Once in the sub configuration mode you define the actual ACE (Access Control Entries) for the ACL.  In the blue box, I define it all in one shot by know that the ACL number ‘2’ falls into the standard ACL range.  Looking at the finished config, you can see they are identical…

I’m not sure what the exact terminology is for the two different config modes so I refer to the first as ‘ACE based’ and the second as ‘number defined’.  Other ACL types (MAC or IP protocol for instance) don’t seem to have this same ACE based configuration leaving you with only the ‘number defined’ method of configuring them.

So getting back to the standard ACL, let’s start with a rather basic example…

Let’s say that we want router2 to prevent router1 from talking IP to router3’s loop0 interface.  Before applying the ACL, we can assume that all interface have full IP reach ability. 

I purposely used the ‘?’ throughout the configuration so you could see what options you had.  In this ACL, I’m tell the first entry to deny the ip address of 10.0.0.2 (router1).  I’m specifying the wildcard mask of 0.0.0.0 to ensure that this only affects the single IP address.  I also use the ‘log’ command on this ACE entry.  We’ll see what that does later.  The next line I tell the router to ‘permit any log’.  Since ACLs are processed sequentially, this will allow anything that doesn’t match the first entry (the deny) to pass the ACL.  Let’s apply this to an interface and see what we get…

Applying an ACL to an interface is a matter of direction.  As you can see above, we define the ACL to be used with the ‘ip access-group’ syntax.  Then we supply the name and in what direction we want the ACL applied in.  It should be noted that ‘inbound’ ACLs are the preferred method of applying ACLs since it comes early in a routers OOO (order of operations).  Best to drop the packet before doing any additional (unneeded) processing. 

As we can see, the pings aren’t going through.  Taking a look at the ACL on router2, we can see that we are getting matches on the deny (Sequence 10) ACE entry…

So while this solved our problem, it also blocked any and all traffic from 10.0.0.2 to any IP address.  For instance, router1 can no longer ping any of router2 and router3’s physical interfaces…

So this isn’t very practical.  A better idea would be to use an extended ACL that could check the destination of the packet as well as the source.  Before we move on to extended ACLs (more interesting stuff) I want to make a quick comment about the ‘log’ command.  The addition of the log command allows the router to generate log messages for the specific ACL action.  These will look this…

Note that the source shows up at 0.0.0.0.  I’m not entirely sure why that is but it’s my assumption that it’s because the standard ACL uses source addressing, so it should be pretty obvious what the source is in most cases. 

Extended ACLs
Extended ACLs take the concept of standard ACLs to a new level.  For instance, we can now use source and destination IP addresses to define the ACL.  We can fix the ACL above so that router1 can ping the link interfaces, but not the loopback address…

Testing shows that it can’t ping the loopback IP (172.16.0.1) but can ping the physical link addresses…

As you can see, the extended ACLs are far more flexible that the standard ACLs.  Not only can they look at IP source and destination, they can also examine layer 4 information…

Here I show that you can match on a specific TCP port number or a specific range of ports.  Lot’s of options here. 

I don’t want to beat the horse here, but there are a couple of configurations that I’d like to talk about that seem to confuse some people.  Direction sometimes throws some people off when using ACLs.  For instance…

If router3 here was running some kind of HTTPS server, we could apply the ACL shown above ‘inbound’ on router2’s 10.0.0.1 interface.  This would work and the 443 session would be allowed through the device. 

Now suppose that we wanted another ACL that would allow the reverse traffic (router3 to router1) to be applied on router2.  Where would it go?  What would it look like?  While this may seem trivial to many of us, there are many engineers that struggle with this concept.  The ACL could go in one of two place.  It could be applied ‘in’ router2’s 10.0.0.10 interface or ‘out’ it’s 10.0.0.1 interface.  To show that you can have both a inbound and outbound ACL on the same interface we will use the ‘out’ method on router2’s 10.0.0.1 interface. 

And this is the piece that most engineers don’t think through.  The traffic destined for router3 has a random source port and a destination of 443.  The return traffic has a source port of 443 and the random destination port.  That being said, the second rule needs to specify the port in the first half (source) of the extended ACL rather than the second have (destination). 

The last piece that I wanted to talk about is what tends to confuse people the most.  Extended ACLs have a ACE option called ‘established’.  The base premise of the established command makes perfect sense, but understanding it’s implementation is a little harder.

If the ACE is defined with the established keyword, it means that in order for the rest of that ACE line to match, the packet MUST have the ACK or RST bit set.  This gives us the ability to deny new TCP flows since the first SYN packet does not contain an ACK or RST bit.  Let’s take a simple example and walk through it…

Here we have taken a new ACL that permits all TCP traffic and added the established configuration to it.  The ACL config looks like this…

We then applied that ACL inbound on router2’s 10.0.0.1 interface.  What will the effect of this configuration be?

Let’s walk through and see.  Let’s start with router3 making a TCP session to router1. I’ll show the diagram followed by the corresponding packet…

And on router3, we see that the session completed as expected…

Now let’s try from router1 and see what happens…

The key to understanding why this only works in one direction (router3 to router1) is understanding the TCP SYN/ACK process.  As we saw from the working example above.  The first packet that gets sent in a TCP session is the initial TCP SYN packet.  So in this case, the first packet that router1 sends towards router3 is going to be a SYN packet.  The ACL that is applied ingress on router2’s 10.0.0.1 interface is checking for ‘established’ TCP sessions.  A SYN does not constitute an established TCP session. 

This emphasizes an important point with ACLs.  Direction matters!  The communication from router3 to router1 worked just fine since router2’s 10.0.0.1 interface never saw a inbound packet that didn’t have the ACK or RST bit set.  In the other direction, it does.

I know this was an easy topic, but it’s worth talking about.

Thanks for reading!