Resequencing an ACL

Here's a quick post on a very useful command when working with ACLs.  I first heard about it while watching a CBT Nugget video, and I can say that it was definitely not covered in the NetAcad curriculum when I went through the classes, because I remember bringing it up to the instructor and it was news to him.

So let's begin by setting the scenerio.  You have the following ACL:

show ip access-list EXAMPLE

Extended IP access list EXAMPLE
    1 permit ip host 10.10.10.28 any
    2 permit ip host 10.10.10.10 any
    3 permit ip host 10.10.10.11 any
    4 permit ip host 10.10.10.45 any
    5 deny ip 10.10.10.0 0.0.0.255 any
    10 permit tcp any host 192.168.10.4 eq smtp

And let's say that we now need to allow one additional host out.  We could rewrite the ACL, but that could be a lot of work if its a long ACL.  Any other options?

Yes, the resequence command can help.  This command was introduced in IOS 12.2(14)S, and allows you to easily resequence an entire ACL.

ip access-list resequence EXAMPLE 10 10

This will renumber every line in the ACL starting with 10, and with an increment of 10 between each line.  This is the default sequencing for an access-list where no sequence numbers are entered.  The end result would be:

Extended IP access list EXAMPLE
    10 permit ip host 10.10.10.28 any
    20 permit ip host 10.10.10.10 any
    30 permit ip host 10.10.10.11 any
    40 permit ip host 10.10.10.45 any
    50 deny ip 10.10.10.0 0.0.0.255 any
    60 permit tcp any host 192.168.10.4 eq smtp

Old documenation will tell you that you can't edit a numbered ACL, but that's actually not true anymore.  

Reflexive ACLs on IOS Routers

In a nutshell, reflexive ACLs allow packets to be evaluated based on upper layer session information. You use reflexive ACLs in order to permit the return traffic from an established session, but deny all other traffic in that direction.  For example, you open up a browser and establish an HTTPS session with www.awesomewebsite.com.  Now obviously, you want the return traffic from the server hosting awesomewebsite.com to make it back to you so you can see this awesome website.  But you also do not want malicious traffic trying to reach your workstation to come in with it.  A standard or extended ACL does not allow this, it's all or nothing.  But a reflexive ACL allows you to do exactly that, allow the return traffic from your session with awesomewebsite.com, but deny all other incoming traffic.  I've heard reflexive ACLs described as "a poor man's stateful firewall."

Cisco documentation points out that you can also configure it in the other direction.  You can, for example, allow all incoming traffic to a server in your DMZ, but only allow return traffic from that server to go back out to the Internet. In this example, external users would be able to view the content on your DMZ server, but it would mitigate the risk of your server becoming part of a botnet and eat up your upload bandwidth participating in a DDoS attack.  While possible, I doubt it's used very often.  So in the configuration example, we'll focus on the more common scenario.

So lets configure a reflexive ACL.  We'll start out with a basic ACL in the outbound direction which will allow all outbound traffic.  As typical, I'll use upper case letters for words and names I've created so they stand out as such when viewing show statements. 

ip access-list extended OUTBOUND
  permit ip any any reflect REFLECTED

And that's it.  In this ACL, we are allowing all outbound traffic. The difference here between this ACL and no ACL at all is the keyword reflect.  This tells the router to remember all traffic matched by the permit ip any any, and create a dynamic ACL for the return traffic that will be allowed.  But we're not limited to this single permit in the OUTBOUND ACL, we can combine that with any combination of permit and deny statements as needed.  Note that reflexive ACLs can only be used as part of extended named ACLs.   But other than that, you're pretty much only limited by your imagination.

ip access-list extended OUTBOUND
  permit tcp host 10.10.10.10 any eq smtp REFLECTED
  deny tcp any any eq smtp
  permit ip any any reflect REFLECTED

Here, we're denying outbound smtp except from a single host (the company email server), and then allowing all other traffic to go out reflected. Next, we'll create a basic ACL for the inbound direction.

ip access-list extended INBOUND
  evaluate REFLECTED

Again, we're not limited to just a single evaultate statement in this ACL either, we can add in any other needed statements allowed by a named ACL.

ip acess-list extended INBOUND
  evaluate REFLECTED
  permit any host 10.10.10.10 eq smtp
  permit any host 10.10.10.10 eq http

Now we just need to apply those lists to the outward facing interface of the router.

interface Ethernet 1/0
  ip access-group INBOUND in
  ip access-group OUTBOUND out

If you have multiple outward facing interfaces, you can apply these same ACLs to multiple interfaces and the same REFLECTED dynamic list will be maintained between them, shielding you from the side effects of asymmetric routing.  Now if Cisco would only give us a way to share the state of reflexive ACL's between different routers (one pointed at ISP1 and one pointed at ISP2 for example), then we'd be all set.

interface Ethernet 1/0
  ip access-group INBOUND in
  ip access-group OUTBOUND out
!
interface Ethernet 1/1
  ip access-group INBOUND in
  ip access-group OUTBOUND out