Standard access-list example on Cisco Router

Hello LAZ,

The access-list you just mentioned filter only transit packets even though the source IP address is configured on local physical interface or loopback interface ??

Locally generated traffic will never be checked by outbound access-lists on your interfaces.

You might be able to filter some outbound locally originated traffic with CoPP policing. I havenā€™t tested this but feel free to try it :slight_smile:

R1(config) control-plane
R1(config-cp) service-policy output MY_POLICY_MAP 

Or maybe with some crazy tricks where you redirect traffic like I did in my NAT on a stick example:

1 Like

Thank you very much Rene,

I try this policy and itā€™s work :-

!
access-list 100 permit icmp host 192.168.45.4 host 192.168.45.5
!
!
class-map match-all 1
 match access-group 100
!
policy-map 1
 class 1
  drop
!
control-plane
 service-policy output 1
!

Thanks again Rene

1 Like

Hi Rene
For example If i created access list deny 10.10.10.0 0.0.0.255 and apply inbound of interface ethernet 0/1
so the traffic that incoming the router through this interface and match with this statement would be drop. what about if the same traffic incoming the router through another port but it has to go out to destination through ehternet 0/1, so the router will forward or drop this traffic.
Thank you.

1 Like

Hello Heng

So, if you create an access list deny 10.10.10.0 0.0.0.255 and apply it inbound on Fa0/1, any traffic coming INTO Fa0/1 that has a source IP address of 10.10.10.X would be dropped.

Now, if you have traffic with a source IP address of 10.10.10.X coming into interface Fa0/2 and it is being routed OUT of Fa0/1, then the traffic will NOT be dropped.

Access lists that are applied to an interface function only in ONE DIRECTION. If you want them to function in both directions, you must apply both an inbound and an outbound access list.

I hope this has been helpful!

Laz

4 Likes

Hello Lazzros Agapides
Thank you so much for your explanation now i got this .

1 Like

Hi Rene,
Thanks for this article, is there any way I can see what is the matches packets or IP address?
I have deny ip any any (274 matches), and I want to know what is denied in those 274 matches?

Thanks in advance.
Wisam

Hello Wisam,

The packets that got dropped donā€™t get logged but you can see what gets dropped realtime with a debug.

R2 is a router with an inbound access-list:

R2#debug ip packet detail 
IP packet debugging is on (detailed)

Letā€™s send a ping from R1:

R1#ping 192.168.12.2 repeat 1
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 192.168.12.2, timeout is 2 seconds:
U
Success rate is 0 percent (0/1)

This gets logged on the console:

R2#
IP: s=192.168.12.1 (GigabitEthernet0/1), d=192.168.12.2, len 100, access denied
    ICMP type=8, code=0
FIBipv4-packet-proc: route packet from GigabitEthernet0/1 src 192.168.12.1 dst 192.168.12.2
FIBfwd-proc: Default:192.168.12.2/32 receive entry
FIBipv4-packet-proc: packet routing failed
IP: tableid=0, s=192.168.12.1 (GigabitEthernet0/1), d=192.168.12.2 (GigabitEthernet0/1), routed via RIB
FIBipv4-packet-proc: route packet from (local) src 192.168.12.2 dst 192.168.12.1
FIBfwd-proc: packet routed by adj to GigabitEthernet0/1 192.168.12.1
FIBipv4-packet-proc: packet routing succeeded
IP: s=192.168.12.2 (local), d=192.168.12.1 (GigabitEthernet0/1), len 56, sending
    ICMP type=3, code=13
IP: s=192.168.12.2 (local), d=192.168.12.1 (GigabitEthernet0/1), len 56, sending full packet
    ICMP type=3, code=13
IP: s=192.168.12.1 (GigabitEthernet0/1), d=192.168.12.2, len 100, input feature
    ICMP type=8, code=0, packet consumed, Access List(47), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE

The last line shows that this packet got ā€œconsumedā€ by the access-list. If you do this on a production router, make sure you add an access-list for your debug or your router gets overburdened with debug messages:

R2#debug ip packet detail ?
  <1-199>      Access list
  <1300-2699>  Access list (expanded range)
  <cr>

Hope this helps!

Rene

Access list can be aplied on switches? How could be this possible due to the fact that switches are layer 2 devices?

1 Like

Hello Rodriarz,

A switch makes forwarding decisions based on layer 2 addresses. However if your switch is running the right image it will have the ability to use an access list to control what traffic goes through the switching process.

The switch can inspect the layer 3 info (with the right image it can also use layer 2 info in an ACL) and decide whether or not the packet should be denied or allowed. If the packet is denied the packet is dropped. If the packet is allowed it will then go through the normal switching process (the switch looking at the source and destination mac address of the frame and making a decision based on the cam table) Essentially the acl takes effect before the switching process happens.

I hope this helps,
Scott

Hello Scott! Thanks for the answering! What do you mean about ā€œthe right imageā€? There is images on switches that cannot analyze the acces list before the switching proccess?

2 Likes

I try to answer as many questions as I can to expand my knowledge , and to help others and maybe one day they can return the favor when I need help. Anywho there are different images that can be used on a switch for example lan lite and lan base. The differences between the two are their features. For example the lan lite can do ACLs but only for virtual interfaces not physical ones. Below is a link to a cisco article explaining ACLs on a switch and what different features the different images support.

I hope this helps,
Scott

1 Like

Thank you so much scott!! I really appreciate it! Now I have a better understanding about acl on switches

2 Likes

Hi Rene
As you mentioned example for standard access list , if we deny the network between 2 router , will it block any management traffic having source ip from subnet 192.168.12.1 from R1 to R2. Kindly need your help

Hello Muhammad

If you apply the access list as in the lesson, then access to anything (management traffic, data traffic etc) that goes through that interface that matches the access list will be blocked or allowed based on the particular parameters of that access list. So if you have an access list that denies the 192.168.10.0/24 subnet and is applied to the interface in an ā€œinā€ direction and you attempt to connect to the device through that interface with management traffic or otherwise, the packet will be dropped.

Now if by management traffic you mean the VTY lines, then, the same thing will occur, because in order to access the VTY lines, which are virtual management interfaces, you still have to go through the same physical interface and be scrutinized by the same access list.

I hope this has been helpful!

Laz

i am confused with inbound or outbound acces-list, we have two routers R1 and R2, i thought that, when a i want to block traffic from R1 to R2 and I am R1 so I configure outbound on R1 for outgoing traffic and from R2 perspective inbound for incomming trafic.
For example inbound, traffic from the internet and outbound, from my internal network to the internet?

1 Like

Hello Jan

I believe you got it right. When dealing with ā€œinboundā€ and ā€œoutboundā€ ACLs, you must look at the particular interface in question, and determine the direction of traffic flow you want to filter.

Now in the example that you suggested, if you have traffic going from R1 to R2, then you can filter it with an outbound ACL on the Fa0/0 interface of R1, OR you can filter it with an inbound ACL on the Fa0/0 interface of R2. Or technically you can do both, but that would be kind of redundant.

You can choose the location of the ACL (on R1 or R2) depending on your traffic. Standard access lists should be placed as close as possible to the destination for which you want to filter traffic. The reasoning behind it is that, because standard access-lists can filter traffic based only on the source address, they should be put far away from the actual source to avoid excessive filtering. So in your example, the ACL should be placed on the Fa0/0 interface of R2.

I hope this has been helpful!

Laz

2 Likes

Hello laz,
in this lesson, you use a standard ā€œinboundā€ access-list. Can you confirm that the ā€œbest practiceā€ rather recommend the standard outbound access list, but that the use of a loopback port, if it allows the insertion of standard outbound acl, prevents its application, and that ping to the loopback containing that outbound acl will work, alas, for all source ip? (or is it a limitation of packet tracer?)

Hello Hugues

In this lesson, the standard inbound access list is applied to Fa0/0 of R2. So any ping coming from R1 destined for the loopback will be blocked on its way in. Standard access lists filter based on the source address. For this reason, best practice is to place the access list as close as possible to the expected source of traffic.

Now if you want to filter traffic on a loopback interface, configuring an ACL on the loopback interface itself will not filter traffic. This is true of Packet Tracer, and of real devices. This is because, by definition, a router will never filter traffic that is destined for itself. But this is true even of physical interfaces. Letā€™s say you have the following topology:

Imagine you create an access list that denies everything, and you place it on Fa0/1 of R2 like so:

access-list 99 deny any
!
interface GigabitEthernet0/1
 ip address 3.3.3.3 255.255.255.0
 ip access-group 99 in
 ip access-group 99 out
 duplex auto
 speed auto
!

Now if R1 has the appropriate routing, and you try to ping 3.3.3.3, the ping will be successful! This is because you cannot filter traffic on an interface that is destined for the IP address of that interface using an ACL. If the traffic is traversing an interface but is destined for another network (not that of the interface itself) then the ACL will be applied.

So it is not so much an issue of filtering traffic to a loopback, but traffic the IP address of the interface on which the ACL is applied.

If you want to filter such traffic, you will have to use control plane policing:

I hope this has been helpful!

Laz

ok, I understand: then best practices say that standard access lists should be applied to the equipment closest to the destination (in order to prevent a hack flow from weaving between the equipment chosen for ACL and the destination) [and not on the outbound interface closest to the destination], and in this equipment at the interface[quote=ā€œlagapides, post:39, topic:889ā€] as close as possible to the expected source of traffic. [/quote] (then inbound, not outbound, in order to save the cpu because they base their criteria on filtering only on the source IP address).

1 Like