Request Reply Figure 23-3. Simple network without ACLs Say we want host A to be able to telnet to host B, but we don't want host B to be able to telnet to host A. If we apply a normal inbound access list to interface E1 on the router, we allow A to contact B, and prevent B from contacting A. Unfortunately, we also prevent B from replying to A. This limitation is shown in Figure 23-4. This is too restrictive for our needs. While we've secured host A from host B's advances, we've also denied host A useful communications from host B. What we need is for the router to act more like a firewall: we need the router to deny requests from host B, but we want host B to be able to reply to host A's requests. Reflexive access lists solve this problem. Chapter 23: Access Lists Inside ACL applied inbound Outside 10.0.0.0/24 20.0.0.0/24 Request Reply Request Figure 23-4. Simple access list applied inbound on E1 Reflexive access lists create ACLs on the fly to allow replies to requests. In this exam- ple, we'd like to permit traffic from B, but only if traffic from A is detected first. Should B initiate the traffic, we do not want to permit it. This concept is shown in Figure 23-5. Inside Reflexive ACL applied Outside 10.0.0.0/24 20.0.0.0/24 Request Reply Request Figure 23-5. Reflexive access list applied to E1 Reflexive access lists create temporary permit statements that are reflections of the original statements. For example, if we permit telnet outbound, a temporary permit statement will be created for telnet inbound. Reflexive access lists are very useful, but they do have some limitations: The temporary entry is always a permit, never a deny. The temporary entry is always the same protocol as the original (TCP, UDP, etc.). The temporary entry will have the opposite source and destination IP addresses from the originating traffic. Reflexive Access Lists The temporary entry will have the same port numbers as the originating traffic, though the source and destination will be reversed (ICMP, which does not use port numbers, wi