Network administrators use reflexive access control lists (also known as IP-session-filtering ACLs) to allow IP traffic for sessions originating from their network while denying IP traffic for sessions originating outside the 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 your.network.address any reflect tcpsession permit udp your.network.address any reflect udpsession
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.
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.
Miss a column?
Check out the Security Solutions Archive, and catch up on the most recent editions of Mike Mullins' column.
Worried about security issues? Who isn't? Automatically sign up for our free Security Solutions newsletter, delivered each Friday, and get hands-on advice for locking down your systems.
Mike Mullins has served as an assistant network administrator and a network security administrator for the U.S. Secret Service and the Defense Information Systems Agency. He is currently the director of operations for the Southern Theater Network Operations and Security Center.