Certified Router Support Professional Extended IP access control lists and configuration

Extended IP access control lists and configuration

Access-lists come in many flavors, including standard and extended IP access-lists as well as access-lists capable of identifying other characteristics in non-IP traffic.  Access-lists, also known as ACLs, can be named or numbered.  Identification or matching of traffic is a key concept of access-lists and is performed with each line in the ACL.  These lines or entries are also known as ACEs or Access Control Entries.  It is easy to think of access-lists as filters, but they are really a way to match or identify characteristics of a packet.  How they are then applied can make them a filter or something else.  If an access-list is identified, any traffic not matching an ACE will have an implicit deny or negative match applied to it.  Therefore if the ACL is used for filtering, anything not matched will be dropped.  This document will focus on IP Extended access-lists and how they are used to filter traffic going through a router.   In the future, I may expand on the other uses for an access-list. 

IP access-lists can be standard or extended as well as named or numbered.  The key difference between a standard and extended IP access-list is that standard access-lists only have the capability to look at the source IP Address in the packet.  Extended IP access-lists have the ability to look at source and destination IP addresses, layer 4 protocols, layer 4 specific information such as source and destination ports, and various protocol flags at layer 3 and layer 4.  So when there is a requirement for destination IP Address matching or granularity, extended IP access-lists are the way to go. 



Additionally, I mentioned that there are named and numbered access-lists.  In most cases, the capabilities of these are the same.  Named access-lists tend to be easier for me to use in a configuration due to the fact that I can name them something descriptive.  There are a few cases when a numbered access-list must be used, as well as a few instances where a named access-list must be used.  However, these cases are not directly related to the packet filtering example we will look at in this document.  When using named access-lists, the name can be something of the engineer’s choosing.  However when using numbered IP extended access-lists, the ranges of 100-199 and 2000-2699 are the only permitted values.



Prior to getting into a filtering example, let’s briefly look at traffic flow in a client server environment.  For demonstration, consider a web client accessing a web server.  There are generally multiple streams of communication that occur.  For example, a DNS request may have to occur as well as images that are imbedded within the web page.  To simplify the example, let’s just explore the IP, then the https communication that occurs to deliver the html page to the browser.




Using the above diagram as an example, we can see that we have a web client with an IP address of and a web server with an IP address of  Additionally, we probably know that web servers typically use TCP port 80.  An important thing to understand is that clients typically use a source port that is in the range of 1024-65535.  In practice, there would be different addresses and/or NAT (Network Address Translation) involved.  However for this discussion, I want to keep things simple and discuss this exactly as it is shown.



When the web client attempts to connect to the web server, an initial packet is sent.  With TCP this is part of the TCP Three Way Handshake.  This handshake is an important topic, but not really relevant to this discussion.  What is relevant is understanding that traffic flows from client to server and from server to client.  This traffic has characteristics that we can match and filter on.  Whether or not the traffic is part of the three way handshake or not, the characteristics I will discuss today are more related to the direction of the traffic.  I will mention that there are flags that are related that three way handshake that can be used for identification in extended access-lists.  I hope to expand on this document and discuss these advanced features in the future.



Using the above example what does the traffic look like that is flowing from the client to the server?  What about the traffic that is flowing from the server to the client?  Let’s take a look. 





So we can see that traffic from the client to the server has a source IP of and a destination of  Traffic from the server to the client has a source IP address of and a destination IP address of  In this example, it is fairly easy to see the “flip-flopping” of the source and destination IP addresses.  If I wanted to construct an access-list to match only the layer three information, I could the following.




Client to Server (Numbered Example)



access-list 101 permit ip host host




Client to Server (Named Example)



ip access-list extended Client2Server

permit ip host host




Server to Client (Numbered Example)



access-list 102 permit ip host host




Server to Client (Named Example)



ip access-list extended Server2Client

  permit ip host host




Now we have created our access-lists, the next thing we must do is attach them in a way that the appropriate traffic can be filtered.  An access-list can be applied per protocol, per direction, per interface.  Looking at the diagram, we are only using IP protocol and we know that an interface only has two directions, inbound and outbound.  We can also see that we have two interfaces, FastEthernet 0/0 and Serial 0/0/0.  To filter traffic from the client to the server, we can filter in two places.  The first place is inbound on FastEthernet 0/0 and the second place is outbound on Serial 0/0/0.  To filter the return traffic from the server to the client, we can filter inbound on Serial 0/0/0 or outbound on FastEthernet 0/0.  The “ip access-group” interface command is used to attach an IP access-list to an interface.  There is no difference in how this command is used with named or numbered access-lists.  So in order to restrict outbound traffic (Client to Server) to only that shown in this diagram, I can do either of the following.



interface FastEthernet0/0

ip access-group Client2Server in






interface Serial 0/0/0

ip access-group Client2Server out




Note: Either of these methods achieves the goal of only permitting the traffic in the diagram from the Client to the Server.  Instead of using “Client2Server”, the numbered ACL 101 could have also been used.  No other IP communication would be permitted in the attached direction on the interface.  Organizational goals and policies typically dictate the placement and direction of the acl attachment.



To restrict access from the server to the client to the traffic in the picture, we could attach the Server2Client access-list as follows.




interface Serial 0/0/0

ip access-group Server2Client in






interface FastEthernet 0/0

ip access-group Server2Client out



The same note would apply to this ACL attachment as well.  Therefore 102, could be used in place of the named access-list.  Additionally, inbound and outbound ACL’s can exist on the same interface.  Therefore, the following would utilize Serial 0/0/0 to restrict traffic to and from the server and clients to the traffic shown in the diagram. 




interface Serial 0/0/0

ip access-group Client2Server out

ip access-group Server2Client in




Let’s expand on this example a bit and include the layer 4 protocol and port information.  We know that that web servers typically operate on TCP Port 80.  We also know that clients typically source TCP requests from ports greater than 1023 (1024-65535).  Below is a more detailed version of the diagram that shows the TCP information.




Notice how that not only the source and destination ip addresses are swapped with traffic flowing in the opposite directions.  The TCP source and destination ports are also swapped.  This would also be true if we were discussing UDP protocol .  Another thing worth noting is that the source port in the client to server communication will not always be 1029.  That number was given as an example, but is typically any number greater than 1023.  These are known as unprivileged ports and do not require special permissions in the client operating system to open these sockets.  Let’s expand on our previous example and create two new named IP extended access-lists that have the layer four information to allow the client to utilize the web server’s port 80.  In our previous example, all IP communications between the client and server would have been permitted.




Client to Server


ip access-list extended C2S

  permit tcp host gt 1023 host eq 80




Server to Client

ip access-list extended S2C

permit tcp host eq 80 gt 1023




In this example, we can see that the keyword “ip” has been replaced by “tcp” for the protocol.  We can also see that we have port information listed.  The operator “gt” means greater than.  The operator “eq” has the meaning of equal.  So the C2S ACL has an ACE that can be read as follows:


MATCH TCP traffic with a source IP of and a source port greater than 1023 (1024-65535) and a destination IP address of with the destination port 80. 




As with the previous example, the C2S ACL can be applied inbound to FastEthernet 0/0 or outbound on Serial 0/0/0.  The S2C ACL can be applied inbound on Serial 0/0/0 or outbound on FastEthernet 0/0.  An example of both ACL’s applied in the appropriate direction on Serial 0/0/0 is as follows:



interface Serial 0/0/0

ip access-group C2S out

ip access-group S2C in




Note that by applying these ACL's to this interface, any previously attached access-groups are no longer attached to this interface.




Access-lists can be used for many functions inside a router.  One of the more common uses is for traffic filtering.  One of the areas of confusion for those less experienced is how to properly build and apply an access-list.  Traffic flows to and from sources and destinations typically mirror each other.  Understanding how this traffic appears on the network is crucial to properly building access-lists.  There are many other areas that I hope to address in the future concerning the appropriate constructions of masks and the use of more complex match criteria.  Additionally, truly using a router as a firewall requires understanding CBAC, or ip inspects.  However, understanding the key concepts outlined in this document are very important building blocks that should be understood prior to looking at more advanced features.

The main difference between Extended and Standard access lists is the variety of fields in the packet that can be compared for matching by extended access lists.  A single extended ACL statement can examine multiple parts of the packet headers, requiring that all the parameters be matched correctly to match that one ACL statement.  That matching logic is what makes extended access lists both much more useful and more more complex than standard IP ACLs.

Extended IP ACL Concepts

Standard and Extended IP Access Lists: Matching

Type of Access List What can be matched
Both standard and extended ACLs Source IP address
Portions of the source IP address using a wildcard mask
Only extended ACLs Destination IP address
Portions of the destination IP address using a wildcard mask
Protocol type (TCP, UDP, ICMP, IGRP, IGMP, and others)
Source port
Destination port
All TCP flows except the first
IP precedence

IOS checks all the matching information configured in a single access-list command.  Everything must match for that single command to be considered a match and for the defined action to be taken.  The options start with the protocol type, followed by the source IP address, source port, destination IP address, and destination port number.

access-list Statement What It Matches
access-list 101 deny ip any host Any IP packet, any source IP address, with a destination of IP address of
access-list 101 deny tcp any gt 1023 host eq 23 Packets with a TCP header, any source IP address, with a source port greater than (gt) 1023, a destination IP address of exactly, and a destination port equal to (eq) 23
access-list 101 deny tcp any host eq 23 The same as the preceding example, but any source port matches, because that parameter is omitted in this case.
access-list 101 deny tcp any host eq telnet The same as the preceding example. The telnet keyword is used instead of port 23.
access-list 101 deny udp lt 1023 any A packet with a source in network, using UDP with a source port less than (lt) 1023, with any destination IP address.

Matching TCP and UDP Port Numbers

Extended IP ACLs allow for the matching of the IP header protocol field, as well as matching the source and destination TCP or UDP port numbers.

When considering any exam question that involves TCP or UDP ports, keep the following key points in mind:

* The access-list command must use protocol keyword tcp to be able to match TCP ports and the udp keyword to be able to match UDP ports.  The ip keyword does not allow for matching the port numbers.

* The source port and destination port parameters on the access-list command are positional.  In other words, their location in the command determines if the parameter examines the source or destination port.

* Remember that ACLs can match packets sent to a server by comparing the destination port to the well-known port number.  However, ACLs need to match the source port for packets sent by the server.

* It is useful to memorize the most popular TCP and UDP applications, and their well-known ports.

For exam questions that require ACLs and matching of port numbers, first consider whether the question requires that the ACL be placed in a certain location and direction.  If so, you can then determine if that ACL would process packets either sent to the server or sent by the server.  At that point, you can decide whether you need to check the source or destination port in the packet.

Popular Applications and Their Well-Known Port Numbers

Port Number(s) Protocol Application Applications Name Keyword in access-list Command Syntax
20 TCP FTP Data ftp-data
21 TCP FTP Control ftp
23 TCP Telnet telnet
25 TCP SMTP smtp
53 UDP,TCP DNS domain
67,68 UDP DHCP nameserver
69 UDP TFTP tftp
80 TCP HTTP(WWW) www
110 TCP POP3 pop3
161 UDP SNMP snmp
16,384-32,767 UDP RTP-based voice (VoIP) and video

Extended IP ACL Configuration

Extended IP Access List Configuration Commands:

Command Configuration Mode and Description
access-list access-list-number {deny | permit } protocol source source-wildcard destination destination-wildcard [log | log-input Global command for extended numbered access lists. Use a number between 100 and 199 or 2000 and 2699, inclusive
access-list access-list-number {deny | permit} {tcp | udp} source source-wildcard [operator[port]] destination destination-wildcard [operator[port]] [established] [log] A version of the access-list command with TCP specific parameters.

The location and direction should be chosen first so that the ACL’s parameters can be planned based on the information in the packets flowing in that direction.  The ACL should be configured with access-list commands.  Then the ACL should be enabled with the same ip access-group command used with standard ACLs.  The differences in configuration between standard and extended are summarized as follows:

* Extended ACLs should be placed as close as possible to the source of the packets to be filtered, because extended ACLs can be configured so that they do not discard packets that should not be discarded.  So filtering close to the source of the packets save some bandwidth.

* All fields in one access-list command must match a packet for the packet to be considered to match that access-list statement.

* The extended access-list command uses numbers between 100-199 and 2000-2699, with no number being better than another.

The extended version of the access-list command allows for matching of port numbers using several basic operations, such as equal-to and less-than.  These are: eq, neq, lt, gt, and range.

Following the permit or deny action, the protocol parameter defines whether you want to check for all IP packets or just those with TCP or UDP headers.  When you check for TCP or UDP numbers, you must specify the TCP or UDP protocol.

With extended IP ACLs, Cisco suggest that you locate them as close as possible to the source of the packet.  Standard ACLs, Cisco suggests as close as possible to the destination.

 For Support