Section 9 – Access Control Lists

Section 9 Tasks

• Read today’s lesson notes (below)
• Complete today’s lab
• Read the ICND1 cram guide
• Spend 15 minutes on the subnetting.org website

Along with subnetting and VLSM, access control lists (ACLs) are one of the bugbear subjects for new Cisco students. Among the problems are learning the IOS configuration commands, understanding ACL rules (including the implicit “deny all” rule), and learning the port numbers and protocol types.

Like any subject, you should take the learning process one step at a time, apply every command you see here to a router, and do lots and lots of labs.

Today you will learn about the following:

• ACL basics
• Standard, extended, and named ACLs
• ACL rules
• Wildcard masks
• ACL configuration
• Troubleshooting ACLs

This module maps to the following CCNA syllabus requirements:

• Describe the types, features, and applications of ACLs

° Standard
° Sequence numbers
° Editing
° Extended
° Named
° Numbered
° Log option
° Configure and verify ACLs in a network environment

ACL Basics

The point of ACLs is to filter the traffic which passes through your router. I don’t know of any network which should permit any traffic type to enter or leave it.

As well as filtering traffic, ACLs can be used to reference NAT pools, to filter your debugging commands, and with route maps (this is outside of the CCNA syllabus requirements). Depending upon the type of ACL you configure, you can filter traffic based on source network or IP addresses, destination network or IP addresses, protocols, or port numbers. You can apply ACLs to any router interface, including your Telnet ports.

The three main types of ACLs are as follows:

• Standard numbered
• Extended numbered
• Standard or extended named

Standard numbered ACLs are the most basic form of ACL you can apply to the router. While they are the easiest to configure, they have the most limited range of filters available. They can only filter based on the source IP address or network. The way to recognise a standard ACL is by the number which precedes the configuration lines; these numbers will be from 1 to 99.

Extended numbered ACLs allow far more granularity but can be trickier to configure and troubleshoot. They can filter a destination or source IP address or network, a protocol type, and a port number. The numbers you can use to configure extended ACLs are 100 to 199, inclusive.

Named ACLs allow you to associate a list of filters with a name rather than a number. This makes them easier to identify in router configurations. Named ACLs can actually be either extended or standard; you choose which at the initial configuration line of the ACL.

For success in the CCNA exam, and to make it as a new Cisco engineer, you need to understand the following:

• Port numbers
• ACL rules
• Command syntax for ACLs

Port Numbers

You simply must know the common port numbers by heart if you want to pass the CCNA exam and to work on live networks. Looking up common port numbers isn’t an option when you have customers watching what you are doing. Here are the most common port numbers you will encounter and will need to know:

TABLE 9.1 – Common CCNA Port Numbers

Access Control List Rules

This is one of the hardest parts to understand. I’ve never seen a complete list of rules written down in one Cisco manual. Some refer to them generally or explain some of them, but then miss others completely. The difficulty is that the rules always apply but (until now) you found them only by trial and error. Here are the rules you need to know:

ACL Rule 1 – Use only one ACL per interface per direction.

This makes good sense. You wouldn’t want to have several ACLs doing different things on the same interface. Simply configure one ACL which does everything you need it to, rather than spreading out filters over two or more lists. I could have added “per protocol” to the above rule because you could have an IPX access control list, but IP is really the only protocol in use in modern networks.

Figure 9.1 – One ACL per Interface per Direction

ACL Rule 2 – The lines are processed top-down.

Some engineers become confused when their ACL doesn’t perform as expected. The router will look at the top line of the ACL, and if it sees a match, it will stop there and will not examine the other lines. For this reason, you need to put the most specific entries at the top of the ACL. For example, take the ACL blocking host 172.16.1.1:

In the example above, you should have put the Deny 172.16.1.1 line at the top, or at least above the Permit 172.16.0.0 statement.

ACL Rule 3 – There is an implicit “deny all” at the bottom of every ACL.

This catches many engineers out. There is an invisible command at the bottom of every ACL. This command is set to deny all traffic which hasn’t been matched yet. The only way to stop this command coming into effect is to configure a “permit all” at the bottom manually. For example, take an incoming packet from IP address 172.20.1.1:

You actually wanted the packet to be permitted by the router, but instead it denies it. The reason is the implicit “deny all,” which is a security measure.

ACL Rule 4 – The router can’t filter self-generated traffic.

This can cause confusion when doing testing before implementing your ACL on a live network. A router won’t filter traffic it generated itself. This is demonstrated in Figure 9.2 below:

Figure 9.2 – ACL Testing with Self-Generated Traffic

ACL Rule 5 – You can’t edit a live ACL.

In fact, until IOS 12.4 you could only edit a named ACL, not standard or extended ACLs. This was a limitation of ACL architecture. Before IOS 12.4, if you wanted to edit a standard or extended ACL, you had to follow these steps ( I used list 99 as an example):

1. Stop ACL traffic on the interface with the no ip access-group 99 in command.
2. Copy and paste the ACL into Notepad and edit it there.
3. Go into ACL mode and paste in the new ACL.
4. Apply the ACL to the interface again.

Here are the steps on a live router:

ACL created and applied to interface:

Router>en
Router#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#access-list 1 permit 172.16.1.1
Router(config)#access-list 1 permit 172.16.2.1
Router(config)#interface FastEthernet0/0
Router(config-if)#ip access-group 1 in

Take off the active interface:

Router(config)#int FastEthernet0/0
Router(config-if)#no ip access-group 1 in
Router(config-if)#^Z

Show the ACLs. Copy and paste into Notepad and make the changes:

Router#show run ← or show ip access lists
access-list 1 permit host 172.16.1.1
access-list 1 permit host 172.16.2.1

You actually need to add an exclamation mark in-between each line of configuration (if you are pasting it in) to tell the router to do a carriage return:

access-list 1 permit host 172.16.1.1
!
access-list 1 permit host 172.16.2.2

The lines being pasted into the router configuration are shown below. Delete the previous ACL and then paste in the new version:

Router#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#no access-list 1
Router(config)#access-list 1 permit host 172.16.1.1
Router(config)#!
Router(config)#access-list 1 permit host 172.16.2.2
Router(config)#exit
Router#
%SYS-5-CONFIG_I: Configured from console by console
show ip access
Router#show ip access-lists
Standard IP access list 1
  permit host 172.16.1.1
  permit host 172.16.2.2
Router#
Router(config)#int FastEthernet0/0
Router(config-if)#ip access-group 1 in ← reapply to the interface

The commands above may not work if you are using Packet Tracer. Also, please do try these commands on a router because they are exam topics. Bear in mind that you should disable the ACL on the interface (so it’s no longer live) before you edit it in order to avoid strange or unpredictable behaviour. I’ll show you how to edit live ACLs on IOS 12.4 and later shortly.

ACL Rule 6 – Disable the ACL on the interface.

Many engineers, when they want to test or deactivate the ACL for a while, will actually delete it altogether. This isn’t necessary. If you want to stop the ACL from working, simply remove it from the active interface it is applied to:

 Router(config)#int FastEthernet0/0
Router(config-if)#no ip access-group 1 in
Router(config-if)#^Z

ACL Rule 7 – You can reuse the same ACL.

I’ve seen this often on live networks. You will usually have the same ACL policy throughout your network. Rather than configuring several ACLs, simply refer to the same ACL and apply it to as many interfaces as you require. Figure 9.3 below illustrates this concept:

Figure 9.3 – You Can Reuse an ACL

ACL Rule 8 – Keep them short!

The basic rule with ACLs is to keep them short and focused. Many novice Cisco engineers stretch their ACL over many lines when, with some thought, it could be tightened to just a few lines of configuration. I’ve mentioned previously that you want your most specific lines of configuration on top. This is good practice and saves CPU cycles on the router. Good ACL configuration skills come with knowledge and practise.

ACL Rule 9 – Put your ACL as close to the source as possible.

Cisco documentation advises us to put an EXTENDED ACL as close to the SOURCE as possible and STANDARD ACL as close to the DESTINATION as possible, because that will prevent unnecessary overhead but will still allow any “legitimate” traffic.

Figure 9.4 – Put Your ACL Close to the Source

Farai says – “The official Cisco advice is EXTENDED as close to the SOURCE as possible and STANDARD as close to the DESTINATION as possible.”

Wildcard Masks

Wildcard masks are essential to learn because they are used as part of command line configuration in ACLs and some routing protocols. They exist because there has to be a way to tell the router which parts of an IP address or network address you want to match.

The matching is done at the binary level, but you can easily configure wildcard masks using the same notation you use for subnet masks. A binary 1 tells the router to ignore the digit and a 0 means match the digit.

The easy way to perform wildcard masking for the CCNA exam is simply to ensure that you add a number to the subnet mask to give you a total of 255. So, if your subnet mask in one octet was 192, you would add 63 to it to make 255. If it was 255, you would add 0. Take a look at the examples below:

You need to enter a wildcard mask if you want your ACL to match a subnet or an entire network. For example, if you wanted to match 172.20.1.0 255.255.224.0, you would enter the following:

Router(config)#access-list 1 permit 172.20.1.0 0.0.31.255

Matching subnet 192.200.1.0 255.255.255.192 would require the following:

Router(config)#access-list 1 permit 192.200.1.0 0.0.0.63

Be careful when applying network statements with OSPF, which also requires a wildcard mask.
The same principle applies when you have a network with two host bits, as you will need to enter an ACL to match these. For example, matching subnet 192.168.1.0 255.255.255.252 or /30, you will need to enter the following:

Router(config)#access-list 1 permit 192.168.1.0 0.0.0.3

I have left off some configuration, as I just want to show the relevant part. This will match hosts 1 and 2 on the 192.168.1.0 network. If you wanted to match hosts 5 and 6 on the 192.168.1.4/30 network, you would enter the following:

Router(config)#access-list 1 permit 192.168.1.4 0.0.0.3

Read through the subnetting and VLSM notes to understand this concept further. It is important!

Configuring Access Control Lists

As with any skill, repetition makes mastery. As I’ve said before, you must type on a router every example I give, do as many labs as possible, and then make up your own examples. You need to be fast and you need to be accurate, both in the exam and in the real world.

The standard and extended ACLs presented in the next sections are numbered ACLs. These represent the classic way of configuring ACLs. Named ACLs are the other way of configuring ACLs and they are presented in a subsequent section.

Standard ACLs

Standard numbered ACLs are the easiest to configure, so this is the best place to start. Standard ACLs can only filter based on a source network or IP address.

Figure 9.5 – Incoming Packet with Source and Destination

In Figure 9.5 above, the incoming packet has a source and destination address, but your standard ACL will only look at the source address. Your ACL would permit or deny this source address (see Figure 9.6):

Router(config)#access-list 1 permit host 172.16.1.1

Figure 9.6 – Network with Multiple Hosts/Networks

Router(config)#access-list 1 permit host 172.16.1.1
Router(config)#access-list 1 permit host 192.168.1.1
Router(config)#access-list 1 permit 10.1.0.0 0.0.255.255

This would be applied to the server side router. Remember that there will be an implicit “deny all” at the end of this list, so all other traffic will be blocked.

Extended ACLs

Far more granularity is built into extended numbered ACLs; however, this makes them trickier to configure. You can filter source or destination networks, ports, protocols, and services.

Generally, you can look at the configuration syntax for extended ACLs, as follows:

access list# permit/deny [service/protocol] [source network/IP] [destination network/IP]
[port#]

For example:

access-list 101 deny tcp 10.1.0.0 0.0.255.255 host 172.30.1.1 eq telnet
access-list 100 permit tcp 10.1.0.0 0.0.255.255 host 172.30.1.1 eq ftp
access-list 100 permit icmp any any

Figure 9.7 – Blocking Server Access Example

An ACL you could configure for the network above, featuring e-mail, web, and file servers, would be as follows (applied on the server side):

access-list 100 permit tcp host 172.16.1.1 host 172.20.1.1 eq smtp
access-list 100 permit tcp 10.1.0.0 0.0.255.255 host 172.30.1.1 eq ftp
access-list 100 permit tcp host 192.168.1.1 host 172.40.1.1 eq www

Or, it could be the next ACL, if you had different requirements:

access-list 101 deny icmp any 172.20.0.0 0.0.255.255
access-list 101 deny tcp 10.1.0.0 0.0.255.255 host 172.30.1.1 eq telnet

Or, it could be as follows:

access-list 102 permit tcp any host 172.30.1.1 eq ftp established

The [established] keyword tells the router to permit the traffic only if it was originated by hosts on the inside. The three-way handshake flags (ACK or RST bit) will indicate this.

Named ACLs

Unlike numbered ACLs, named ACLs can be easily identified based on their descriptive name, and this is useful especially in large configurations. They were introduced to add flexibility and ease of management of ACLs. Named ACLs can be considered more of a configuration enhancement, as it does not modify the core ACL structure (it just modifies the way we refer to an ACL).

The syntax is similar to the numbered ACLs, with the major difference of using names instead of numbers to identify ACLs. Just like in the case of numbered ACLs, you can configure standard or extended named ACLs.

Another difference when configuring named ACLs is that you always have to use the ip accesslist command, unlike with numbered ACLs, where you could also use the simple access-list command.

Router(config)#access-list ?
   <1-99>            IP standard access list
   <100-199>         IP extended access list
   <1100-1199>       Extended 48-bit MAC 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)
   <700-799>         48-bit MAC address access list
   dynamic-extended  Extend the dynamic ACL absolute timer
   rate-limit        Simple rate-limit specific access list
Router(config)#ip access-list ?
   extended    Extended access list
   log-update  Control access list log updates
   logging     Control access list logging
   resequence  Resequence access list
   standard    Standard access list
R1(config)#ip access-list standard ?
   <1-99>       Standard IP access-list number
   <1300-1999>  Standard IP access-list number (expanded range)
   WORD         Access-list name
R1(config)#ip access-list extended ?
   <100-199>    Extended IP access-list number
   <2000-2699>  Extended IP access-list number (expanded range)
   WORD         Access-list name

Named ACLs have a slightly different syntax than the other types of ACLs do (standard numbered and extended numbered). You can also edit live named ACLs, which is a useful feature. You simply need to tell the router that you want to configure a named ACL, and whether you want it to be standard or extended. You can also edit numbered ACLs with later IOS releases, so please check the documentation for your platform.

When creating a named ACL using the ip access-list command, Cisco IOS will place you in the ACL configuration mode where you can enter or remove ACL entries (denied or permitted access conditions). Figure 9.8 below shows an example of a named ACL, followed by the corresponding output:

Figure 9.8 – Named ACL

Router(config)#ip access-list extended BlockWEB
Router(config-ext-nacl)#?
Ext Access List configuration commands:
  <1-2147483647>  Sequence Number
  default         Set a command to its defaults
  deny            Specify packets to reject
  dynamic         Specify a DYNAMIC list of PERMITs or DENYs
  evaluate        Evaluate an access list
  exit            Exit from access-list configuration mode
  no              Negate a command or set its defaults
  permit          Specify packets to forward
  remark          Access list entry comment
Router(config-ext-nacl)#deny tcp any any eq 80
Router(config-ext-nacl)#permit ip any any

Named ACL verification can be done using the following commands:

• show ip access-lists: shows all ACLs created on the device.
• show ip access-lists <acl_name>: shows a particular named ACL

Router(config)#do show ip access-lists
Standard IP access list test
       30 permit 10.1.1.1
       20 permit 192.168.1.1
       15 permit 172.20.1.1
       10 permit 172.16.1.1

To learn how you can add or delete ACL entries in a named ACL, please refer to the “ACL Sequence Numbers” section below.

Applying ACLs

In order to come into effect, you must apply your ACL to an interface or router port. I say this because I’ve seen many novice Cisco engineers type the ACL and then wonder why it isn’t working! Or they configure it but apply the wrong ACL number or name to the interface.

If you are applying an ACL to a line, you have to specify it with the access-class command, and to an interface, it is the ip access-group command. Why Cisco have you do this, I will never know!

Here are three examples of ACLs being applied to a port or interface.

Interface:

Router(config)#int FastEthernet0/0
Router(config-if)#ip access-group 101 in

Line:

Router(config)#line vty 0 15
Router(config-line)#access-class 101 in

Interface:

Router(config)#int FastEthernet0/0
Router(config-if)#ip access-group BlockWEB in

ACL Sequence Numbers

With 12.4 onwards, you can see that Cisco IOS adds sequence numbers to each ACL entry. So now I can create an access control list and then remove a line from it.

Router(config)#ip access-list standard test
Router(config-std-nacl)#permit 172.16.1.1
Router(config-std-nacl)#permit 192.168.1.1
Router(config-std-nacl)#permit 10.1.1.1
Router(config-std-nacl)#
Router(config-std-nacl)#exit
Router(config)#exit
Router#
*Jun 6 07:38:14.155: %SYS-5-CONFIG_I: Configured from console by console access
Router#show ip access-lists
Standard IP access list test
       30 permit 10.1.1.1
       20 permit 192.168.1.1
       10 permit 172.16.1.1

Note that the sequence numbers are not displayed in the router running configuration. In order to see them you have to issue a show [ip] access-list command.

Add an ACL Line

To add a new ACL line, you can simply enter the new sequence number and then the ACL statement. The example below shows how you can add line 15 to your existing ACL:

Router#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#ip access
Router(config)#ip access-list standard test
Router(config-std-nacl)#15 permit 172.20.1.1
Router(config-std-nacl)#
Router(config-std-nacl)#do show ip access
Router(config-std-nacl)#do show ip access-lists
Standard IP access list test
       30 permit 10.1.1.1
       20 permit 192.168.1.1
       15 permit 172.20.1.1
       10 permit 172.16.1.1
Router(config-std-nacl)#

Remove an ACL Line

To remove an ACL line, you can simply enter the no <seq_number> command, like in the example below where line 20 is deleted:

Router#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#ip access
Router(config)#ip access-list standard test
Router(config-std-nacl)#no 20
Router(config-std-nacl)#
Router(config-std-nacl)#do show ip access
Router(config-std-nacl)#do show ip access-lists
Standard IP access list test
       30 permit 10.1.1.1
       15 permit 172.20.1.1
       10 permit 172.16.1.1
Router(config-std-nacl)#

Resequence an ACL

To resequence an ACL, you can use the ip access-list resequence <acl_name> <starting_seq_number> <step_to_increment> command. The behaviour of this command can be examined in the example below:

Router(config)#ip access-list resequence test 100 20
Router(config)#do show ip access-lists
Standard IP access list test
       100 permit 10.1.1.1
       120 permit 172.20.1.1
       140 permit 172.16.1.1
Router(config-std-nacl)#

The resequence command created new sequence numbers, starting from 100, and incremented them by 20 for each new ACL line.

ACL Logging

By default, ACL entries that are matched by packets traversing a router interface create incremental counters that can be analysed using the show ip access-lists command, as can be seen in the example below:

Router#show ip access-lists
Extended IP access list test
     10 deny tcp any any eq 80 (10 matches)
     20 permit ip any any (56 matches)

If you need more detailed information about the traffic that is being matched by the ACL entries, you can configure the log or log-input parameters to the relevant ACL entries.

Router(config)#ip access-list extended test
Router(config)#no 10
Router(config)#10 deny tcp any any eq 80 log
Router#show ip access-lists
Extended IP access list test
    10 deny tcp any any eq 80 log
    20 permit ip any any (83 matches)

In the configuration sample above, ACL logging for test ACL entry 10 is configured. When a packet hits that ACL entry, the ACL counters will continue to increase but the router will also generate a log message that contains details about the specific ACL hit:

%SEC-6-IPACCESSLOGP: list test denied tcp 10.10.10.2(24667) -> 10.10.10.1(80), 1 packet

If you need even more details about the transaction, you can replace the log paramter with the log-input parameter,as you can see in the example below:

Router(config)#ip access-list extended test
Router(config)#no 10
Router(config)#10 deny tcp any any eq 80 log-input
Router#show ip access-lists
Extended IP access list test
    10 deny tcp any any eq 80 log-input
    20 permit ip any any (125 matches)

When the specific ACL entry is hit, a more detailed log message is generated by the router, which includes the incoming interface and the source MAC address:

%SEC-6-IPACCESSLOGP: list test denied tcp 10.10.10.2(14013) (FastEthernet0/0 00aa.aabb.ccdd) -> 10.10.10.1(80), 1 packet

ACL logging can be very useful for troubleshooting to see what exactly is dropped/permitted, but one thing must be noted for real-world situations (this is beyond the scope of the CCNA exam): ACL entries that contain [log] or [log-input] keyword are process-switched by the router (as opposed to being CEF-switched, which is the default in modern routers – this will be covered later in the book). This requires more router CPU cycles, which can become a problem if there is a lot of traffic that is hitting the logged ACL entry.

Using ACLs to Limit Telnet and SSH Access

Besides filtering the traffic on an interface level, ACLs can be associated with many other device features, including filtering traffic on VTY lines. In a previous module, you learned how you can configure Telnet or SSH acsess to a device (e.g., router or switch) using the line vty command.

Sometimes you may not want to accept all Telnet/SSH connections to or from the device. In order to manipulate this you must define an ACL that defines the type of traffic that will be allowed or denied on the VTY line. The ACL can be numbered or named. You associate the ACL to the VTY line using the access-class <acl> [in|out] command.

The following example defines an ACL permitting Telnet traffic from host 10.10.10.1, which will then be applied inbound to the VTY lines:

Router(config)#ip access-list extended VTY_ACCESS
Router(config-ext-nacl)#permit tcp host 10.10.10.1 any eq telnet
Router(config-ext-nacl)#deny tcp any any
Router(config-ext-nacl)#exit
Router(config)#
Router(config)#line vty 0 4
Router(config-line)# access-class VTY_ACCESS in
Router(config-line)#

You can verify the configuration using the following commands:

Router#show run | sect line vty
line vty 0 4
access-class VTY_ACCESS in
.....

Troubleshooting and Verifying ACLs

I think that with an understanding of the configuration commands and rules you should be fine with access control lists. If your ACL isn’t working, first check that there is basic IP connectivity by pinging. Then check whether you have applied your ACL, that there are no typos, and whether you need to allow any IP traffic to pass (remember the implicit “deny all”). Some of the most important verification steps in the ACL troubleshooting process include:

• Verifying the ACL statistics
• Verifying the permitted networks
• Verifying the ACL interface and direction

Verifying the ACL Statistics

After you have successfully configured an ACL and applied it to an interface, it is very important to have a method by which you can verify the correct behaviour of the ACL, especially how many times an ACL entry has been used (hit). Based on the number of hits, you can adjust your filtering policy or you can enhance your ACLs to improve the overall security. Based on your needs, you can verify the ACL statistics on a global level or per interface (starting with IOS 12.4).

Global ACL Statistics

Global ACL statistics can be verifyied using the show ip access-list or show access-list commands, which can refer to a numbered or a named ACL:

Router#show ip access-lists
Extended IP access list test
    10 deny tcp any any eq 80 (10 matches)
    20 permit ip any any (56 matches)

This method may not provide very specific information in situations in which you apply the same ACL on different interfaces, as it offers overall statistics.

Per Interface ACL Statistics

In situations where you want to examine per interface ACL hits, either inbound or outbound, you can use the show ip access-list interface <interface_number> [in|out] command, as illustrated below:

Router#show ip access-list interface FastEthernet0/1 in
Extended IP access list 100 in
    10 permit ip host 10.10.10.1 any (5 matches)
    30 permit ip host 10.10.10.2 any (31 matches)

If no direction is specified, any input or output ACL applied to the specific interface is displayed. This feature is also called “ACL Manageability” and is available starting with IOS 12.4.

Verifying the Permitted Networks

Sometimes, especially in large environments where you have to configure many ACLs, you can make typo errors when configuring the ACL entries and this can lead to wrong traffic flows being blocked on different interfaces. In order to verify the correct ACL entries (permit and deny statements) you can use either the show run | section access-list or the show ip access-list commands, as described in previous sections.

Verifing the ACL Interface and Direction

One common error when applying an ACL to an interface is applying it in the wrong direction, meaning inbound instead of outbound and outbound instead of inbound. This can cause a lot of issues, both from a functionality and security perspective. One of the first steps you should take in an ACL troubleshooting process is verifying that the ACL is applied to the correct interface and in the correct direction.

Multiple commands exist to verify this, including the show run and the show ip access-list interface <interface> [in|out] commands.

Section 9 Questions

1. You can have a named, extended, and standard ACL on one incoming interface. True or
false?
2. You want to test why your ping is blocked on your Serial interface. You ping out from the
router but it is permitted. What went wrong? (Hint: See ACL Rule 4.)
3. Write a wildcard mask to match subnet mask 255.255.224.0.
4. What do you type to apply an IP access control list to the Telnet lines on a router?
5. How can you verify ACL statistics per interface (name the command)?
6. How do you apply an ACL to an interface?

Section 9 Answers

1. False. You can only configure a single ACL on an interface per direction.
2. A router won’t filter traffic it generated itself.
3. 0.0.31.255.
4. access-class.
5. Issue the show ip access-list interface command.
6. Issue the ip access-group <ACL_name> [in|out] command.

Section 9 Labs

Standard ACL Lab

Topology

 

Purpose

Learn how to configure a standard ACL.

Walkthrough

1. Configure the network above. Add a static route on each router so any traffic for any network leaves the Serial interface. You are doing this because, though not a routing lab, you still need the traffic to route. Add .1 to the Router A Serial interface and .2 to the Router B Serial interface.

RouterA(config)#ip route 0.0.0.0 0.0.0.0 s0/1/0
RouterB(config)#ip route 0.0.0.0 0.0.0.0 s0/1/0

2. Configure a standard ACL on Router A permitting the 192.168.1.0/10 network. By default, all other networks will be blocked.

RouterA(config)#access-list 1 permit 192.168.1.0 0.0.0.63
RouterA(config)#int Serial0/1/0
RouterA(config-if)#ip access-group 1 in
RouterA(config-if)#exit
RouterA(config)#exit
RouterA#

3. Test the ACL by pinging from Router B, which by default will use the 10.0.0.1 address.

RouterB#ping 10.0.0.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.1, timeout is 2 seconds:
UUUUU
Success rate is 0 percent (0/5)

4. Test another ping, but source it from 192.168.1.1 and this should work.

RouterB#ping
Protocol [ip]:
Target IP address: 10.0.0.1
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: 192.168.1.1
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 31/31/32 ms

Extended ACL Lab

Topology

Purpose

Learn how to configure an extended ACL.

Walkthrough

1. Configure the network above. Add a static route on Router B so any traffic for any network leaves the Serial interface. You are doing this because, though not a routing lab, you still need the traffic to route.

RouterB(config)#ip route 0.0.0.0 0.0.0.0 s0/1/0

2. Add an extended ACL to Router A. Permit Telnet traffic to your Loopback interface only. Remember to permit Telnet also.

RouterA(config)#access-list 100 permit tcp any host 172.20.1.1 eq 23
RouterA(config)#int s0/1/0
RouterA(config-if)#ip access-group 100 in
RouterA(config-if)#line vty 0 15
RouterA(config-line)#password cisco
RouterA(config-line)#login
RouterA(config-line)#^Z
RouterA#

The ACL line above is number 100, which tells the router it is extended. What you want to allow uses TCP. It is allowing TCP from any network destined for host 172.20.1.1 on the Telnet port, which is 23. When you issue a show run command, the router actually replaces the port number with the name, as illustrated below:

access-list 100 permit tcp any host 172.20.1.1 eq telnet

3. Now test a Telnet from Router B. First, Telnet to the Serial interface on Router A, which should be blocked. Then test the Loopback interface.

RouterB#telnet 10.0.0.1
Trying 10.0.0.1 ...
% Connection timed out; remote host not responding
RouterB#telnet 172.20.1.1
Trying 172.20.1.1 ...Open
User Access Verification

Password: ←password won’t show when you type it
RouterA> ←Hit Control+Shift+6 together and then let go and press the X key to quit.

NOTE: We will be covering ACLs in other labs, but you really need to know these cold. For this reason, try other TCP ports, such as 80, 25, etc. In addition, try UDP ports, such as 53. You won’t be able to test them easily without a PC attached to Router B.

Going further, mix up the IP addresses, permitting Telnet (in this example) to the Serial interface but not the Loopback interface. Then put an ACL on Router B instead. I can’t overemphasise how important this is. If you need to wipe the ACL, you can simply type the following:

RouterA(config)#no access-list 100

Named ACL Lab

Topology

Purpose

Learn how to configure a named ACL.

Walkthrough

1. Configure the network above. Add a static route on each router so any traffic for any network leaves the Serial interface. You are doing this because, though not a routing lab, you still need the traffic to route.

RouterA(config)#ip route 0.0.0.0 0.0.0.0 s0/1/0
RouterB(config)#ip route 0.0.0.0 0.0.0.0 s0/1/0

2. Add an extended named ACL on Router B. Permit pings from host 172.20.1.1 but no other hosts or networks.

RouterB(config)#ip access-list extended blockping
RouterB(config-ext-nacl)#permit icmp host 172.20.1.1 any RouterB(config-ext-nacl)#exit
RouterB(config)#int s0/1/0
RouterB(config-if)#ip access-group blockping in
RouterB(config-if)#

3. Now test the ACL with pings from the Serial interface on Router A and the Loopback interface (which should work).

RouterA#ping 192.168.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
UUUUU
Success rate is 0 percent (0/5)
RouterA#ping
Protocol [ip]:
Target IP address: 192.168.1.1
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: 172.20.1.1
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
Packet sent with a source address of 172.20.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 31/34/47 ms

NOTE: You need to understand which service is which, as well as which port numbers various services use. Otherwise, you will really struggle to configure an ACL. This ACL is pretty straightforward and can be achieved with one line. If you had routing protocols running, then they would need to be permitted.

To permit RIP, specify the following:

access-list 101 permit udp any any eq rip

To permit OSPF, specify the following:

access-list 101 permit ospf any any

To permit EIGRP, specify the following:

access-list 101 permit eigrp any any


Related Articles

Leave a Reply

avatar