Day 6 Verifying and Troubleshooting ACL Implementations
CCNA 640-802 Exam Topics
Verify and monitor ACLs in a network environment.
Troubleshoot ACL issues.
Key Topics
Today’s review topics are rather brief compared to yesterday’s. This is so you can take the opportunity to fully review ACL implementations, including their configuration, verification, and troubleshooting. Today we review the verification commands and look at some possible troubleshooting scenarios.
Verifying ACLs
When you finish configuring an ACL, 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-1. 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-1 Verifying Access List Configuration
RouterX#show access-lists
Standard IP access list SALES
10 permit 10.3.3.1
20 permit 10.4.4.1
30 permit 10.5.5.1
40 deny 10.1.1.0, wildcard bits 0.0.0.255
50 permit any
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.33.33.1 any eq ftp-data
Notice in the output from the show access-lists command in Example 6-1 that sequence numbers are incremented by 10—most likely because the administrator did not enter a sequence number. Also notice that this command tells you how many times IOS has matched a packet to a statement—25 times in the case of the first statement in the named ACL ENG.
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-2, 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-2 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
<output omitted>
Finally, you can also verify your ACL creation and application with the show running-config command (shown in Example 6-3) or show startup-config.
Example 6-3 Verifying ACL Creation and Application in the Running Configuration
RouterX#show running-config
Building configuration...
!
<output omitted>
!
interface Ethernet0
ip address 10.44.44.1 255.255.255.0
ip access-group ENG out
!
interface Serial0
ip address 172.16.2.1 255.255.255.252
ip access-group SALES in
!
<output omitted>
ip access-list standard SALES
permit 10.3.3.1
permit 10.4.4.1
permit 10.5.5.1
deny 10.1.1.0 0.0.0.255
permit any
!
ip access-list extended ENG
permit tcp host 10.22.22.1 any eq telnet
permit tcp host 10.33.33.1 any eq ftp
permit tcp host 10.33.33.1 any eq ftp-data
!
<output omitted>
Troubleshooting ACLs
Using the show commands described in the previous section reveals most of the more common ACL errors before they cause problems in your network. When you troubleshoot an ACL, check it against the rules you learned about 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 6-1.
Problem 1: Host Has No Connectivity
Host 192.168.10.10 has no connectivity with 192.168.30.12. The access list shown in Example 6-4 is applied inbound to R3’s s0/0/0 interface.
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 6-5.
Example 6-5 Solution 1: Correcting the “Host Has No Connectivity” Problem
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.
Problem 2: Denied Protocols
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 6-6 is applied inbound to R1’s Fa0/0 interface.
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. The solution is to replace the permit tcp any any statement with permit ip any any as shown in Example 6-7.
Example 6-7 Solution 2: Correcting the “Denied Protocols” Problem
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.
Problem 3: Telnet is Allowed #1
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 6-8.
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 6-9.
Example 6-9 Solution 3: Correcting the “Telnet Is Allowed #1” Problem
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
Problem 4: Telnet Is Allowed #2
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 6-10.
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 6-11 shows the solution to this problem.
Example 6-11 Solution 4: Correcting the “Telnet Is Allowed #2” 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
Problem 5: Telnet Is Allowed #3
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 6-12 is applied inbound to R3’s s0/0/0 interface.
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 6-13 shows the solution to this problem.
Notice that this solution does not block Telnet traffic from 192.168.30.12 to the Fa0/0 interface on R3. A better solution might be to apply the ACL to the Fa0/0 interface for inbound traffic.