Troubleshooting ACLs
When you finish the ACL configuration, use the show commands to verify the configuration. Use the show access-lists command to display the contents of all ACLs, as demonstrated in Example 6-13. By entering the ACL name or number as an option for this command, you can display a specific ACL. To display only the contents of all IP ACLs, use the show ip access-list command.
Example 6-13 Verifying Access List Configuration
RouterX# show access- lists Standard IP access list SALES 10 deny 10.1.1.0, wildcard bits 0.0.0.255 20 permit 10.3.3.1 30 permit 10.4.4.1 40 permit 10.5.5.1 Extended IP access list ENG 10 permit tcp host 10.22.22.1 any eq telnet (25 matches) 20 permit tcp host 10.33.33.1 any eq ftp 30 permit tcp host 10.44.44.1 any eq ftp-data
The show ip interface command displays IP interface information and indicates whether any IP ACLs are set on the interface. In the show ip interface e0 command output shown in Example 6- 14, IP ACL 1 has been configured on the E0 interface as an inbound ACL. No outbound IP ACL has been configured on the E0 interface.
Example 6-14 Verifying Access List Configuration on a Specific Interface
RouterX# show ip interface e0 Ethernet0 is up, line protocol is up Internet address is 10.1.1.11/24 Broadcast address is 255.255.255.255 Address determined by setup command MTU is 1500 bytes Helper address is not set Directed broadcast forwarding is disabled Outgoing access list is not set Inbound access list is 1 Proxy ARP is enabled Security level is default Split horizon is enabled ICMP redirects are always sent ICMP unreachables are always sent ICMP mask replies are never sent IP fast switching is enabled IP fast switching on the same interface is disabled IP Feature Fast switching turbo vector IP multicast fast switching is enabled IP multicast distributed fast switching is disabled <text ommitted>
Take a look at some examples of access list problems. For the following issues, refer to Figure 6-20.
Figure 6-20 ACL Troubleshooting Reference Network
Each of the following problems assumes that an inbound access list is configured to S0 of RouterX, as shown in Figure 6-20. You will use the show access-lists command to determine information about the access list(s) in place to troubleshoot all these problems.
Problem: Host Connectivity
Host 10.1.1.1 has no connectivity with 10.100.100.1. The following output reveals information about the access list(s) in place to help determine the possible cause of the problem:
RouterX# show access- lists 1 0 Standard IP access list 10 10 deny 10.1.1.0, wildcard bits 0.0.0.255 20 permit 10.1.1.1 30 permit ip any any
The cause of this problem is that Host 10.1.1.1 has no connectivity with 10.100.100.1 because of the order of the access list 10 rules. Because the router processes ACLs from the top down, statement 10 would deny host 10.1.1.1, and statement 20 would not be processed. The solution to this problem is to reverse statements 10 and 20.
The 192.168.1.0 network cannot use TFTP to connect to 10.100.100.1. The following output reveals information about the access list(s) in place to help determine the possible cause of the
problem:
RouterX# show access- lists 1 20 Extended IP access list 120 10 deny tcp 172.16.0.0 0.0.255.255 any eq telnet 20 deny tcp 192.168.1.0 0.0.0.255 host 10.100.100.1 eq smtp 30 permit tcp any any
The cause of this problem is that the 192.168.1.0 network cannot use TFTP to connect to 10.100.100.1 because TFTP uses the transport protocol UDP. Statement 30 in access list 120 allows all other TCP traffic, and because TFTP uses UDP, it is implicitly denied. The solution to this problem is to correct statement 30; it should be ip any any.
The 172.16.0.0 network can use Telnet to connect to 10.100.100.1, but this connection should not be allowed. The following output reveals information about the access list(s) in place to help determine the possible cause of the problem:
RouterX# show access- lists 1 30 Extended IP access list 130 10 deny tcp any eq telnet any 20 deny tcp 192.168.1.0 0.0.0.255 host 10.100.100.1 eq smtp 30 permit ip any any
The cause of this problem is that the 172.16.0.0 network can use Telnet to connect to 10.100.100.1 because the Telnet port number in statement 10 of access list 130 is in the wrong position. Statement 10 currently denies any source with a port number that is equal to Telnet trying to establish a connection to any IP address. If you want to deny Telnet inbound on S0, the solution is to deny the destination port number that is equal to Telnet, for example, deny tcp any any eq telnet.
Host 10.1.1.1 can use Telnet to connect to 10.100.100.1, but this connection should not be allowed. The following output reveals information about the access list(s) in place to help determine the possible cause of the problem:
RouterX# show access- lists 1 40 Extended IP access list 140 10 deny tcp host 10.160.22.11 10.100.100.0 0.0.0.255 eq telnet 20 deny tcp 192.168.1.0 0.0.0.255 host 10.100.100.1 eq smtp 30 permit ip any any
The cause of this problem is that the Host 10.1.1.1 can use Telnet to connect to 10.100.100.1 because there are no rules that deny host 10.1.1.1 or its network as the source. Statement 10 of access list 140 denies the router interface from which traffic would be departing. But as these packets depart the router, they have a source address of 10.1.1.1 and not the address of the router interface. The solution to this problem would be to modify entry 10 so that 10.1.0.0 subnet was denied instead of the address 10.160.22.11.
Problem: Host 10.100.100.1 can use Telnet to connect to 10.1.1.1, but this connection should not be allowed. The following output reveals information about the access list(s) in place to help determine the possible cause of the problem:
RouterX# show access- lists 1 50 Extended IP access list 150 10 deny tcp host 10.100.100.1 any eq telnet 20 permit ip any any
Access list 150 is applied to interface S0 in the inbound direction.
The cause of this problem is that the Host 10.100.100.1 can use Telnet to connect to 10.1.1.1 because of the direction in which access list 150 is applied to the S0 interface. Statement 10 denies the source address of 10.100.100.1, but that address would only be the source if the traffic were outbound on S0, not inbound. One solution would be to modify the direction in which the list was applied.
Host 10.1.1.1 can connect into RouterX using Telnet, but this connection should not be allowed. The following output reveals information about the access list(s) in place to help determine the possible cause of the problem:
RouterX# show access- lists 1 60 Extended IP access list 160 10 deny tcp any host 10.160.22.33 eq telnet 20 permit ip any any
The cause of this problem is that the Host 10.1.1.1 can connect into Router B using Telnet because using Telnet to connect into the router is different from using Telnet to connect through the router to another device. Statement 10 of access list 160 denies Telnet access to the address that is assigned to the S0 interface of Router B. Host 10.1.1.1 can still use Telnet to connect into Router B simply by using a different interface address, such as E0. The solution is recognizing which IOS command to use. When you want to block Telnet traffic into and out of the router, use the accessclass command to apply access lists to the vty lines.
More Resources