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:

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:

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

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

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:

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:

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:

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:

Telnetting to the port 21 will fail:

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