Tech Tip: Manage session traffic with reflexive ACLs

Learn how to manage session traffic with reflexive ACLs.

By Mike Mullins

Network administrators use reflexive access control lists (also known as IP-session-filtering ACLs) to allow IP traffic for sessions originating from your network while denying IP traffic for sessions originating outside your network. These ACLs allow the router to dynamically manage session traffic.

The router examines the outbound traffic. When it sees a new connection, it adds an entry to a temporary ACL to allow replies back in.

This is where most people say that the top entry in their access list is to permit established traffic. However, this approach doesn't work with UDP or ICMP traffic, and it doesn't work with applications that dynamically alter the source port for the session traffic. The permit established statement only checks ACK and RST bits—not source and destination address.

Reflexive ACLs also work for UDP and ICMP, which have no ACK or RST bits. They force the reply traffic from the destination of a known recent outbound packet to go to the source of that outbound packet. This adds greater control to what traffic you allow into your network and increases the capabilities of extended access lists.

How reflexive ACLs work

Let's look at an example. On the outside interface of your router, your ACLs would look something like the following:

ip access-group inbound in
ip access-group outbound out

The outbound ACL performs the evaluation and manages session state with the following statements:

ip access-list extended outbound
permit tcp any reflect tcpsession
permit udp any reflect udpsesion

This simple ACL permits all outbound TCP and UDP traffic, and it dynamically creates two new reflexive lists for TCP and UDP traffic. As it initiates TCP and UDP traffic from inside your network, it creates temporary ACLs to manage that session traffic.

The corresponding inbound ACL evaluates the inbound traffic against initiated traffic. For example:

ip access-list extended inbound
permit bgp any any
permit tcp any host your.mailserver.address eq smtp
permit tcp any host your.webserver.address eq http
deny icmp any any
evaluate tcpsession
evaluate udpsession

Once you've applied these ACLs to your external interface, they will allow an inbound packet into the network if it matches a permit statement. (In this example, I've allowed mail and Web traffic.) Otherwise, they filter all inbound traffic against the TCP and UDP reflexive lists.

By default, the length of time an entry remains in the reflexive list is 300 seconds—or whenever the session terminates. I recommend changing this value to something more reasonable. Use the following command:

ip reflexive-list timeout seconds  ! seconds value can be 0 - 2,147,483

How reflexive ACLs fail

Reflexive ACLs don't work with applications that use port numbers that change during a TCP session. If the port number for a return packet is different from the originating packet, the reflexive ACL will deny the return packet—even if the packet is actually part of the same session.

Active FTP is an example of an application with changing port numbers. With reflexive ACLs, if you start an active FTP request from within your network, it won't associate the inbound packets with the FTP session, and it will deny the packets. You must use Passive FTP when originating requests from within your network.

Final thoughts

The purpose of a reflexive ACL is to enhance the capabilities of your extended ACLs. Keep in mind that they evaluate session state and are not a replacement for firewalls.

Mike Mullins has served as a database administrator and assistant network administrator for the U.S. Secret Service. He is a Network Security Administrator for the Defense Information Systems Agency.

Editor's Picks

Free Newsletters, In your Inbox