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