Numbered ACL’s are commonly used for simple quick configurations where a single match is needed such as specifying which host is allowed to access the device via SSH. This lab will discuss and demonstrate the configuration of numbered Access Control Lists (ACL’s)
Access Control Lists are the basis of all network security. ACL’s control the flow of traffic through a device and can prevent unwanted traffic from a particular source to a specific destination. This lab will discuss and demonstrate numbered access list which are not very common due to the newer named access-list advantages. The biggest downfall of numbered access-list is the time involved with editing a numbered acl. Unfortunately you cannot manually place ACE’s (Access Control List Entries) on specific lines in the ACL thus causing a time consuming edit to place an ACE on line 10 of a 100 line numbered ACL.
However, as a Cisco Network Engineer you will still see numbered access-list in the field from old deployments or inexperienced network engineers not knowing the new way of configuring an ACL; either way, its still an objective of the CCNA certification.
There are several different specific ranges of numbered access-list used to perform different types of access control as shown below from the Cisco CLI context sensitive help;
R1(config)#access-list ?
<1-99> IP standard access list
<100-199> IP extended access list
<1000-1099> IPX SAP access list
<1100-1199> Extended 48-bit MAC address access list
<1200-1299> IPX summary address access list
<1300-1999> IP standard access list (expanded range)
<200-299> Protocol type-code access list
<2000-2699> IP extended access list (expanded range)
<2700-2799> MPLS access list
<300-399> DECnet access list
<600-699> Appletalk access list
<700-799> 48-bit MAC address access list
<800-899> IPX standard access list
<900-999> IPX extended access list
compiled Enable IP access-list compilation
dynamic-extended Extend the dynamic ACL absolute timer
rate-limit Simple rate-limit specific access list
Step 1. – To complete the first objective of this lab you need to create a standard numbered access-list. By referencing the context sensitive help you’ll notice the standard ip access-list numbers range between 1 and 99. You can choose a number of your own to complete this objective but for the purposes of demonstration, number 50 will be used. The objective states that you need to block IP host 10.1.1.2 inbound access at R1’s FastEthernet0/0 interface but permit all other traffic. An example is shown below;
R1 con0 is now available Press RETURN to get started. R1>enable R1#configure terminal Enter configuration commands, one per line. End with CNTL/Z. R1(config)#access-list 50 deny host 10.1.1.2 R1(config)#access-list 50 permit any
Now that the numbered access-list is created you need to apply it in the ingress direction of interface Fa0/0 on Router 1 as shown below;
R1(config)#interface fa0/0 R1(config-if)#ip access-group 50 in
You can verify your configuration by pinging R1’s Fa0/0 interface from R2, as a prerequisite you should have been able to ping the IP prior to applying the access-list. Now if configured correctly your pings will be Unreachable;
R2>ping 10.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.1, timeout is 2 seconds:
U.U.U
Success rate is 0 percent (0/5)
R2>
You can also verify that the access-list is properly working by executing the show access-list command in privilege mode on R1. As shown below by the command results you’ll notice that the first ACE has a hit count of 8;
R1(config-if)#end R1#show access-list Standard IP access list 50 10 deny 10.1.1.2 (8 matches) 20 permit any R1#
Change the IP address on R2’s FastEthernet interface to 10.1.1.3/24 and verify test your access-list again to ensure traffic destined to destinations excluding 10.1.1.2/32 is permitted;
R2>enable R2#configure terminal R2(config)#interface fa0/0 R2(config-if)#ip add 10.1.1.3 255.255.255.0 R2(config-if)#end R2#
Now ping R2’s new Fa0/0 interface ip address (10.1.1.3) and verify you have successful communication;
R1#ping 10.1.1.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 24/43/76 ms
R1#
Step 2. – Now its time to create an extended numbered access-list. As previously shown in the CLI context sensitive help, you’ll see extended numbered access-list ranges between 100 and 199, however Cisco later added expanded ranges for both standard and extended numbered access-lists. In this objective you need to create an access-list to block telnet traffic oubound on R1’s Fa0/0 interface to the host 10.1.1.3 equal to telnet and permit all other traffic. Since telnet is TCP traffic, you’ll need to specifically match the traffic by specifying the ACE is TCP only and match the protocol following the destination as you need to prevent traffic from reaching that destination with the destination port number of 22 (telnet) as shown below;
R1#configure terminal R1(config)#access-list 150 deny tcp any host 10.1.1.3 eq telnet R1(config)#access-list 150 permit ip any any
Now this access-list needs to be applied in the egress direction on R1’s interface Fa0/0;
R1(config)#interface fa0/0 R1(config-if)#ip access-group 150 out
Due to the nature of how the Cisco device sources traffic from its self, this objective cannot be tested unless another network and static routes are configured which will be discussed in a later section. Traffic sourced from a router does not get processed by an outbound access-list. However, any traffic that traverses the router from one network to host 10.1.1.3 equal to the telnet protocol will be dropped.
Access-list can be configured on a Cisco device inbound and/or outbound and you must look at it in a way that the router is the traffic cop saying what traffic is authorized to pass and what traffic gets smacked into the bit bucket.
There is a general rule of thumb when dealing with access list. In order for access lists to be the most effective you should place an extended access-list closest to the source as possible and a standard access list closest to the destination as possible.
Also keep in mind that there is an IMPLICIT DENY at the end of every access-list, meaning you cannot see the deny statement but configuration wise, it is the same thing as configuring “deny any any” at the end of the access list. So by default, traffic will be dropped unless you permit it. Engineers often times place an explicit deny statement at the end of the access-list in order to log denied traffic as a method of access-list troubleshooting.