 lists are dynamic filters that allow traffic based on the detection of traffic in the opposite direction. A simple example might be, "only allow Telnet in- bound if I initiate Telnet outbound." When I first explain this to junior engineers, I often get a response similar to, "Doesn't it work that way anyway?" What confuses many people is the similarity of this feature to Port Address Translation (PAT). PAT only allows traffic inbound in response to outbound traffic originating on the network; this is due to PAT's nature, in which a translation must be created for the traffic to pass. Reflexive access lists are much more powerful, and can be applied for different reasons. Without PAT, a filter denies traffic regardless of other traffic. Consider the network in Figure 25-3. There are two hosts, A and B, connected through a router. The router has no access lists installed. Requests from host A to host B are answered, as are requests from host B to host A. Inside Outside 10.0.0.0/24 20.0.0.0/24 Request Reply Request Reply Figure 25-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 illustrated in Figure 25-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. Reflexive access lists create ACLs on the fly to allow replies to requests. In this example, 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 25-5