Access Control Lists
Revised June 27, 2018
If you're not up to speed on binary math, you're going to have a tough time with these problems. I recommend the "Binary-Decimal-Hexadecimal" review exercise.
Your solutions may not look exactly like mine. For some access list problems, there may be multiple correct solutions (especially when future growth is considered). The important thing is that you understand and can apply the principles involved.
1. Design an IP ACL (Access Control List) that permits traffic from host 193.5.2.76, but denies all other IP traffic.
2. Design an IP ACL that denies traffic from host 11.5.25.239, but permits all other IP traffic.
3. Design an IP ACL that permits IP traffic from hosts on network 196.25.1.0/24, and denies other IP traffic.
4. Design an ACL that denies IP traffic from hosts 152.5.35.83 and 104.2.64.33, permits IP traffic from all hosts on network 185.25.0.0/16, and denies all other IP traffic. Invoke your access list inbound on interface E2.
5. Given the statements:
interface ethernet 1 ip access-group 5 in access-list 5 permit host 101.2.3.40 access-list 5 deny 203.45.0.0 0.0.255.255 access-list 5 permit anyWhat will the result be?
6. Design an ACL that permits IP traffic from hosts 1.2.3.98 and 1.2.3.99, and denies all other IP traffic. Invoke your access list outbound on interface Token Ring 3/1.
7. Design an extended IP ACL that denies HTTP traffic intended for the web server at 47.23.67.102, permits HTTP traffic to other web servers, and denies all other IP traffic. Invoke your access list inbound on interface E0, and outbound on FDDI interface 3.
8. Given the statements:
interface ethernet 0 ip access-group 8 in access-list 8 deny host 101.202.3.4 access-list 8 deny 203.45.6.0 0.0.0.255 access-list 8 permit anyWhat will the result be?
9. Design an IP ACL that permits TFTP traffic to TFTP servers that have host addresses ending in even numbers, denies TELNET traffic to TELNET servers that have host addresses ending in odd numbers, permits traffic to other TELNET servers, and denies all other IP traffic. Activate your list inbound on interface E1.
10. Design an extended ACL that permits all IP traffic from hosts on network 215.23.45.0/24, permits anyone to open a Telnet session with either 14.63.73.66 and 221.63.62.88 (and logs such packets to the console), and denies all other IP traffic. Invoke your list inbound on the first Token Ring interface on the card in slot 2.
11. Given the statements:
interface serial 0 ip access-group 111 out access-list 111 deny tcp 14.3.6.234 0.0.0.0 host 6.5.4.1 eq 23 access-list 111 deny udp any any eq tftp access-list 111 permit ip any anyWhat will the result be?
12. Design an access list that permits web traffic from the server at 101.54.32.2 to all hosts on subnet 149.23.8.0/24, permits pings in either direction between the hosts on network 39.0.0.0/8 and subnet 197.2.5.96/27, and denies everything else. Place this access list in force in the outbound direction on the router's E2 port.
13. Given the statements:
interface fddi 3/2 ip access-group 13 access-list 13 permit 100.200.0.0 0.0.255.63What will the result be?
14. Design an access list that permits all IP traffic except pings in either direction between subnets 10.20.0.0/16 and 40.50.60.0/24.
15. Given the statements:
interface token-ring 7 ip access-group 15 in ip access-group 115 out access-list 15 permit host 201.3.4.2 access-list 15 deny 203.45.0.0 0.0.255.255 access-list 15 deny 84.7.22.240 0.0.0.7 access-list 15 permit any access-list 115 permit ip any host 101.202.3.4 log access-list 115 permit tcp 203.45.6.0 0.0.0.255 any eq www access-list 115 permit udp any anyWhat will the result be?
16. Design an access list that permits all IP traffic from the hosts on networks 222.111.3.0/24 through 222.111.7.0/24, and denies all other IP traffic.
17. Given the statements:
interface token-ring 2/1 ip access-group 17 in access-list 17 deny host 201.3.4.2 access-list 17 deny 84.7.22.248 0.0.0.7 access-list 17 deny 153.45.0.0 0.0.255.255 access-list 17 deny 203.45.6.0 0.0.0.255What will the result be?
18. Design an access list that denies all FTP traffic from the hosts on subnets 101.202.8.0/24 through 101.202.13/24 that is destined for FTP servers, but permits all other IP traffic.
19. Given the statements:
interface ethernet 4 ip access-group 119 access-list 119 permit ip any any access-list 119 deny ip 106.45.0.0 0.0.255.255 any access-list 119 deny tcp any 44.7.12.224 0.0.0.15 eq ftp access-list 119 deny udp 23.145.64.0 0.0.0.255 host 1.2.3.4 eq ripWhat will the result be?
20. Design an access list that permits all IP traffic from the hosts on subnets 10.0.0.0/16 through 10.7.0.0/16, permits IP traffic from the hosts on subnets 10.9.0.0/16 through 10.15.0.0/16, and denies all other IP traffic. Place it outbound on E0 and inbound on Token Ring 2.
21. Design an access list that permits bi-directional ICMP traffic between subnets 1.0.96.0/20 and 2.0.1.64/27, permits bi-directional IP traffic between the hosts on subnets 131.5.0.0/16 through 131.8.0.0/16 and the hosts on network 239.5.6.0/24, and denies all other IP traffic except IGRP, which must be permitted everywhere.
22. The following statements are executed in the order given:
access-list 22 deny 1.2.3.4 access-list 22 deny 5.6.7.8 access-list 22 permit any no access-list 22 deny 1.2.3.4 interface serial 3 ip access-group 22 inWhat is the result?
23. Given the statements:
interface ethernet 1 ip access-group 23 in ip access-group 123 in access-list 23 deny host 1.3.5.7 0.0.0.0 access-list 23 deny 10.0.0.0 0.0.0.0 access-list 23 deny 54.78.43.2 255.255.255.255 access-list 23 deny ip host 101.2.5.7 eq telnet access-list 123 permit ip 205.6.23.6 34.67.22.3 access-list 123 permit ipx a0b1c2 -1 access-list 123 deny telnet access-list 123 permit ip host 225.0.0.5 any access-list 123 deny ip any anyHow many errors can you find?
24. Your mission: Allow incoming Telnets to the router or switch only from hosts that reside on the 192.168.99.0/24 network.
1. Here are three solutions to this problem:
access-list 101 permit ip host 193.5.2.76 anybut why use an extended list when a standard list will do?
2. One solution to this problem:
access-list 2 deny host 11.5.25.239 access-list 2 permit any
3. Since there are 254 possible host addresses on this network, we don't want to specify them individually. Therefore, we will use a wildcard mask. An access list that meets the requirements is:
access-list 3 permit 196.25.1.0 0.0.0.255
4. One solution to this problem is:
interface e2 ip access-group 4 in access-list 4 deny host 104.2.64.33 access-list 4 deny host 152.5.35.83 access-list 4 permit 185.25.0.0 0.0.255.255Remember that preceeding an address with the keyword "host" is equivalent to following that address with a mask of "0.0.0.0". Note also that since neither of two "denies" is covered by the "permit", a more efficient solution is:
interface e2 ip access-group 4 in access-list 4 permit 185.25.0.0 0.0.255.255One more thing ... the "access-list" statement is entered in "global config" mode (it does not "belong" the the interface), and the "access-group" statement is entered in "interface config" mode (it does belong to the interface).
5. Access list 25 has been placed inbound on interface E1. Therefore, any IP traffic from host 101.2.3.40 will be allowed into the router via E1. No IP traffic from any of the 256 Class "C" networks starting with 203.45.0.0 will be allowed into E1, but any other IP traffic will be permitted. Since traffic from host 101.2.3.40 is also permitted by the last line, the first line is superfluous, and the same result could be obtained by using:
access-list 5 deny 203.45.0.0 0.0.255.255 access-list 5 permit any
6. The most straightforward solution:
interface token-ring 3/1 ip access-group 6 out access-list 6 permit host 1.2.3.98 access-list 6 permit host 1.2.3.99On the other hand, we could get cute and use a wildcard mask. If we examine the bit patterns for the two host addresses, we notice that they are identical in the first three octets, and identical up to the last bit in the fourth octet, where the two possibilites are our two host addresses. Therefore, we can cover both addresses with one line, and an alternative solution is as follows:
interface token-ring 3/1 ip access-group 6 out access-list 6 permit 1.2.3.98 0.0.0.1Note that this just might be too clever for our own good, in that it only saved us one line, and it is no longer readily apparent what the access list is doing.
7. The most straightforward solution:
interface ethernet 0 ip access-group 107 in interface fddi 3 ip access-group 107 out access-list 107 deny tcp any host 47.23.67.102 eq www access-list 107 permit tcp any any eq www
8. This configuration denies any IP traffic from host 101.202.3.4 from entering interface E0, it denies all IP traffic from any host on network 203.45.6.0/24 from entering interface E0, and it permits any other IP traffic to enter through interface E0.
9. To check for even and odd addresses, we only care that the last bit is a zero or a one, respectively. We can do it with:
interface ethernet 1 ip access-group 109 in access-list 109 permit udp any 0.0.0.0 255.255.255.254 eq tftp access-list 109 permit tcp any 0.0.0.0 255.255.255.254 eq telnetBy the way, I can't imagine that you'd ever want to do this in real life, but it makes an interesting practice problem!
10. One solution:
interface token-ring 2/0 ip access-group 110 in access-list 110 permit ip 215.23.45.0 0.0.0.255 any access-list 110 permit tcp any host 14.63.73.66 eq telnet log access-list 110 permit tcp any host 221.63.62.88 eq telnet log
11. This configuration denies TELNET traffic from 14.3.6.234 bound for host 6.5.4.1 from leaving interface S0, it denies all TFTP traffic bound for TFTP servers, and it permits all other IP traffic. Consistency is a good thing, so, unlike this exercise, use either the keyword "host" or the mask "0.0.0.0". Don't mix and match.
12. One solution:
interface ethernet 2 ip access-group 112 out access-list 112 permit tcp host 101.54.32.2 eq www 149.23.8.0 0.0.0.255 access-list 112 permit icmp 39.0.0.0 0.255.255.255 197.2.5.96 0.0.0.31 echo access-list 112 permit icmp 39.0.0.0 0.255.255.255 197.2.5.96 0.0.0.31 echo-reply access-list 112 permit icmp 197.2.5.96 0.0.0.31 39.0.0.0 0.255.255.255 echo access-list 112 permit icmp 197.2.5.96 0.0.0.31 39.0.0.0 0.255.255.255 echo-replySome explanations are in order here. In the first line of the access list, we are interested in traffic that is coming from the web server, so we place the port identifier after the source address (not the destination address). The second and third lines take care of pings (ICMP echo) and replies (ICMP echo-reply) leaving 39.0.0.0/8, and the fourth and fifth lines take care of pings and replies leaving 197.2.5.96/27. Remember, using a "/27" subnet mask (same as "255.255.255.224") with a class "C" network means that we have set aside three bits in the fourth octet for subnetting. For the "96" subnet, the bit pattern is "011XXXXX", where the X's mean we don't care. Since the first three bits must be "011", and we don't care about the last five bits, the last octet of the wildcard mask must be "00011111", which is 31. The first three octets have to match exactly, so the wildcard mask is "0.0.0.31".
13. This configuration permits IP traffic from any host within the range from 100.200.0.0 - 100.200.0.63, 100.200.1.0 - 100.200.1.63 ... 100.200.255.0 - 100.200.255.63 to pass outbound (the default direction for "access-group" statements) via FDDI 3/2. By the way, letting it choose "outbound" by default is bad practice. You should specify the direction you desire.
14. One solution:
access-list 114 deny icmp 10.20.0.0 0.0.255.255 40.50.60.0 0.0.0.255 echo access-list 114 deny icmp 10.20.0.0 0.0.255.255 40.50.60.0 0.0.0.255 echo-reply access-list 114 deny icmp 40.50.60.0 0.0.0.255 10.20.0.0 0.0.255.255 echo access-list 114 deny icmp 40.50.60.0 0.0.0.255 10.20.0.0 0.0.255.255 echo-reply access-list 114 permit ip any anyWe need to cover the pings and replies in both directions.
15. This configuration places access list 13 inbound on Token Ring interface 7. Accordingly, all IP traffic from host 201.3.4.2 is allowed in on To7, IP traffic from host addresses 203.45.0.0 through 203.45.255.255 is denied access inbound through To7, IP traffic from host addresses 84.7.22.240 through 84.7.22.247 is denied access inbound through To7, and all other IP traffic is permitted inbound through To7. Since 201.3.4.2 is a subset of the last line of access list 13, the first line of access list 13 is superfluous, and the list could be written more concisely as:
access-list 15 deny 203.45.0.0 0.0.255.255 access-list 15 deny 84.7.22.240 0.0.0.7 access-list 15 permit anyThis configuration also places access list 184 outbound on Token Ring interface 7. This allows IP traffic from any host to destination 101.202.3.4 (and logs any such traffic to the console), permits HTTP traffic from hosts on 203.45.6.0/24 from going to any web server, and permits any UDP traffic.
16. One efficient solution:
access-list 16 permit 222.111.3.0 0.0.0.255 access-list 16 permit 222.111.4.0 0.0.3.255The first line covers network 222.111.3.0/24, and the second line covers networks 222.111.4.0/24 through 222.111.7.0/24. Do you see why that's the case?
17. Because there are no "permit" statements in the list, this configuration will deny all IP traffic inbound via Token Ring interface 2/1. An ACL with no "permits" is a mistake (or unfinished), and will likely result in unintended consequences.
18. One solution:
access-list 118 deny tcp 101.202.8.0 0.0.0.255 any eq ftp access-list 118 deny tcp 101.202.9.0 0.0.0.255 any eq ftp access-list 118 deny tcp 101.202.10.0 0.0.0.255 any eq ftp access-list 118 deny tcp 101.202.11.0 0.0.0.255 any eq ftp access-list 118 deny tcp 101.202.12.0 0.0.0.255 any eq ftp access-list 118 deny tcp 101.202.13.0 0.0.0.255 any eq ftp access-list 118 permit ip any anyAnd yet another using four lines:
access-list 118 deny tcp 101.202.8.0 0.0.3.255 any eq ftp access-list 118 deny tcp 101.202.12.0 0.0.0.255 any eq ftp access-list 118 deny tcp 101.202.13.0 0.0.0.255 any eq ftp access-list 118 permit ip any anyAnd this one gets it down to three lines, the best we can do:
access-list 118 deny tcp 101.202.8.0 0.0.3.255 any eq ftp access-list 118 deny tcp 101.202.12.0 0.0.1.255 any eq ftp access-list 118 permit ip any anyThere are other schemes, including:
access-list 118 permit tcp 101.202.14.0 0.0.0.255 any eq ftp access-list 118 permit tcp 101.202.15.0 0.0.0.255 any eq ftp access-list 118 deny tcp 101.202.8.0 0.0.7.255 any eq ftp access-list 118 permit ip any anyCan you see why the above ACLs give equivalent results?
19. Because the first line is a "permit ip any any", all traffic matches on the first line and is allowed to pass, and the other lines are never checked. The "permit ip any any" line was probably intended to be at the end of the access list. The "bottom line" (heh-heh!) is that the order of the lines can be crucial.
20. One solution:
interface ethernet 0 ip access-group 20 out interface token-ring 2 ip access-group 20 in access-list 20 permit 10.0.0.0 0.0.255.255 access-list 20 permit 10.1.0.0 0.0.255.255 access-list 20 permit 10.2.0.0 0.0.255.255 access-list 20 permit 10.3.0.0 0.0.255.255 access-list 20 permit 10.4.0.0 0.0.255.255 access-list 20 permit 10.5.0.0 0.0.255.255 access-list 20 permit 10.6.0.0 0.0.255.255 access-list 20 permit 10.7.0.0 0.0.255.255 access-list 20 permit 10.9.0.0 0.0.255.255 access-list 20 permit 10.10.0.0 0.0.255.255 access-list 20 permit 10.11.0.0 0.0.255.255 access-list 20 permit 10.12.0.0 0.0.255.255 access-list 20 permit 10.13.0.0 0.0.255.255 access-list 20 permit 10.14.0.0 0.0.255.255 access-list 20 permit 10.15.0.0 0.0.255.255That solution is kind of long, but it has the advantage of being straightforward. Another solution is:
interface ethernet 0 ip access-group 20 out interface token-ring 2 ip access-group 20 in access-list 20 deny 10.8.0.0 0.0.255.255 access-list 20 permit 10.0.0.0 0.15.255.255This is concise and relatively easy to understand. Can you see why the two ACLs give equivalent results?
21. One solution:
access-list 121 permit icmp 1.0.96.0 0.0.15.255 2.0.1.64 0.0.0.31 access-list 121 permit icmp 2.0.1.64 0.0.0.31 1.0.96.0 0.0.15.255 access-list 121 permit ip 131.5.0.0 0.0.255.255 239.5.6.0 0.0.0.255 access-list 121 permit ip 131.6.0.0 0.0.255.255 239.5.6.0 0.0.0.255 access-list 121 permit ip 131.7.0.0 0.0.255.255 239.5.6.0 0.0.0.255 access-list 121 permit ip 131.8.0.0 0.0.255.255 239.5.6.0 0.0.0.255 access-list 121 permit ip 239.5.6.0 0.0.0.255 131.5.0.0 0.0.255.255 access-list 121 permit ip 239.5.6.0 0.0.0.255 131.6.0.0 0.0.255.255 access-list 121 permit ip 239.5.6.0 0.0.0.255 131.7.0.0 0.0.255.255 access-list 121 permit ip 239.5.6.0 0.0.0.255 131.8.0.0 0.0.255.255 access-list 121 permit igrp any anyA slightly more efficient, although less intuitive, solution:
access-list 121 permit icmp 1.0.96.0 0.0.15.255 2.0.1.64 0.0.0.31 access-list 121 permit icmp 2.0.1.64 0.0.0.31 1.0.96.0 0.0.15.255 access-list 121 permit ip 131.5.0.0 0.0.255.255 239.5.6.0 0.0.0.255 access-list 121 permit ip 131.6.0.0 0.1.255.255 239.5.6.0 0.0.0.255 access-list 121 permit ip 131.8.0.0 0.0.255.255 239.5.6.0 0.0.0.255 access-list 121 permit ip 239.5.6.0 0.0.0.255 131.5.0.0 0.0.255.255 access-list 121 permit ip 239.5.6.0 0.0.0.255 131.6.0.0 0.1.255.255 access-list 121 permit ip 239.5.6.0 0.0.0.255 131.8.0.0 0.0.255.255 access-list 121 permit igrp any anyAnother possibility:
access-list 121 permit icmp 1.0.96.0 0.0.15.255 2.0.1.64 0.0.0.31 access-list 121 permit icmp 2.0.1.64 0.0.0.31 1.0.96.0 0.0.15.255 access-list 121 deny ip 131.4.0.0 0.0.255.255 239.5.6.0 0.0.0.255 access-list 121 permit ip 131.4.0.0 0.3.255.255 239.5.6.0 0.0.0.255 access-list 121 permit ip 131.8.0.0 0.0.255.255 239.5.6.0 0.0.0.255 access-list 121 deny ip 239.5.6.0 0.0.0.255 131.4.0.0 0.0.255.255 access-list 121 permit ip 239.5.6.0 0.0.0.255 131.4.0.0 0.3.255.255 access-list 121 permit ip 239.5.6.0 0.0.0.255 131.8.0.0 0.0.255.255 access-list 121 permit igrp any anyThis seems to gain us nothing at the expense of complicating the logic. The best solution is probably the first one, which costs us a little in efficiency, but gains us much in the way of clarity. In general, it is better to be inefficient and correct than it is to be efficiently wrong.
22. The first three lines build an ACL, but the fourth line ("no access-list 22") removed the list. It doesn't matter that a particular line was specified, when using the numbered ACL editor, the "no" command deletes the entire list. As a result, an undefined ACL is applied to the interface, and an undefined ACL acts as a "permit any". The net result is that all IP traffic is allowed inbound via S3. Note that the single line could be removed by using the "named" ACL editor on our numbered list, as follows:
Router#config t Router(config)#ip access-list standard 22 Router(config-std-nacl)#no deny 1.2.3.4 Router(config-std-nacl)#end Router#In general, for extensive ACL editing, it's better to do it using a word processing program (Notepad, Wordpad, MSWord, whatever). If using a "fancy" editor, don't forget to save the ACL in "text" (ASCII) mode (not as a Word "doc").
23. Remember, one access list (standard or extended) per protocol per direction per interface. This means that access lists 23 and 123 cannot both be inbound on Ethernet 1 at the same time. Other errors are as follows:
access-list 23 deny host 1.3.5.7 0.0.0.0 Don't use both the keyword "host" and the "0.0.0.0" mask. access-list 23 deny 10.0.0.0 0.0.0.0 It's not likely that "10.0.0.0" is a host address. access-list 23 deny 54.78.43.2 255.255.255.255 The mask was probably intended to be "0.0.0.0", i.e. "host". access-list 23 deny ip host 101.2.5.7 eq telnet We can't deny specific protocols with a standard access list. Also, since there is no "permit" statement in access list 60, it denies all IP traffic. access-list 123 permit ip 205.6.23.6 34.67.22.3 Missing addressing information, the "host" keyword should probably appear before each address. access-list 123 permit ipx a0b1c2 -1 We can't specify any IPX information in an IP access list. access-list 123 deny telnet Missing addressing and protocol (TCP) information. access-list 123 permit ip host 225.0.0.5 any The address "225.0.0.5" is a multicast address. A multicast or broadcast address can never be a legal source address. access-list 123 deny ip any any While this statement is redundant (because it is implicit at the end of every IP access list), some people do include it for the sake of clarity. Therefore, it is not an "error".
24. Here's the solution:
line vty 0 4 access-class 24 in access-list 24 permit 192.168.99.0 0.0.0.255Remember that when placing an ACL on the VTY lines (to control Telnet sessions to the router or switch), the command is "access-class" (not "access-group").