CCNAv6.0 – ACLs Error and Solutions Example

Troubleshooting Access Control List (ACL) errors.

Using the show commands reveals most of the more common ACL errors before they cause problems in your network.

When you look at an ACL configuration, check it against known rules you learned regarding how to build ACLs correctly. Most errors occur because these basic rules are ignored.

The most common errors are entering ACL statements in the wrong order and not applying adequate criteria to your rules.

Let us look at a series of common problems and the solutions.

Error #1

Host 192.168.1.4 has no connectivity with 192.168.3.6. Can you see the error in the output of the show access-lists command?

Solution

Look at the order of the ACL statements above, Host 192.168.1.4 has no telnet connectivity with 192.168.3.6 because of the order of rule 10 in the access list. Because the router processes ACLs from the top down, statement 10 denies host 192.168.1.4, so statement 20 does not get processed. Statements 10 and 20 should be reversed. The last line allows all other non-TCP traffic that falls under IP (ICMP, UDP, and so on).

Error #2

The 192.168.1.0 /24 network cannot use TFTP to connect to the 192.168.3.0 /24 network. Can you see the error in the output of the show access-lists command?

Solution – The 192.168.1.0 /24 network cannot use TFTP to connect to the 192.168.3.0 /24 network because TFTP uses the transport protocol UDP. Statement 30 in access list 102 allows all other TCP traffic. Because TFTP uses UDP, it is implicitly denied. Statement 30 should be ip any any.

This ACL works whether it is applied to Fa0/0 of R1 or S0/0/1of R3, or S0/0/0 or R2 in the inward bound direction. However, based on the rule about placing extended ACLs closest to the source, the best option is in this case is on Fa0/0 of R1 because it allows unwanted traffic to be filtered without crossing the network infrastructure.

Error #3

The 192.168.1.0 /24 network can use Telnet to connect to 192.168.3.0 /24, but this connection should not be allowed. View the output from the show access-lists command and see if you can spot a solution. Where would you apply this ACL?

Solution – The 192.168.1.0 /24 network can use Telnet to connect to the 192.168.3.0 /24 network, Solution – The 192.168.1.0 /24 network can use Telnet to connect to the 192.168.3.0 /24 network, because the Telnet port number in statement 10 of access list 103 is listed 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 traffic inbound on S0/0/1, you should deny the destination port number that is equal to Telnet, for example, deny tcp any any eq telnet.

 Error #4

Host 192.168.1.4 can use Telnet to connect to 192.168.3.6, but this connection should not be allowed. View the output from the show access-lists command.

Solution – Host 192.168.1.4 can use Telnet to connect to 192.168.3.6 because there are no rules that deny host 192.168.1.4 or its network as the source. Statement 10 of access list 104 denies the router interface from which traffic would be leaving. However, as these packets go out from the router, they have a source address of 192.168.1.4 and not the address of the router interface.

Error #5

Host 192.168.3.6 can use Telnet to connect to 192.168.1.4, but this connection should not be allowed. Look at the output from the show access-lists command and find the error.

Solution – Host 192.168.3.6 can use Telnet to connect to 192.168.1.4 because the direction in which access list 105 is applied to an interface on R2 is incorrect. Statement 10 denies the source address of 192.168.3.6, but that address would only be the source if the traffic were outbound on So/0/0, or inbound on So/0/1.