ll use type numbers). The temporary entry will be removed after the last packet is seen (usually a FIN or RST). The temporary entry will expire if no traffic is seen for a configurable amount of time (the default is five seconds). You cannot create a reflexive access list that allows one protocol when another is detected. For example, you cannot allow HTTP inbound because a telnet was initi- ated outbound. If you want to reflexively allow HTTP inbound, you must test for HTTP outbound. Because the port numbers in the temporary entries are always the reverse of the port numbers from the original traffic, they are not suitable for protocols such as RPC that change source port numbers. Reflexive ACLs are also not suitable for protocols that create new streams such as FTP. FTP can still be used with reflexive access lists, provided passive mode is used. Configuring Reflexive Access Lists Reflexive access lists are a bit more complicated than regular access lists because you must nest one ACL within another. Consider the need to test for two types of traffic: the original request, and the resulting reply. An ACL must be created for each test. The ACL for the reply is created dynamically when the ACL for the original request is matched. Cisco calls the way that reflexive access lists are configured nesting, though the configuration doesn't look like nested code to most programmers. Continuing with the preceding example, let's create a reflexive access list for telnet. We want host A to be able to telnet to host B, but we'll deny everything else. This scenario is overly restrictive for most real-world applications, but it'll help illustrate the functionality of reflexive access lists. To configure reflexive access lists, we must create one ACL for outbound traffic, and one for inbound traffic. First, we'll create a named access list called TelnetOut: ip access-list extended TelnetOut permit tcp host 10.0.0.10 host 20.0.0.20 eq telnet reflect GAD deny ip any any Chapter 23: Access Lists Reflexive access lists can only be 