How to Configure Extended ACLs – Exclusive Explanation
The number of extended ACLs starts from 100 to 199 and 2000 to 2699, providing 799 possible extended numbered ACLs. We can also create extended ACLs with the name. Extended ACLs are used more than standard ACLs because of greater control and facilities.
Extended ACLs check packet source addresses, destination addresses, protocols, and port numbers. For example, an extended ACL can simultaneously allow FTP traffic from a network to a specific destination while denying all other traffic and web browsing.
Configuring Extended ACLs
Extended ACLs can filter protocols and port numbers. Network administrators can build extremely specified extended ACLs using either the port number or the name of well-known port numbers. The extended ACLs use logical operations such as eq for equal, neq for not equal, gt for greater than, and lt for less than.
The configuration steps for extended ACLs are not different than standard ACLs. Like the standard ACLs, first, we configure ACLs, and then they are activated on an interface. The command syntax and parameters are more complex than standard ACLs due to additional features.
The order in which the statements are entered during configuration is the order in which they are displayed and processed. The command syntax for configuring Extended ACL is the following:
access-list <access-list-number> {deny | permit | remark} protocol {source source-wildcard} [operator port <port-number or name>] {destination destination-wildcard} [operator port [ port-number or name>]
The parameter detail is the following:-
access-list-number – The parameter identifies the access list using a number. The range of extended ACL is from 100 to 199 and from 2000 to 2699.
deny – it denies access if the condition is matched.
Permit – it permits access if the condition is matched.
Remarks – This parameter is used to enter a remark and comment to the access list
protocol – The common protocol is ICMP, IP, TCP and UDP. The IP keyword is used to match any protocol.
Source – This parameter specifies the number of the network or host from which the packet is being sent.
Source-wildcard – wildcard bits are applied to the source address. It is opposite to the subnet mask.
destination – This parameter specifies the destination host or network, which is the packet’s destination.
destination wild-card – This is the wildcard for the destination network.
operator – This is an optional parameter for comparing source or destination port. The possible operands are lt, gt, eq, neq, and range.
established – This is also an optional parameter for the TCP protocol only. It shows the established TCP connection.
Note:- You can see that there are many keywords and parameters for extended ACLs, but it is unnecessary to use them all when configuring an extended ACL.
Example-1 Extended ACL Configuration
In this example, suppose you are a network administrator and want to allow website browsing only from the network 192.168.2.0/24. The web traffic uses port 80 for HTTP and port 443 for HTTPS traffic. The HTTP traffic requires flow back into the network from the website accessed by the clients.
The administration also wants to restrict this return traffic to HTTP exchange from the requested website while denying all other traffic. The figure below illustrates the ACL configuration for the same.
ACL 101 allows requests to port 80 (HTTP) and port 443 (HTTPS), while ACL 104 blocks all incoming traffic except for previously established connections. The permit statement in ACL 104 allows inbound traffic using the established parameter.
The established parameter also allows traffic that originates from the 192.168.2.0/24 network to return to that network. Without an established parameter, clients can send traffic to a web server but not receive traffic returning from the web server.
Applying Extended ACLs to Interfaces
In the previous example, you configured the ACL to allow users from the 192.168.2.0/24 network to browse HTTP and HTTPS websites. The ACL is configured, but it will not filter traffic until it is applied to an interface.
Just like standard ACL, it is necessary to consider whether the traffic to be filtered is going in or out. So when a user in the network 192.168.2.0/24 accesses a website on the server, traffic goes out to router3. When a user in the network 192.168.2.0/24 receives data from the server, traffic is coming into the local router.
In the above topology, Router3 has three interfaces. Remember that an extended ACL should be applied close to the source, so the closest interface to the source in this topology is fa0/1. Web request traffic from users on the 192.168.10.0/24 LAN is inbound to the fa0/0 interface, and return traffic from established connections to users on the LAN is outbound from the fa0/0 interface. So we will apply the ACL to the fa0/0 interface in both directions, as shown in the figure below.
Example- 2 Restrict FTP Connection
In this example, we must deny FTP traffic from subnet 192.168.1.0 and allow all other traffic to server0. The FTP uses TCP port 20 and 21, therefore the ACL requires both port name keywords FTP and ftp-data or eq 20 and eq 21 to deny FTP. So if we use name, then the command would be.
access-list 103 deny tcp 192.168.1.0 0.0.0.255 host 192.168.4.2 eq ftp
access-list 103 deny tcp 192.168.1.0 0.0.0.255 192.168.4.2 eq ftp-data
If we use port numbers instead of port names, the commands would be written as:
access-list 103 deny tcp 192.168.1.0 0.0.0.255 192.168.4.2 eq 20
access-list 103 deny tcp 192.168.1.0 0.0.0.255 192.168.4.2 eq 21
I have already discussed the implied deny in standard ACL. This ACL also contains implied deny, so to prevent the implied deny any statement at the end of the ACL from blocking all traffic, the permit ip any any statement must be added to the end.
The ACL should be applied inbound on the Fa0/1 interface to filter traffic from the 192.168.1.0/24 LAN as it enters the router interface. The figure below illustrates the configuration of the above-discussed ACL.
Example-3 Restrict Telnet Connection
Like FTP traffic, we can also configure and restrict telnet to any network or individual host. The example below denies Telnet traffic from any source to 192.168.4.2 (Server0) but allows all other IP traffic. The ACL will be configured on Router2, interface Fa0/0 outbound. The permit statement has also been added to ensure no other traffic is blocked.
Creating Named Extended ACLs
Just like named standard ACLs, we can configure named extended ACLs similarly. For creating named standard ACLs, follow the steps below.
- Enter into global configuration mode.
- Use the ip access-list extended <name> command to define a name for the extended ACL and enter to named ACL configuration mode.
- In named ACL configuration mode, enter the conditions to permit or deny
- Exit the named ACL mode and apply the ACL to the desired interface.
- Return to privileged EXEC mode and verify the ACL with the show access-lists name command as well as using show running-config
- Save the entries in the configuration file with the copy running-config startup-config
- To remove a named extended ACL, use the no ip access-list extended <name> in the global configuration command.
Example of Named Extended ACL
The figure below illustrates the named extended ACLs for FTP services. We have already configured this ACL for network 192.168.1.0/24 to restrict accessing the FTP services of server0.
So, let us create the same ACL with a name for the same network. The named ACL denies the users on the 192.168.1.0/24 LAN access to the FTP service to the server and allows all other traffic. The figure below illustrates the configuration.
Verifying Extended ACLs
ACL verification is an essential step in the ACL configuration. When ACL has been configured and applied to an interface, use show commands to verify the configuration. We can verify the ACLs using “show access-list” command, “show running-config” command and “show ip interface <interface-number>” command.
The extended ACLs do not implement the same internal logic and hashing function as standard ACLs. The output and sequence numbers are the order in which the statements were entered. Host entries are not automatically listed before range entries. The show ip interface verify the ACL on the interface and the direction in which it was functional.
After verifying the ACL configuration, confirm that the ACLs work according to plan. Check to block and permit traffic as expected.
Editing Extended ACLs
As discussed earlier, extended ACL editing is the same as standard ACL editing. The methods of editing extended ACL are the following:
- Using Text editor– Copy the ACL and paste it into the text editor where the changes are made. Remove the current access list using the no access-list Copy and paste back the modified ACL into the configuration.
- Using Sequence numbers– This method deletes the sequence numbers and then re-enter the correct statement using the sequence number. Enter into named ACL configuration mode using ip access-list extended <name>. If the ACL is numbered instead of named, use the ACL number in place of the name parameter. ACEs can be inserted or removed.