Standard access-list example on Cisco Router

(Lazaros Agapides) #16

Hello Srikanth.

Yes, it is possible to apply two access lists to the same interface, as long as one is inbound and the other is outbound. Actually, if you take IPv6 into account you can have up to four access lists on an interface, one per direction per protocol.

I hope this has been helpful!

Laz

1 Like
(aravind c) #17

Hi Rene,

I have a query. In the below access-list 2, why pings from R1 to IP 2.2.2.2 are failing? As per statement, it should only deny traffic from 192.168.12.0, right?

R2#sh ip access-list 2 (deny traffic from n/w 192.168.12.0; permit all other n/w's)
Standard IP access list 2
    10 deny   192.168.12.0, wildcard bits 0.0.0.255 (90 matches)
    20 permit any (30 matches)
R1#pi 2.2.2.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
UUUUU
Success rate is 0 percent (0/5)
R2#sh run int fa0/0
Building configuration...

Current configuration : 119 bytes
!
interface FastEthernet0/0
 ip address 192.168.12.2 255.255.255.0
 ip access-group 2 in
 duplex auto
 speed auto
end

Please clarify.

Thanks

Aravind

(Rene Molenaar) #18

Hi Aravind,

In your deny statement, you are denying traffic from the entire 192.168.12.0/24 subnet. R1 is probably using 192.168.12.1 as its source address.

Rene

(Hussein Samir) #19

Hi Rene,

How can I filter local generated packet in the router ?

(Lazaros Agapides) #20

Hello Hussein.

When creating and implementing (extended) access lists, you are specifying how to filter traffic based on source and destination IPs, protocols, ports etc. In order to filter traffic that is generated locally by the router, you just have to determine the IP address from which it is being generated (an IP address of a local physical or loopback interface) and filter it accordingly by applying the access list to the appropriate interface(s).

You don’t have to do anything special for locally generated traffic, just make sure you have the appropriate IP address ranges included in your access lists.

I hope this has been helpful!

Laz

(Hussein Samir) #21

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 ??

(Rene Molenaar) #22

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:

(Hussein Samir) #23

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
(Heng S) #24

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.

(Lazaros Agapides) #25

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

2 Likes
(Heng S) #26

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

1 Like
(Wisam A) #27

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

(Rene Molenaar) #28

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

(Rodrigo A) #29

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

1 Like
(Kevin W) #30

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

(Rodrigo A) #31

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
(Kevin W) #32

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
(Rodrigo A) #33

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

2 Likes
(Muhammad A) #34

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

(Lazaros Agapides) #35

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