Extended Access-List example on Cisco Router

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.

Hello Bruce,

Think of the destination IP address when that host sends traffic to something on the Internet. It’s not the IP address of the default gateway, but the IP address of whatever device on the Internet tries to reach.

If you want to make sure that 192.168.1.2 can only reach destinations in your VLANs but not go out to the Internet, you first need to permit traffic to those VLANs. For example:

permit ip host 192.168.1.2 172.16.10.0 0.0.0.255
permit ip host 192.168.1.2 172.16.11.0 0.0.0.255
permit ip host 192.168.1.2 172.16.12.0 0.0.0.255

Then deny all other traffic:

deny ip host 192.168.1.2 any

Then permit everything else if this doesn’t apply to other devices in the 192.168.1.0/24 subnet:

permit ip any any

If you can’t summary the subnet addresses of your VLANs and the number of VLANs might change sometimes then it’s not a bad idea to use an object-group in your ACL:

This example is for the ASA but it’s pretty much the same for Cisco IOS.

Hope this helps!

Rene

Hi Rene,

Thank you so much for your reply. That is exactly what I need. But, I am just curious. If I only block the traffic tcp port 80 and 443 , is it gonna work? Thank you.

  deny tcp host 192.168.1.2 any eq www
  deny tcp host 192.168.1.2 any eq 443
    permit ip any any

Hello Bruce

The access list entries that you have provided will block traffic with the following characteristics:

  1. A source IP address of 192.168.1.2
  2. Any source port
  3. Any destination IP address
  4. Specific destination ports 80 and 443.

So the access list will block any attempts of the host 192.168.1.2 to access an http or https server.

I hope this has been helpful!

Laz

Hello Rene/Laz,
I apologize because my question may not be completely relevant to the topic. However, I would really like to get some help if possible.

Would you please provide me a template for Border inbound ACL at the internet WAN router on the WAN interface? So far this is what I have found. Please let me know if I am missing anything.

ip access-list extended INBOUND
permit icmp any any echo
permit icmp any any echo-reply
permit icmp any any unreachable
deny icmp any any
deny ip 10.0.0.0 0.255.255.255 any
deny ip 172.16..0.0 0.15.255.255 any
deny ip 192.168.0.0 0.0.255.255 any
deny ip 127.0.0.0 0.255.255.255 any
deny ip host 0.0.0.0 any
permit ip any any

Thank you in advance.

Hello AZM

It’s a good start and you cover most of the issues that can affect the edge. You will also need to examine your network and see what additional traffic you can deny, that is, traffic that you know is invalid for your network. For example, if you will never have an FTP session initiated from the Internet to an internal host, you can block that particular port as well.

Take a look at this Cisco documentation that describes best practices for ACLs at the edge, as they are the first line of defense of your network:

I hope this has been helpful!

Laz

Question…
how would the ACL configuration be if I had three hosts (192.168.10.1, .2, .3) on vlan 10 which currently resides on Fa0/1 that need http access to a host (172.16.52.50) on vlan 30 on Fa2/1?

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

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

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:

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

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…

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

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

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

1 Like