Extended Access-List example on Cisco Router

lagapidis · April 14, 2019, 6:10am

Hello Liam

First you would create the ACL that matches the traffic that you need. I’m making the following assumptions:

you want the three hosts on VLAN 10 to have web access to the host on VLAN 30
you want to deny access from the three hosts on VLAN 10 to any other service on the host on VLAN 30
you want to deny access from the three hosts on VLAN 10 to any other host on VLAN 30
you want to deny access from any other host on VLAN 10 to any other host on VLAN 30

I’m making these assumptions because, if you don’t have any access lists at all, the default behaviour of the network is to allow these hosts to have access to the web host. So essentially, you want to allow the connectivity you describe, but deny everything else.

Having said that, the ACL will look something like this:

ip access-list extended my_list
 10 permit tcp host 192.168.10.1 host 172.16.52.50 eq 80
 20 permit tcp host 192.168.10.2 host 172.16.52.50 eq 80
 30 permit tcp host 192.168.10.3 host 172.16.52.50 eq 80

You would need to specify each individual host in order to achieve what you want. You don’t require any additional configurations since any packets that don’t match the access list will be denied.

Next, you must apply this to an interface. When applying extended access lists, it is best practice to place them as close as possible to the source. So the best place to employ this access list is at the Fa0/1 interface.

I hope this has been helpful!

Laz

sachin3072004 · November 2, 2019, 4:39pm

Hello Laz,

I executed following commands on cisco router.

debug ip packet 101  detail 
access-list 101 permit tcp any any

I was expecting all the tcp packets will be logged .
But I did not see any logs .
Are these the right commands to log messages ?

Thanks,
Sachin

fugazz · November 3, 2019, 2:00pm

Hi Sachin,
if you are connected to this Cisco router using telnet/ssh do not forget to enable:
Device# terminal monitor

Also check out if you are really logging required severity level. By default “debug” is logged, but you can check it by executing show command:
Device# show logging

The next thing is that logging works only on packets that are generated by router itself and on packets that are destined to router itself, other packets are CEF switched.
Logging itself does work only on Process Switched packets. To make all packets Process Switched on transit router just disable CEF on it.
Device(config)# no ip cef

So if you have for example this topology:

  (R1) ––––––––– (R2) ––––––––– (R3)
Loopback0                     Loopback0
1.1.1.1/32                    3.3.3.3/32

Imagine that R1 and R3 have loopbacks configured. If you want to ping from R1 loopback to R3 loopback then transit router is R2. Thus on R2 you should do this configuration:

R2(config)# no ip cef
R2(config)# logging monitor debugging 
R2(config)# access-list 100 permit icmp host 1.1.1.1 host 3.3.3.3
R2(config)# end
R2# terminal monitor
R2# debug ip packet 100 detail
IP packet debugging is on (detailed) for access list 100

Now when you are connected over telnet/ssh to R2 and R1 sends ping to R3 loopback sourced from R1s own loopback you should see it in debug on R2.

There is lesson for it what you definitelly want to check out:

lagapidis · November 4, 2019, 7:07am

Hello Sachin

You can enable logging on packets that are examined by an access list by adding the “log” keyword at the end of the access list statement. Any packet that matches the access list causes an information log message to be sent to the logging destination (buffer or console depending on how you have it set up). In your example, you could do the following:

access-list 101 permit tcp any any log

Once that’s done, any new packets coming in that match will be logged.

I hope this has been helpful!

Laz

temitope.ogunwola · April 16, 2020, 8:26pm

Please i have a concern…

We noticed our switch randomly block phones on vlan 34 which is odd.Some of this communication are within the same subnet and should not be hitting the access list at all.

Here is my log

.29.132(48378) (Vlan34 004e.006e.0000) -> 10.20.28.13(80), 1 packet
*Apr 15 22:03:04.421: %SEC-6-IPACCESSLOGP: list 134 denied tcp 10.20.29.132(48381) (Vlan34 004e.006e.0000) -> 10.20.28.13(80), 1 packet
*Apr 15 22:03:14.427: %SEC-6-IPACCESSLOGP: list 134 denied tcp 10.20.29.132(48383) (Vlan34 004e.006e.0000) -> 10.20.28.13(80), 1 packet
*Apr 15 22:03:15.439: %SEC-6-IPACCESSLOGP: list 134 denied tcp 10.20.29.132(48386) (Vlan34 004e.006e.0000) -> 10.20.28.13(80), 1 packet
*Apr 15 22:03:16.451: %SEC-6-IPACCESSLOGP: list 134 denied tcp 10.20.29.132(48388) (Vlan34 004e.006e.0000) -> 10.20.28.13(80), 1 packet
*Apr 15 22:03:24.412: %BUFCAP-6-DISABLE: Capture Point cap disabled.
*Apr 15 22:03:24.726: %SEC-6-IPACCESSLOGP: list 134 denied udp 10.20.29.211(57138) (Vlan34 01dc.0200.0400) -> 10.20.28.11(5060), 1 packet

The access-list 134 is below:

cisco-stack1#show ip access-list 134
Extended IP access list 134
9 permit ip any host 10.20.0.119
10 permit ip any host 10.20.28.1 (124 matches)
20 permit ip any host 10.20.22.1
29 permit ip 10.20.28.0 0.0.1.255 host 192.168.254.22
30 permit ip 10.20.28.0 0.0.1.255 host 192.168.154.205
31 permit ip 10.20.28.0 0.0.1.255 host 10.20.5.22
32 permit ip 10.20.28.0 0.0.1.255 host 10.20.5.23
40 permit udp 10.20.28.0 0.0.1.255 host 10.20.5.14 eq domain
50 permit udp 10.20.28.0 0.0.1.255 host 10.20.5.15 eq domain
60 permit ip host 10.20.28.10 host 192.168.154.49
61 permit ip host 10.20.28.10 host 192.168.154.71
62 permit ip host 10.20.28.10 any
70 permit ip host 10.20.28.11 host 192.168.154.49
71 permit ip host 10.20.28.11 any
80 permit ip host 10.20.28.12 host 192.168.154.49
81 permit ip host 10.20.28.12 host 192.168.154.71
82 permit ip host 10.20.28.12 any
90 permit ip host 10.20.28.13 host 192.168.154.49
91 permit ip host 10.20.28.13 any
92 permit ip host 10.20.28.15 any
100 deny ip any 10.0.0.0 0.255.255.255 log-input (3067200 matches)
110 deny ip any 172.16.0.0 0.0.15.255
120 deny ip any 192.168.0.0 0.0.255.255 (54250 matches

Any ideas to fix this please

Local span Capture on po1 (which goes to ip phone 10.20.29.X ) displays traffic from the ip phone to 10.20.28.13 with a destination mac of 22:Ac:1a:0c:ab:c1 which is the mac address of SVI vlan34 on the c9200L. This explains why this traffic is being processed on SVI vlan34 and consequently being processed by ACL 134 even though both devices are the same subnet.
Traffic destined for 10.20.28.13 should have the mac address of 10.20.28.13.

Kindly advice how to fix this…

lagapidis · April 20, 2020, 7:21am

Hello Temitope

So here’s what I see. You have an IP phone A with an IP address of 10.20.29.132 and it is sending traffic to device B 10.20.28.13, but both of these devices are on the same subnet, since you are using a subnet mask of 255.255.254.0. But you are seeing traffic from A going to the SVI (the default gateway?) rather than to the correct phone.

The only reason I can see this happening is that IP phone A thinks that the destination address of 10.20.28.13 is not in its own subnet so it is sending such traffic to the default gateway, and it is hitting the access list as a result. The only way this can happen is if the subnet mask of IP Phone A is incorrect. I suspect that the subnet mask is 255.255.255.0 rather than 255.255.254.0.

I hope this has been helpful!

Laz

temitope.ogunwola · April 29, 2020, 11:08pm

Thank you so much!
this has already being checked but not the case now.
Traffic destined to 10.20.28.13 should have the mac address of 10.20.28.13, this issue could be caused by a possible corruption of the arp packets being distributed along the network.

Please what could possibly be why the ip phone is mapping to its vlan gateway and not the destination server.hence traffic within the same subnet is blocked by the ACL.

please be aware that we have a GPON platform at the GPON core, and then the device that the phone connects to is a Zhone 2804GPON ONT.our phone is on vlan 24.The ACL is blocking traffic within the same subnet.

When this issue happens, those phones are sending traffic to the destination mac of their gateway regardless of the destination ip. We took several captures and confirmed this. We also took more captures and confirmed that the gateway is not sending arp replies with incorrect data to the phone.
We disabled proxy arp on the switch which would cause this behavior and the issue persisted

lagapidis · May 1, 2020, 5:58am

Hello Temitope

This is indeed an interesting situation. Can you give us some more information about your topology including information about the GPON topology? Is the phone on the customer premises? Where are the active components of the GPON network, and how do they interconnect with the 9200 device? A small diagram of your topology would help in resolving this issue.

Let us know so we can continue to help you …

Laz

joshspam83 · June 17, 2020, 12:33pm

Hey All. Quick question i’m hoping someone can shed some light on.
I’m having a look through some ACL’s that are on a L3 switch applied to a SVI inbound. I’m documenting them before migrating over to a firewall in the near future.

What reason would there be a rule that is permitting traffic from the subnet, to its own subnet? It is the first entry and has a heap of hits too.

I would have thought that traffic from within the same broadcast domain wouldn’t need to be processed by the acl applied inbound on the svi?

If i recall correctly, sometimes an acl will stop traffic generated from the router\svi itself (could use some clarification here). but i’m not sure why that would apply in this case.

With the high hits, i’m assuming becuase packets that are hitting the SVI ip\gateway are matching and the hitcount is incrementing.

Extended IP access list VLAN68_INBOUND
Prety standard ACL with permitting traffic to other networks.
Nothing unusual.

Extended IP access list VLAN68_INBOUND
    10 permit ip 172.16.68.0 0.0.3.255 172.16.68.0 0.0.3.255 (189436587 matches)
    11 permit ip any 172.16.82.0 0.0.0.255 (6110620 matches)
    12 permit ip any 172.16.83.0 0.0.0.127 (2428203 matches)
    13 permit ip any 172.16.229.16 0.0.0.15 (559334 matches)

 + more lines

Implicit deny on end

Vlan68 is up, line protocol is up
Inbound  access list is VLAN68_INBOUND

lagapidis · June 19, 2020, 7:42am

Hello Josh

Statement 10 in the access list states that any packet with a source and destination IP addresses within this range of addresses would be matched. The range is 172.16.68.0/22. In other words:

172.16.68.0 to 172.16.71.255

Now, if the VLAN68 SVI serves as the gateway for this whole range of addresses, then yes, the fact that you see matches is strange. However, it is likely that VLAN68 only serves a subset of this range. What is the IP address and subnet mask of the VLAN 68 SVI?

Here’s an example. Let’s say the SVI has an IP address of 172.16.68.1/24 and you have a host on this subnet with an IP address of 172.16.68.10. This host sends a packet to 172.16.70.10. This packet will be sent to the default gateway (SVI VLAN68) to be routed, and a match will be made on the access list because both source and destination addresses fall within the permitted range.

I hope this has been helpful!

Laz

shivam0367 · July 4, 2020, 10:12pm

https://cdn.networklessons.com/wp-content/uploads/2013/02/xstandard-access-list-example-1.png.pagespeed.ic.sWnhSnQgFw.webp

Hi Laz ,

QUESTION 1

On above figure , we have created an inbound ACL on Router 2 to permit Icmp traffic , here is the syntax

R2 (config)#access-list 100 permit icmp 1.1.1.0 0.0.0.255 host 2.2.2.2 echo
R2 (config)#access-list 100 deny ip any any

Please confirm the reachablity if we try to ping as below

R1 #Ping 2.2.2.2 (Source ip address is 192 .168.12.1 ) , the device is unreachable because in ACL , we putted the network in deny condition .
Please correct if i am wrong .

R1# Ping 2.2.2.2 source loop back 0 , device is reachable because we put the the permit statement
Please correct if i am wrong .

Now the issue came , keep in notice please

i am unable to find permit or deny statement in show access list , if we ping like this

Case 1: R1#ping 192.168.12.2

Is we get reachability if we ping like this ?
If no then how can we acheive it ?

Case 2:

R1#ping 192.168.12.2 source loopback 0

Is we get reachability if we ping like this ?
If no then how can we acheive it ?

QUESTION 2

Laz sir , request to you please illustrate the below question in simple and descriptive way .

https://i.stack.imgur.com/FMyYW.pngk

What I’m trying to do is to deny ping access from the 12.12.12.0 network to reach the 10.10.10.0 network but not deny ping access to go from 10.10.10.0 network and reach the 12.12.12.0 network. So basically PC2 and PC3 can’t ping PC0 and PC1 but PC0 and PC1 can or the other way around,this is what I tried to do so far with no success.

How can we acheive it with configuration detail and explain what it meant by the term that implementation closer to destination in standard ACL and in extended ACL it is closer to the source , i am unable to recognize it , please explain with topology

Question 3

Please explain this post as i am unable to get it in which router second permit statement allowed for echo reply and confirm that it is on outbound or inbound interface and how you decided it . Kindly explain with all syntax in lucid manner .

Post as below

Robocop(config)#access-list 100 permit icmp 1.1.1.0 0.0.0.255 host 2.2.2.2 echo
Robocop(config)#access-list 100 deny ip any any

for this case, Robocop cannot ping to ED209 ip 192.168.12.1

how can i allow robocop to ping ED209 192.168.12.1

Regards
Shivam Chaudhary

shivam0367 · July 6, 2020, 7:42pm

Hi Rene / Team ,

i have share a reference of toplogy with a statement , what i learned in this got some confusion and want to know is ACL will be possible on below task if we apply it .

Question 1

Can we apply deny and permit statement apply at a same time , if apply then what was the last statement in ACL , kindly share the syntax

A) Deny the host 192.168.1.1 communicating with 192.168.2.0 (Host to Network ) Deny
B)Permit the host 192.168.1.2 communicating with 192.168.2.0 (Host to Network ) Permit
C) Deny the Network 192.168.3.0 communicating with 192.168.2.0 (Network to Network ) Deny
D) what is the last statement .

Is that acl can we apply in real network , as what i learned from this lesson , you mentioned only deny or permit statement at a single time , can it is posiible to apply both permit and deny statement on ACL , Just let me know .

Question 2 ,

Why we create same ACL List on multiple interface or even if we have 3 or more deny or permit statement regarding the flow of traffic , you said to consider and count in one ACL . What was the reason behind this , why you call it in your lesson ?

Question 3

Request you to please share the syntax of ACL with permit or deny icmp traffic in a network , it is very tough to understand the block or permit icmp in a network .

How can we apply ACL on below given task

permit icmp traffic from one network to single host
deny icmp traffic from one network to other network
deny icmp traffic from one host to other host .
permit icmp traffic from one network to other network

Regards
Shivam Chaudhary

lagapidis · July 8, 2020, 8:22am

Hello Shivam

In such situations, the best thing to do is lab it up and experiment for yourself so that you can experience the results of such tests. This would be the most efficient way to see what happens in each case.

For case 1, if you were to ping from R1 using the command ping 192.168.12.2 then the ping will fail. This is because, by default, R1 will use the source address of the closest interface to the destination, based on the routing table. In this case, the source interface will be Fa0/0 with an IP address of 192.168.12.1. THis means that this source address will be blocked by the access list.

For case 2, you are specifying the source interface as loopback 0, so the source IP address will be 1.1.1.1 which matches the permit statement in the ACL, and is thus allowed.

In order to achieve this, you should apply an incoming extended access list on the interface of Router1 that connects to the 12.12.12.0/24 network as shown by the arrow in the diagram.

The access list should be something like this:

access-list 100 deny icmp 12.12.12.0 0.0.0.255 10.10.10.0 0.0.0.255 echo
access-list 100 permit any any

This will cause all ping requests from 12.12.12.0 to be blocked. Make sure you use the echo keyword so only ping requests are blocked. Otherwise, ping replies will also be blocked, meaning that the response to pings from 10.10.10.0/24 to 12.12.12.0/24 will be blocked.

In this case, we are using extended access lists. For blocking pings from 12.12.12.0/24, we are placing the access list as close as possible to the source, which is the interface on the router closest to this network. We could place it on Router 0 as well, but that would cause any attempted pings to traverse the yellow network as well before being blocked, and this is inefficient.

I’m not sure I understand the question. Can you please clarify what your specific question is? Thanks!

I hope this has been helpful!

Laz

lagapidis · July 10, 2020, 6:33am

Hello Shivam

An access list can have many statements in it. Each statement must be either permit or deny, however, you can have many statements of each type in a single access list. For example, the access list in this lesson has three statements, two of which are deny and one is permit:

ip access-list extended DROPICMP
 deny   icmp host 192.168.12.2 1.1.1.0 0.0.0.255
 deny   icmp host 2.2.2.2 1.1.1.0 0.0.0.255
 permit ip any any

I’m not sure I fully understand your question., however, I will try to answer. A single access list can be applied multiple times on multiple interfaces in multiple directions. So you can indeed have one access list and apply it in both directions on a single interface, or in either direction on two or more interfaces. There is nothing that limits this. You can also place multiple statements in a single access list. Access lists can have tens or even hundreds of entries if you like, with both permit and deny statements.

For the scenarios that you are describing:

permit icmp traffic from one network to single host

In order to achieve this you must specify:

protocol type of icmp
the network with the wildcard mask
the host keyword
the IP address of the host

For example, access-list 101 permit icmp 10.10.10.0 0.0.0.255 host 192.168.5.5

For each of the other cases you state, you simply replace the network or the host with the appropriate addresses, and the permit with deny wherever applicable.

I hope this has been helpful!

Laz

ajitnagarkar07 · August 2, 2021, 5:44am

Hi Team,
I have a doubt. Why is my outbound ACL does not working with traffic generated on the same router but works with traffic generated on a different router.
My topology: R1 --------- (fa0/0)R2 ----------- R3

&#35;&#35;&#35; CONFIG ON R2 ###
 ip access-group R2_OUT out
ip access-list extended R2_OUT
 deny   ip any host 1.1.1.1
 permit ip any any
R2#

R2#sho run int fa0/0
!
interface FastEthernet0/0
 ip access-group R2_OUT out
end

&#35;&#35;&#35; ACL WORKING FOR TRAFFIC GENERATED VIA R3 BUT NOT FROM R2 ###

R3#ping 1.1.1.1 source 3.3.3.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 3.3.3.3
UUUUU
Success rate is 0 percent (0/5)
R3#

R2#ping 1.1.1.1 source 2.2.2.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 2.2.2.2
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 24/28/36 ms
R2#

lagapidis · August 3, 2021, 10:42am

Hello Ajit

Locally generated traffic will never be checked by an outbound access list on the interface. Locally generated traffic is traffic that is generated from the same router that has the access list applied.

Take a look at this post for more details.

I hope this has been helpful!

Laz

james.h.holloman.ii · August 5, 2021, 3:37pm

Working on an EACL facing external network. Issue that I’m seeing is any match to “deny” statement, is not showing in the “show logging” command. I am seeing matches to “permit” statement.

Example EACL on Cisco 1941 running software 15.8.3M6 MD:

ip  access-list extended EXTERNAL_ACL_INBOUND
 deny ip 0.0.0.0 0.255.255.255 any log-input
 deny ip 10.0.0.0 0.255.255.255 any log-input
 deny ip 100.64.0.0 0.63.255.255 any log-input
 deny ip 127.0.0.0 0.255.255.255 any log-input
 deny ip 169.254.0.0 0.0.255.255 any log-input
 deny ip 172.16.0.0 0.15.255.255 any log-input
 deny ip 192.0.0.0 0.0.0.255 any log-input
 deny ip 192.0.2.0 0.0.0.255 any log-input
 deny ip 192.168.0.0 0.0.255.255 any log-input
 deny ip 198.18.0.0 0.1.255.255 any log-input
 deny ip 198.51.100.0 0.0.0.255 any log-input
 deny ip 203.0.113.0 0.0.0.255 any log-input
 deny ip 224.0.0.0 31.255.255.255 any log-input
 permit ip object-group Allowed_Services object-group Allowed_Host_Internal object-group Allowed_Host_External log-input
 deny ip any any fragments log-input
 deny tcp any any fragments log-input
 deny udp any any fragments log-input
 deny icmp any any fragments log-input
 deny ip any any log-input
 deny tcp any any log-input
 deny udp any any log-input
 deny icmp any any log-input

Console logging is set to debug:

When EACL is applied to external interface, I immediately see matches on the “permit” ACE and “deny ip any any log-input” ACE.

When I type “show logging” I see all matching entries for the “permit” ACE but there are no entries for the “deny ip any any log-input” ACE.

I am seeing the “deny ip any any log-input” matches increase as I refresh about every 5 minutes.

lagapidis · August 7, 2021, 6:34am

Hello James

Keep in mind that when you use the log-input or the log keywords after a statement in an ACL, the logging takes place in a particular way. From this Cisco Documentation, it states the following about the log and log-input keywords:

Causes an informational logging message about the packet that matches the entry to be sent to the console. (The level of messages logged to the console is controlled by the logging console command.)

The message includes the access list number, whether the packet was permitted or denied; the protocol, whether it was TCP, UDP, ICMP, or a number; and, if appropriate, the source and destination addresses and source and destination port numbers. The message is generated for the first packet that matches a flow, and then at 5-minute intervals, including the number of packets permitted or denied in the prior 5-minute interval.

So seeing an increase every five minutes is logical. This is done to alleviate CPU usage. Rather than sending out a Syslog for every single matched packet, it accumulates them and gives you a running total every five minutes.

I hope this has been helpful!

Laz

james.h.holloman.ii · August 7, 2021, 5:13pm

The issue I’m seeing is it is not showing in the logs. When I issue the “show logging”, while in the console, the denied entries are not there. Only the permit entries are there.

lagapidis · August 10, 2021, 6:57am

Hello James

So you’re seeing the matches appear on the ACL when you do a show ip access-list command, but you’re not seeing them in the logs? And only permit statements appear in the logs, but not the deny?

Well, one thing that I’m thinking is that the deny ip any any statement is a special case. It may be exempt from appearing in the logs due to the fact that it may cause a drain on the device resources. Remember the deny ip any any is a statement that is there by default at the end of all ACLs. The fact that you explicitly stated it here just places it in a different position in the ACL.

My suggestion would be to play around with the commands involved in the logging. For example, issue the logging buffered 8192 information command to ensure that informational messages are being logged. Also, you can use the ip access-list log-update threshold 10 command to have a logging message appear for every 10 hits/packets rather than every 5 minutes.

Take a look at this Cisco community thread for more insight, and let us know how you get along.

I hope this has been helpful!

Laz