Access Control Lists (ACLs) – Part 6

As you may recall, we can use extended IP ACLs to filter packets based on source address, destination address, transport layer protocols, and other options, as follows:

• access-list 106 permit tcp host 1.2.3.4 host 5.6.7.8 eq telnet

For a packet to be permitted by ACL 106, the following must be true:

• The transport layer protocol is TCP


• The source address is 1.2.3.4


• The destination address is 5.6.7.8


• The destination port is Telnet (port 23)

Why is it the destination port, and not the source port? It’s because the port specification (“eq telnet”) follows the destination address (5.6.7.8). In ACL 106, since the source port is unspecified, it could be anything. What if instead we had written the ACL like this:

• access-list 107 permit tcp host 1.2.3.4 eq telnet host 5.6.7.8

For a packet to be permitted by ACL 107, the following must be true:

• The transport layer protocol is TCP


• The source address is 1.2.3.4


• The source port is Telnet (port 23)


• The destination address is 5.6.7.8

Thus, using an extended IP ACL gives us directional control that we don’t have with a standard IP ACL. Let’s look at an example:

• access-list 108 deny tcp host 1.2.3.4 host 5.6.7.8 eq telnet


• access-list 108 permit ip any any

Assuming that ACL 108 is placed in service correctly, it will prevent host 1.2.3.4 from opening a Telnet session to host 5.6.7.8. This is because when host 1.2.3.4 (the Telnet client) sends the TCP “syn” to host 5.6.7.8 (the Telnet server), the addresses match the “deny” line, as does the destination port of 23 (Telnet) and the transport layer protocol (TCP). Thus, the “syn” packet is denied, and the TCP session is never established.

Will ACL 108 also prevent host 5.6.7.8 from opening a Telnet session to host 1.2.3.4? Remember that for most applications, client ports are chosen randomly in the range of 1024 and above. Let’s say that when host 5.6.7.8’s Telnet client process starts, the IP stack in 5.6.7.8 assigns that process a port number of 2000. Now, when 5.6.7.8 sends a TCP “syn” to host 1.2.3.4 (the Telnet server), even though the destination port of 23 (the server) matches that specified by the “deny” line of ACL 108, as does the transport protocol (TCP), the source and destination addresses do not match (the addresses are reversed). Since the packet does not match the “deny” line, it’s permitted by the “permit” line. Thus 5.6.7.8 receives the “syn” packet, and the first phase of the TCP three-way handshake is successful.

Next, the Telnet server (1.2.3.4) will reply to the client (5.6.7.8) with a “syn ack” (the second phase of the TCP three-way handshake). For this packet, the addresses do match those specified by the “deny” line of ACL 108, as does the transport protocol (TCP), but the destination port doesn’t. Remember, the server (1.2.3.4), using port 23 (which would be the source port), is replying to the client (5.6.7.8), at port 2000 (the destination port). Since 2000 is not the destination port specified by the “deny” line of ACL 108, the packet does not match the “deny” line, and is permitted by the “permit” line. Thus, the “syn ack” makes it to 5.6.7.8.

When 5.6.7.8 then sends 1.2.3.4 an “ack” (to complete the three-way handshake), this packet is permitted as well, and the Telnet session has been successfully established. Thus, an extended IP ACL gives us directional control, which is both good and bad. It’s good, because it gives us more flexibility, but it’s bad because to deny traffic in both directions, we have to explicitly deny the traffic in both directions. In other words, to block Telnet bi-directionally between 1.2.3.4 and 5.6.7.8, but permit everything else, we could do this:

• access-list 109 deny tcp host 1.2.3.4 host 5.6.7.8 eq telnet


• access-list 109 deny tcp host 1.2.3.4 eq telnet host 5.6.7.8


• access-list 109 permit ip any any

When blocking particular protocols, be careful to permit everything you intend to permit. What does ACL 110 permit?

• access-list 110 deny tcp host 1.2.3.4 host 5.6.7.8 eq telnet


• access-list 110 deny tcp host 1.2.3.4 eq telnet host 5.6.7.8


• access-list 110 permit tcp any any

ACL 110 permits any TCP traffic that isn’t Telnet, but it doesn’t permit TFTP or VoIP (which use UDP) or ping (which uses ICMP). If you mean to permit “ip” (the entire protocol suite), then that’s what you have to say. And remember that in addition to specifying an exact port (“eq”), you can also use “lt”, “gt” or a “range” (“less-than”, “greater-than”, or a range or ports numbers, respectively).

Similarly, what if we want to block pings (ICMP echoes) from host 1.2.3.4 to the 10.0.0 network? We could do:

• access-list 111 deny icmp host 1.2.3.4 10.0.0.0 0.255.255.255 echo


• access-list 111 permit ip any any

Note that although ACL 111 will prevent host 1.2.3.4 from successfully pinging hosts on the 10.0.0.0 network, it will permit network 10.0.0.0 hosts to ping host 1.2.3.4. To block pings in both directions, you could also deny ICMP echo replies, like this:

• access-list 112 deny icmp host 1.2.3.4 10.0.0.0 0.255.255.255 echo


• access-list 112 deny icmp host 1.2.3.4 10.0.0.0 0.255.255.255 echo-reply


• access-list 112 permit ip any any

What other options are available with extended IP ACL’s? As you might recall, both standard and extended IP ACLs now count the number of matches on each line, and this can be viewed with “show access-lists”. This allows you to monitor who is doing what, or, in the case of a “deny”, who is attempting to do what.

With extended IP ACLs, you can go one step further, and have the ACL display console messages when matches occur. This is accomplished by appending the keyword “log” to lines of the ACL, like this:

• access-list 113 deny tcp host 1.2.3.4 host 5.6.7.8 eq telnet log


• access-list 113 deny tcp host 1.2.3.4 eq telnet host 5.6.7.8 log


• access-list 113 permit ip any any

Note that in ACL 113 we didn’t add the “log” option to the “permit”, because we aren’t interested in the non-Telnet traffic, and don’t want to see messages regarding that.

There are many other things that can be done with extended IP ACLs. Consult the Cisco docs for examples, and don’t forget to use the “?” to check for available keywords and options with your particular version of IOS.

Author: Al Friebe