Troubleshoot and resolve ACL issues.
ACLs can be particularly difficult to troubleshoot if you do not use a methodical approach to locating and resolving the issue or issues. On Day 10, “Basic ACL Configuration,” we reviewed ACL configuration and verification. Today we look at some possible ACL troubleshooting scenarios.
When you troubleshoot an ACL, check it against the rules you use for how to design ACLs correctly. Most errors occur because these basic rules are ignored. In fact, the most common errors are entering ACL statements in the wrong order and not applying adequate criteria to your rules. Let’s look at a series of common problems and their solutions using the topology shown in Figure 3-1.
Host 192.168.10.10 has no connectivity with 192.168.30.12. The access list shown in Example 3-1 is applied inbound to R3’s s0/0/0 interface.
R3# show access-lists 100
Extended IP access list 100
10 deny tcp 192.168.10.0 0.0.0.255 any
20 permit tcp host 192.168.10.10 any
30 permit ip any any
Because ACLs are processed sequentially until a match is made, traffic from host 192.168.10.10 is denied by the first statement. Statement 20, which permits host 192.168.10.10, never gets processed. The solution is to change the position of statement 20 so that it comes before statement 10. You can do this with the commands shown in Example 3-2.
R3(config)# ip access-list extended 100
R3(config-ext-nacl)# no 20 permit tcp host 192.168.10.10 any
R3(config-ext-nacl)# 5 permit tcp host 192.168.10.10 any
R3(config-ext-nacl)# end
R3# show access-lists 100
Extended IP access list 100
5 permit tcp host 192.168.10.10 any
10 deny tcp 192.168.10.0 0.0.0.255 any
30 permit ip any any
First, notice that we entered named ACL configuration mode in order to edit the sequence numbers for the extended numbered ACL. Second, we removed statement 20. Finally, we reapplied statement 20 with a new sequence number lower than 10–5 in the example. Notice from the show access-lists output that the statement order is now correct. Host 192.168.10.10 will be permitted, and all other traffic from the 192.168.10.0/24 subnet will be denied.
The 192.168.10.0/24 network cannot use TFTP to connect to the 192.168.30.0/24 network. The access list shown in Example 3-3 is applied inbound to R1’s G0/0 interface.
R1# show access-lists 120
Extended IP access list 120
10 deny tcp 192.168.10.0 0.0.0.255 any eq telnet
20 deny tcp 192.168.10.0 0.0.0.255 host 10.100.100.1 eq smtp
30 permit tcp any any
The 192.168.10.0/24 network cannot use TFTP to connect to the 192.168.30.0/24 network because TFTP uses the transport protocol UDP. Statement 30 in access list 120 allows all other TCP traffic. Because TFTP uses UDP, it is implicitly denied. One possible solution is to replace the permit tcp any any statement with permit ip any any, as shown in Example 3-4.
R1(config)# ip access-list extended 120
R1(config-ext-nacl)# no 30 permit tcp any any
R1(config-ext-nacl)# permit ip any any
R1(config-ext-nacl)# end
R1# show access-lists 120
Extended IP access list 120
10 deny tcp 192.168.10.0 0.0.0.255 any eq telnet
20 deny tcp 192.168.10.0 0.0.0.255 host 10.100.100.1 eq smtp
30 permit ip any any
Notice that we did not have to include a sequence number for the new permit ip any any statement because this statement comes at the end of the list. IOS will automatically increment it by 10.
The 192.168.10.0/24 network can use Telnet to connect to 192.168.30.0/24, but this connection should not be allowed. The access list is shown in Example 3-5.
R1# show access-lists 130
Extended IP access list 130
10 deny tcp any eq telnet any
20 deny tcp 192.168.10.0 0.0.0.255 host 10.100.100.1 eq smtp
30 permit ip any any
The 192.168.10.0/24 network can use Telnet to connect to the 192.168.30.0/24 network because Telnet in statement 10 of access list 130 is listed in the wrong position. The source port would not be Telnet’s port 23, but some randomly chosen port numbered above 1024. The destination port number (or application) must be set to Telnet, as shown in the solution to this problem in Example 3-6.
R1(config)# ip access-list extended 130
R1(config-ext-nacl)# no 10 deny tcp any eq telnet any
R1(config-ext-nacl)# 10 deny tcp any any eq telnet
R1(config-ext-nacl)# end
R1# show access-lists 130
Extended IP access list 130
10 deny tcp any any eq telnet
20 deny tcp 192.168.10.0 0.0.0.255 host 10.100.100.1 eq smtp
30 permit ip any any
Host 192.168.10.10 can use Telnet to connect to 192.168.30.12, but this connection should not be allowed. The access list is shown in Example 3-7.
R1# show access-lists 140
Extended IP access list 140
10 deny tcp host 192.168.10.1 any eq telnet
20 deny tcp 192.168.10.0 0.0.0.255 host 10.100.100.1 eq smtp
30 permit ip any any
Host 192.168.10.10 can use Telnet to connect to 192.168.30.12 because no rules deny host 192.168.10.10 or its network as the source. Statement 10 denies the router interface from which traffic would be departing. However, as Telnet packets depart the router, they have the source address of 192.168.10.10, not the address of the router interface. Example 3-8 shows the solution to this problem.
R1(config)# ip access-list extended 140
R1(config-ext-nacl)# no 10 deny tcp host 192.168.10.1 any eq telnet
R1(config-ext-nacl)# 10 deny tcp host 192.168.10.10 any eq telnet
R1(config-ext-nacl)# end
R1# show access-lists 140
Extended IP access list 140
10 deny tcp host 192.168.10.10 any eq telnet
20 deny tcp 192.168.10.0 0.0.0.255 host 10.100.100.1 eq smtp
30 permit ip any any
Host 192.168.30.12 can use Telnet to connect to 192.168.10.10, but this connection should not be allowed. The access list shown in Example 3-9 is applied inbound to R3’s s0/0/0 interface.
R3# show access-lists 150
Extended IP access list 150
10 deny tcp host 192.168.30.12 any eq telnet
20 permit ip any any
Host 192.168.30.12 can use Telnet to connect to 192.168.10.10 because of the direction in which access list 150 is applied to the S0/0/0 interface. Statement 10 denies the source address of 192.168.30.12, but that address would be the source only if the traffic were outbound on S0/0/0, not inbound. Example 3-10 shows the solution to this problem.
R3(config)# interface serial 0/0/0
R3(config-if)# no ip access-group 150 in
R3(config-if)# ip access-group 150 out
Notice that this solution does not block Telnet traffic from 192.168.30.12 to the G0/0 interface on R3. A better solution might be to apply the ACL to the G0/0 interface for inbound traffic.
For today’s exam topics, refer to the following resources for more study.
3.144.227.72