Extended Access Lists

Extended Access Lists

“Beware of the extended access list!” This grave warning comes from many CCNA testers who have gone before you. Out of all the topics on the CCNA exam, not one has come close to tripping up candidates more than the extended access list. With most things in Cisco, the difficulty comes in the concept and the syntax is quite simple. However, when it comes to the extended access lists, the concepts are fairly straightforward; it is the syntax that can be a monster. Fear not, my brave CCNA studier. After working through this section, you will feel quite comfortable with extended access lists.

Configuration of Extended Access Lists

After you have set up a few standard access lists, you’ll have the configuration mastered. Standard access lists allow you to permit or deny network traffic based only on the source address. On the other hand, extended access lists allow you to permit or deny traffic based on the sub-protocol, source address, source port number, destination address, and destination port number—and that’s just what is on the CCNA exam. An extended access list can even filter based on time of day or user authentication.

Now if you imagine fitting all those parameters into a single line of syntax, you begin to understand why extended access list syntax can become quite long. Before we get deep into each step of the syntax, let’s take a step back and look at extended
access list parameters from a distance. First off, extended access lists are identified by the numbers 100–199, as shown by context-sensitive help:

dynamic-extended Extend the dynamic ACL absolute timer From a broad view, an extended access list requires three major parameters: a protocol, source information, and destination information. The general syntax looks like this:
Access-list <100-199> <protocol> <source_information>

Now let’s walk through the creation of an extended access list, one piece at a time. This example uses access list 150, putting it smack in the middle of the access list range. For this example, web access should be allowed for one host,
Neo(config)#access-list 150 ?
deny Specify packets to reject dynamic Specify a DYNAMIC list of PERMITs or DENYs permit Specify packets to forward
remark Access list entry comment

The first thing you notice is that you have the standard <permit/deny> option, but now a dynamic option has been added to the list. Although dynamic access lists are beyond the scope of the CCNA certification, the concept is pretty amazing: You can have an access list that allows minimal outbound or inbound access. If you have a user that needs access to a network through your
router, you can authenticate that user to the router with a pre-determined username and password.

If the authentication is successful, a dynamic entry is added to the access list allowing the device access for a certain amount of time, after which the access list entry is removed. Amazing stuff! Because extended access lists have the same implicit deny statement as standard access lists, you must permit at least one type of packet or all traffic is denied. You can now continue on
through this configuration of permitting web access for the host, using context-sensitive help to guide you through each additional piece of syntax.

Now the syntax is starting to look quite a bit different from the standard access list. You now have the choice of what protocol to permit or deny.

Although the list is quite exhaustive, for the CCNA exam you need to be concerned with only the following four protocols: IP, TCP, UDP, and ICMP.

These protocols are roughly defined as the following (the applications are explained further during the discussion on port numbers):

  • IP—Permits or denies source/destination addresses that use the entire TCP/IP protocol suite. Using this keyword permits or denies all access from a source to a destination.
  • TCP—Permits or denies source/destination addresses that use TCP-based applications. The most common applications include FTP, Telnet, SMTP, and HTTP.
  • UDP—Permits or denies source/destination addresses that use UDP-based applications. The most common applications include DNS and TFTP.
  • ICMP—Permits or denies source/destination addresses that use ICMP-based applications. The most common applications include Echo, Echo-Reply, and Unreachables.

In this example, the access list needs to permit HTTP access, which uses the TCP protocol.

From this next context-sensitive help prompt, it looks as if there is a prompt to enter either a destination IP address or port information. BEWARE! This is where most extended access list mistakes are made! As you can see from the context-sensitive help, you can enter many forms of port information: a port equal (eq) to a certain number, greater than (gt) a certain number,
less than (lt) a certain port number, a range of port numbers, and the list goes on and on.

Initially, you might think that this is the place to permit the port for HTTP access (port 80). Unfortunately, that thought process is incorrect. This area is where you discover the strange and fascinating phenomena known as a source port number.

By this point, you most likely know the commonly used port numbers such as TCP port 21 for FTP, TCP port 80 for HTTP, and so on. However, most administrators never learn that these are actually destination port numbers. For any TCP/IP-based communication, there is always a destination and source port number. Here’s how it works: imagine you have a PC connected directly to the Internet. You would like to use a web browser to access the latest news headlines; however, like most technology-based individuals, you also have 10 other web browser instances minimized at the bottom of your task bar.

You open a new web browser (instance #11) and access the news website. Sure enough, the web browser window fills with text and pictures of all the latest news and events. Now how in the world did your computer know to fill that web browser window (#11) with the information rather than one of the other 10 you had minimized at the bottom of the screen? The answer is in the source port information. As soon as you opened the web browser #11, Windows (or whatever operating system you are
using) generated a unique source port number for that window. Whenever it attempts to communicate with the destination host, it uses its unique source port number. The source port number that the operating system chooses is always above the range of “well known” ports (which range from 0–1023).

For example, imagine that the news website you want to communicate with is Fox News (www.foxnews.com), and your PC’s IP address is When the web browser opens, it generates a random source port of 3382. As shown in Figure 19.2, when the web request is sent from your PC to the Fox News web server, it is sent to the destination www.foxnews.com:80 (this is known as a socket—the combination of a destination IP address with a destination port number).

It has a source of When the Fox News website communicates back to your PC, it uses a destination of with a source address of www.foxnews.com:80. Back to the task at hand. If you enter port number information after the source IP address, you permit or deny source port information.

You will rarely, if ever, know a network device’s source port number information. This number is randomly generated by the host’s operating system.

By omitting the any source port information and continuing on to the destination address specifications, the Cisco router assumes all source ports are permitted. This example allows web access. The destination address is the entire Internet address space. This can be easily summed up with the destination address keyword of any. The following code enters the any keyword and continues to use the context-sensitive help to guide you through each additional piece of syntax.

Now you can see that you have a multitude of choices, some of which include the same port number options you were given before. Now that the destination IP address information has been specified (with the any keyword), you can now fill in the destination port number. Most of the time you will use the eq (equals to) port number syntax to designate a single port

number. The following code enters the eq keyword and continues to use the context-sensitive help to guide you through each additional piece of syntax.

Notice that the context-sensitive help now provides a list of commonly used port numbers. At the top of the list is the option <0-65536>, enabling you to enter any port number you choose. In this example, you can enter either the keyword www or port number 80 and the result will be the same.

Although you can see the list of commonly used port numbers right now, the list may not be available to you in the CCNA exam. At a minimum, you should commit the following list of ports to memory: TCP Ports:

To complete the access list, the necessary port information is added:
Neo(config)#access-list 150 permit tcp host any eq 80

As before, for the access list to take effect, it must be applied. The same syntax is used to do this as is used for the standard access list: ip access-group <in/out>. Don’t forget the best way to find the direction you should apply the access list: Imagine yourself as a router. Is the traffic going away from you (leaving one of your interfaces)? Apply the access list outbound. Is the traffic coming into you (received by one of your interfaces)? Apply the access list inbound.

Cisco recommends applying extended access lists closer to the source of the network traffic you are permitting or denying. This is completely opposite to what you do with standard access lists. The reason for the complete turnaround is that extended access lists enable you to specify source and destination requirements, whereas standard access lists allow you to specify only source requirements. With a standard access list, network traffic may have to cross an entire worldwide network just to find out that it has been denied. With extended access lists, you can designate that traffic is denied from a certain destination before that traffic ever leaves its local subnet.

Standard access lists are always applied closest to the destination. Extended access lists are always applied closest to the source.

Practical Extended Access List Examples

Because of their flexibility, extended access lists are, by far, the most commonly used access lists in production networks. This section takes a look at a few real-world requirements and puts extended access lists into action. Figure 19.3 shows the network diagram used for the extended access list examples.

Blocking a Subnet
This example blocks the Network 2 subnet from reaching the intranet server using the FTP protocol. You must first decide what router to work with. Extended access list best practices recommend denying this traffic as close to the source as possible. This means that you need to access the Maggie router. Maggie(config)#access-list ?

dynamic-extended Extend the dynamic ACL absolute timer

Because these are extended access lists, you must use access list numbers 100–199. This example uses 125.

The FTP application protocol runs on top of TCP, so this is the protocol to choose from the list: Maggie(config)#access-list 125 deny tcp ?

Be careful, now. You can enter either the destination IP address information or port number information. Remember, this first prompt enables you to enter source port information. You will rarely, if ever, enter any source port restrictions. Of course, the CCNA exam constantly tries to trick you with this often confused fact. This example continues right on to the destination IP address information. The intranet server has the address

Now you are given the option again to enter the port configurations. At this point, the router is requesting destination port information, which is what you need to use to block FTP. Before you can specify an individual port, you must first designate the eq (equal to) syntax:

You are again given a laundry list of port numbers that you can enter. You can enter the exact port number or use the commonly used port names in the list.

The first line of the access list is now created, but don’t forget that there is still an implicit deny at the end of the list. If you were to apply this list now, it would block the subnet from reaching anything. You must add at least one permit line; in this case, it is a permit any statement.

Remember that with extended access lists, the only protocol that encompasses all TCP/IP traffic is the IP protocol. Often, the TCP protocol is mistakenly chosen for the permit any statement, which results in only TCP-based applications working.

As mentioned before, the access list must permit all other traffic through. Thus, you must use the ip protocol selection followed by a source of any and a destination of any. This is accomplished in the following line:

Maggie(config)#access-list 125 permit ip any any

This line allows all TCP/IP traffic from any source to any destination. This is how to create a permit any (which overrules the implicit deny) in an extended access list. The access list is now created, but before it can take effect, it must be applied—in this case, as close to the source as possible. Looking back at Figure 19.3, you can see that the FastEthernet 0/0 interface is as close to the source as you can get (directly connected), so that is the best option.

Just like that, the first objective is accomplished. All hosts on Network 2 are denied from using FTP to access the intranet server, but permitted to do anything else. Here is the complete configuration, without commentary:

Restricting by Protocol
Allow the host on Network 1 to use only HTTP and HTTPS to access the intranet server. Do not restrict any other access to or from the Network 1 subnet.

This example allows the host on Network 1 to use HTTP and HTTPS only to access the intranet server. Do not restrict any other access to or from the Network 1 subnet. Now that you have seen a couple access list examples, you can do this with a little less commentary. The router closest to the source this time is the Homer router.

Restricting by Network
Now here’s something new! In this example, your network should block all incoming Internet traffic unless an Internet host is fulfilling a request originating from the internal network. This is one of the most common requests for networks requiring Internet access. Executives want the network to be secure, so they want to block all incoming traffic from the Internet.

However, if you plan on applying a deny ip any any–style access list to the Internet interface, you might as well unplug the cable. This is why Cisco came up with something known as the TCP-established access list command. Here’s the concept:
When a web browser connects to a web server, it typically does so on TCP port 80. To be reliable, the TCP protocol initiates all its sessions using something known as a TCP three-way handshake.

This process gets both the sending and receiving hosts on the same page and begins the data transfer. What the TCP-established command access list argument does is watch for this handshake to take place. It then opens return traffic ports to allow the contacted Internet host (and only that host) to communicate back to the internal machine requesting data. To satisfy the objective, you can access the command prompt on the Marge router and enter
the following line:


Although permitting only the TCP established sessions is very secure, it is not flawless. Cisco therefore created something known as Context Based Access Control (CBAC), implemented in firewall feature-set IOS versions. Although this is not on the exam, it is worth mentioning.

Know how to implement a TCP-established access list and what effect this type of configuration has.

Named Access List

In recent years, Cisco has introduced a much better form of access list. As the name implies, a named access list transcends the typical access list number ranges, enabling you to assign a logical name to the access list. In addition to the logical name, these named access lists also allow some simple editing. You can remove individual access list lines without deleting and re-creating the entire access list. In very recent IOS versions, the named access lists have been enhanced to allow complete flexibility of inserting and even rearranging access list entries. Named access lists are also configured from Global Configuration mode, but are prefaced with the ip command:

Notice the addition of the sequence number option! By default, the Cisco router inserts lines with sequence number increments of 10. That means that the first line you enter is sequence 10, the next will be 20, and so on. This is fantastic because you can squeeze lines in between just by choosing a sequence number in the range greater than 10 and less than 20. Here is a
brief example of this:

This resequence command makes it possible to move access list lines around! For example, if I wanted to move sequence number 10 to sequence number 35, I could enter

Marge(config)#ip access-list resequence Jeremys_List 10 35

The sequence number feature was added to all access lists (named or otherwise) in IOS version 12.2(15)T and 12.3(2)T.

About the author


Leave a Comment