Troubleshooting ACLs

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

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

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:

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:

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:

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:

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:

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:

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

About the author

Prasanna

Leave a Comment