Extended Access-List example on Cisco Router

Quick question.

So if I do permit tcp any any eq telnet will that only match traffic DESTINY to port 23? IE 192.168.1.1:12345 > 4.2.2.2:23 MATCH however what about the return traffic?

4.2.2.2:23 > 192.168.1.1:12345? I’m thinking about a QoS classification where that would only match the first half of the conversation.

Does that make sense?

Hi William,

That’s correct.

If you use “permit tcp any any eq telnet” then it will only match traffic that has destination port 23. In your example, it will match 192.168.1.1:12345 > 4.2.2.2:23.

The return traffic will be 4.2.2.2:23 > 192.168.1.1:12345, the source port will be 23 and the destination port is 12345.

Rene

So for QOS wouldn’t you want to mark both parts of the conversation and give it proper BW? How would you accomplish that without NBAR?

The answer to this depends on where traffic is flowing relative to where you have applied a QoS service-policy. If you take a simple network like this:

Client ---- Router ---- Server

Where you want to reserve bandwidth for telnet traffic from the client to the server and from the server back to the client, it would be something like this (all from the Router):

ip access-list extended ACL_TELNET-CLIENT-2-SERVER
permit tcp host <CLIENT> host <SERVER> eq 23

class-map CM_TELNET-CLIENT-2-SERVER
match access-group ACL_TELNET-CLIENT-2-SERVER

policy-map PM_TELNET-CLIENT-2-SERVER
class CM_TELNET-CLIENT-2-SERVER
bandwidth 100

Interface from Client----->  (config-if)#service-policy input PM_TELNET-CLIENT-2-SERVER

Now you just repeat the template that is above to capture the traffic coming back from the Server to the Client. The key difference will be how you write your ACL:

ip access-list extended ACL_TELNET-SERVER-2-CLIENT
permit tcp host <SERVER> eq 23 host <CLIENT>

class-map CM_TELNET-SERVER-2-CLIENT
match access-group ACL_TELNET-SERVER-2-CLIENT

policy-map PM_TELNET-SERVER-2-CLIENT
class CM_TELNET-SERVER-2-CLIENT
bandwidth 100

Interface from Server----->  (config-if)#service-policy input PM_TELNET-SERVER-2-CLIENT

In my experience this isn’t common practice, do you guys see it? I see more like reserving bandwidth in one direction, not the return. Is that fair to say?

The safest approach is to set QoS in both directions. At my company, we are concerned with prioritizing VOIP, print jobs, and SSH. VOIP is a bit easier since the VOIP server and phones automatically mark their traffic as DSCP EF, so we just trust those markings, but with the others, we do, in fact, mark them similar to the example I provided earlier where the classifier for return trip looks to the source port, not the destination.

If you knew that your remote sites, for example, had more of a problem with downloads saturating the bandwidth than uploads, you probably could set QoS in just the one direction and be fine. We set it both ways “just in case.”

Hi Rene,

In your example

access-list 100 permit tcp 1.1.1.0 0.0.0.255 host 2.2.2.2 eq 80
this will allow only tcp traffic with port no 80 from 1.1.1.0 to 2.2.2.2
no where you allowed telnet traffic(port 23) then how telnet is successful.

Rohitendu,
You are right that telnet traffic, by default, is port 23. However, telnet will run on any port you tell it to. In the lesson, Rene told telnet to use port 80 with the following command

telnet 2.2.2.2 80 /source-interface loopback 0

Using telnet in this way to probe whether a port is open is a very useful trick that network admins use all the time in troubleshooting/verification.

19 posts were merged into an existing topic: Extended Access-List example on Cisco Router

Hi Rene,

The lesson is really great. Thank you very much for it.

I configured the network discussed. But changed loopback of R2 with another network behind R2. The access list was configured in the “out” interface of R2 to prevent all traffic except the http traffic from loopback of R1 to reach the network which replaced the loopback of R2. As expected it filters the traffic from R1 and allows http traffic from loopback of R1. To my surprise the traffic generated in R2 irrespective of it being http or ping is not filtered by the access list eventhough it is configured in the “out” interface of R2. Wonder how this can be explained.

Thank you in advance.

Regards,
Abey

Hi @abcjacob,

There is a good answer for this. Traffic generated by the local router is never matched against access-list on one of your interfaces :slight_smile:

Rene

Hi Rene,

Thanks for your very nice article …
I want to know what about the command "ip prefix-list " . It is used to classify/select traffic. Want to know more about this . Thx

I didn’t understand the Andrew statement …

ip access-list extended ACL_TELNET-CLIENT-2-SERVER
**permit tcp host <CLIENT> host <SERVER> eq 23** [Can’t understand the syntax ]

br//zaman

Here’s an example for the prefix-list:

In the extended access-list example from Andrew, is replaced with the source IP address and with the destination IP address. The last part, eq 23 is the destination port number.

For example:

SW1(config-ext-nacl)#permit tcp host 192.16.1.1 host 192.168.2.2 eq 23

Hi Rene,

Have you tackled “lock-and-key” or dynamic ACLs anywhere ? I’ve looked around and haven’t found anything but I might have missed something.

If not will you address this at some point ?

Thanks in advance for you reply !

Hi Thery,

I see I don’t have it…I did create an example a few years ago on gns3vault.com:

I’ll add it to my list and add it later.

Rene

Here’s a rather confusing one…
I was able to figure this out in the end. However, I just need confirmation that my logic is correct. I have a router with 3 interfaces. One to the default gateway (172.16.0.1), another pointing inwards (to-LAN - 10.10.10.0/24) and another pointing to another LAN (192.168.40.0/24).

When applying an extended access list to the interface and I put OUT (ip access-group 110 OUT) as the direction the access list does not apply.

However using IN on the interface (ip access-group 110 IN) this works perfectly.

I think it’s because the default route is pointing to 172.16.0.1, which is OUT and the others are seen as IN by the router.

I’ve attached the diagram below to suit. I hope this makes sense.

Regards,
Floyd
53

Hi Floyd,

You need to think about how traffic flows through your router. INBOUND and OUTBOUND only applies to the interfaces, it doesn’t have anything to do with routing.

Looking at your topology, traffic from 192.168.40.2 to 10.10.10.8 enters the Gi0/2 interface and exits the Gi0/0 interface. It never crosses the Gi0/0/0 interface.

This is why the access-list works INBOUND on your Gi0/2 interface. You can also apply it OUTBOUND on your Gi0/0 interface and it will work :slight_smile:

Does this make sense?

Hi again,
Im practicing extended access list. I have two doubts

Im blocking access to the network 172.16.108.0/24 from the network 172.16.104./24

I dont want that the PCs from network 172.16.104.0 reach the network 172.16.108.0 but I want that PCs from network 172.16.108.0 can reach any PC of the network 172.16.104.0

Can I do that?

Because when I write the following statement

Access-list 100 deny ip 172.16.104.0 0.0.0.255 ip 172.16.108.0 0.0.0.255

I block access from both networks

Hello Helen

When you create an access list, and you do not apply it anywhere, it actually does nothing. In order for it to function, you must apply it to an interface and a direction. The interface you choose and the direction you choose will directly affect the results. Let’s say you have the following topology:

**SW1**--------(Fe0/1) R (Fe0/2)----------SW2

And you have the 172.16.104.0/24 subnet connected to SW1 and the 172.16.108/24 subnet connected to SW2. Let’s call these Network A and Network B respectively.

Now, the access list you have created is correct. It will not allow access FROM Network A TO Network B. Now you have to be sure on which interface of the Router to apply it to and in which direction.

The rule of thumb for extended access lists is to place them as close as possible to the source of the traffic. In this case, this is the 172.16.104.0/24 subnet. So, the interface of the router that is closest to the source is Fe0/1.

Now, which direction? Well the flow of data you want to block is FROM Network A TO Network B, or from SW1 to SW2. From the point of view of the Fe0/1 interface, this is INCOMING traffic.

So, you should put the command ip access-group 100 in on the Fe0/1 interface of the Router.

This should allow all traffic to go from 172.16.108.0/24 to 172.16.104.0/24 but not the other way around.

Now the problem that you are facing is the fact that you cannot ping from Network A to Network B which is what you want. But when you try to ping from Network B to Network A you also cannot ping. Why? Because the ping reaches its destination, but when it comes back as a reply, it is blocked by the access list. What you need is a reflexive access list so that any session initiated by A to B will be allowed to return.

You can learn more about reflexive access lists at this lesson.

I hope this has been helpful!

Laz

Hi Rene,
I have questions regarding ACL. I have VLAN 2 192.168.1.0/24 on L3 core switch. I would like to use ACL to block only single IP 192.168.1.2 in the range to access internet. But, I want this IP to be able to access all other VLANs we have on our core (we have more than 10 vlans). Core switch has default route point to the firewall by using VLAN 3 172.16.1.1.

L3 core switch —using VLAN 3-----Firewall----Internet

ip access-list block-internet
10 deny ip host 192.168.1.2 host 172.16.1.1 (Firewall Interface)
20 Permit ip any any
Int vlan 10
ip access-group block-internet in

It did not work. what is the proper way to do it? Any ideas? Thanks in advance.