Reflexive access-list are one of the method that help us achive firewall functionality with a router hardware. The other methods that serve to the same purpose are Context-Based Access Control (CBAC) and TCP Intercept. For an introduction to CBAC with example please check my older post Cisco: Use CBAC to achieve firewall functionality on router device . For TCP Intercept check my blog in the next weeks.
Today, I will present Reflexive access-list and how can take advantage of their specific behavior. Reflexive access list commands are used to configure IP session filtering. IP session filtering provides the ability to filter IP packets based on upper-layer protocol “session” information. They are generally used to allow outbound traffic and to limit inbound traffic in response to sessions that originate inside the router. E.g. you want to allow a TCP connection from outside only is the initall packet was send from the inside. Take FTP active mode session on data port TCP 20. If you are doing FTP from inside the LAN port 20 will be allowed outbound and also inbound. But if somebody from outside try to reach one device on your LAN on port 20, the session will be dropped due to Access-list implemenation.
Reflexive ACLs can be defined only with extended named IP ACLs. They cannot be defined with numbered or standard named IP ACLs, or with other protocol ACLs. Reflexive ACLs can be used in conjunction with other standard and static extended ACLs. As a syntax Reflexive access-list are presented exactly like any normal ACL, with the implementation of two parameters “reflect” and “evaluate”.
Let have a look to this example topology. R2 will be the router where the Reflexive ACL has to be implemented. The implementation is quite simple. You configure an outbound access-list which permit tcp sessions from any subnet to any subnet. The difference from this outbound ACL and a normal one, will be the “reflect” parameter at the end on the permit line. The “reflect” parameter will have the name OUT (it can be any name you want).
After the outbound list is completed configured, then we will configure an inbound access-list with a “permit tcp any any” statement followed by the parameter “evaluate OUT”. Below it’s a simple example how to configure this Reflexive ACL on the topology presented above, to permit UDP and TCP inside only if the session was initiated from inside:
ip access-list extended OUTBOUND
permit tcp any any reflect TO_REFLECT
permit udp any any reflect TO_REFLECT
ip access-list extended INBOUND
evaluate TO_REFLECT
interface Serial1/0
ip access-group OUTBOUND out
ip access-group INBOUND in
So, the INBOUND ACL will evaluate OUTBOUND ACL to permit or deny TCP packet from outside. Remember that by default, packets generated by the router itself will not be
reflected. This is why if you have a routing protocol running towards outside, on your router you have to permit static those packets. Let’t take the example of the BGP routing protocol. Assume that you have a BGP peering between R2 and R3. On R2 you will have to permit static the BGP packets from outside, like in the example below:
ip access-list extended OUTBOUND
permit tcp any any reflect TO_REFLECT
permit udp any any reflect TO_REFLECT
ip access-list extended INBOUND
permit tcp any any eq bgp
permit tcp any eq bgp any
evaluate TO_REFLECT
interface Serial1/0
ip access-group OUTBOUND out
ip access-group INBOUND in
In this way the BGP packets local generated on the router, will be allowed IN and OUT on the WAN interface. You will proceed in the same way for other packets that are generated on the router and you want to allow them to pass through WAN interface.
For a live example please see the video presentation below. If you did not had a look to the example topology, now it would be a good time to do it. Already I have preconfigured BGP AS 300 on router R3 and BGP AS100 on R2 and R1, so the conectivity from R1 to R3 is not a problem. Also R1 and R3 have a Loopback interface which is advertised into BGP. After implementing the Reflexive ACL on R2 I will be allow to telnet from R1 to R3, but not viceversa. Also the BGP packets between R2 and R3 will be static permited in ACL.
I hope that I could helped you to understand the importance on the Reflexive ACL. Sometime simple ACL would do the job and then I would suggest not to complicate things. But if you have something tricky to solve regarding access in your LAN, or you prepare for some exam like CCIE, then Reflexive ACL are quite useful and important.
The IETF is forming a new working group to address scalability issues in the Internet’s routing system caused by companies splitting their network traffic over multiple carriers, a practice called multihoming.