Configuring extended ACLs

To be more precise when matching a certain network traffic, extended access lists are used. Extended access lists are more difficult to configure and require more processor time than the standard access lists, but they enable a much more granular level of control.

With extended access lists, you can evaluate additional packet information, such as:

  • source and destination IP address
  • type of TCP/IP protocol (TCP, UDP, IP…)
  • source and destination port numbers

Two steps are required to configure an extended access list:

1. configure an extended access list using the following command:

(config) access list NUMBER permit|deny IP_PROTOCOL SOURCE_ADDRESS WILDCARD_MASK [PROTOCOL_INFORMATION] DESTINATION_ADDRESS WILDCARD_MASK PROTOCOL_INFORMATION

2. apply an access list to an interface using the following command:

(config) ip access-group ACL_NUMBER in | out
NOTE
Extended access lists numbers are in ranges from 100 to 199 and from 2000 to 2699. You should always place extended ACLs as close to the source of the packets that are being evaluated as possible.

 

To better understand the concept of extended access lists, consider the following example:

Extended ACL example network

We want to enable the administrator’s workstation (10.0.0.1/24) unrestricted access to Server (192.168.0.1/24). We will also deny any type of access to Server from the user’s workstation (10.0.0.2/24).

First, we’ll create a statement that will permit the administrator’s workstation access to Server:

R1(config)#access-list 100 permit ip 10.0.0.1 0.0.0.0 192.168.0.1 0.0.0.0

Next, we need to create a statement that will deny the user’s workstation access to Server:

R1(config)#access-list 100 deny ip 10.0.0.2 0.0.0.0 192.168.0.1 0.0.0.0

Lastly, we need to apply the access list to the Fa0/0 interface on R1:

R1(config)#int f0/0
R1(config-if)#ip access-group 100 in

This will force the router to evaluate all packets entering Fa0/0. If the administrator tries to access Server, the traffic will be allowed, because of the first statement. However, if User tries to access Server, the traffic will be forbidden because of the second ACL statement.

NOTE
At the end of each access list there is an explicit deny all statement, so the second ACL statement wasn’t really necessary. After applying an access list, every traffic not explicitly permited will be denied.

 

What if we need to allow traffic to Server only for certain services? For example, let’s say that Server was a web server and users should be able to access the web pages stored on it. We can allow traffic to Server only to certain ports (in this case, port 80), and deny any other type of traffic. Consider the following example:

Extended ACL example

On the right side, we have a Server that serves as a web server, listening on port 80. We need to permit User to access web sites on S1 (port 80), but we also need to deny other type of access.

First, we need to allow traffic from User to the Server port of 80. We can do that using the following command:

R1(config)#access-list 100 permit tcp 10.0.0.2 0.0.0.0 192.168.0.1 0.0.0.0 eq 80

By using the tcp keyword, we can filter packets by the source and destination ports. In the example above, we have permitted traffic from 10.0.0.2 (User’s workstation) to 192.168.0.1 (Server) on port 80. The last part of the statement, eq 80, specifies the destination port of 80.

Since at the end of each access list there is an implicit deny all statement, we don’t need to define any more statement. After applying an access list, every traffic not originating from 10.0.0.2 and going to 192.168.0.1, port 80 will be denied.

We need to apply the access list to the interface:

R1(config)#int f0/0
R1(config-if)#ip access-group 100 in

We can verify whether our configuration was successful by trying to access Server from the User’s workstation using different methods. For example, the ping will fail:

C:\>ping 192.168.0.1

Pinging 192.168.0.1 with 32 bytes of data:

Reply from 10.0.0.1: Destination host unreachable.
Reply from 10.0.0.1: Destination host unreachable.
Reply from 10.0.0.1: Destination host unreachable.
Reply from 10.0.0.1: Destination host unreachable.

Ping statistics for 192.168.0.1:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss)

Telnetting to the port 21 will fail:

C:\>telnet 192.168.0.1 21
Trying 192.168.0.1 ...
% Connection timed out; remote host not responding

However, we will be able to access Server on port 80 using our browser:

HTTP successful


Download our Free CCNA Study Guide PDF for complete notes on all the CCNA 200-301 exam topics in one book.

We recommend the Cisco CCNA Gold Bootcamp as your main CCNA training course. It’s the highest rated Cisco course online with an average rating of 4.8 from over 30,000 public reviews and is the gold standard in CCNA training: