Extended Access-List example on Cisco Router

Lessons Discussion
63

I’ll give those a try.

1 Like
64

Hello!!
My extended ACL does not work when using on the outbound interface.
Could you help me?

R1#sh ip access-lists drop-icmp
Extended IP access list drop-icmp
    8 deny ip host 1.1.1.1 host 2.2.2.2 log
    10 deny icmp host 192.168.12.1 2.2.2.0 0.0.0.255
    20 deny icmp host 192.168.12.2 1.1.1.0 0.0.0.255
    30 permit ip any any log

R1# sh run interface FastEthernet0/0
 ip address 192.168.12.1 255.255.255.0
 ip access-group drop-icmp out

R1#ping 2.2.2.2 source f0/0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/21/24 ms
R1#
*Mar  1 01:39:20.759: IP: tableid=0, s=192.168.12.1 (local), d=2.2.2.2 (FastEthernet0/0), routed via FIB
*Mar  1 01:39:20.759: IP: s=192.168.12.1 (local), d=2.2.2.2 (FastEthernet0/0), len 100, sending
*Mar  1 01:39:20.779: IP: tableid=0, s=2.2.2.2 (FastEthernet0/0), d=192.168.12.1 (FastEthernet0/0), routed via RIB
*Mar  1 01:39:20.779: IP: s=2.2.2.2 (FastEthernet0/0), d=192.168.12.1 (FastEthernet0/0), len 100, rcvd 3

Why does that ACL not work?

Thanks!

65

Hello Raphael

You have configured the ACL correctly, and your pings are performed correctly too. However, the reason why the pings are not being blocked is that ACLs will not filter locally generated traffic, that is, traffic generated by the router itself. Take a look at this NetworkLessons Note on ACLs and locally generated traffic.

I hope this has been helpful!

Laz

1 Like
66

Do outbound ACL prevent traffic that is orginated by the local router?

67

Hello David

No, an outbound ACL does not filter locally generated traffic. To do that you must use Control Plane Policing (CoPP). More info can be found at this NetworkLessons note about ACLs filtering locally generated traffic.

For more information about CoPP take a look at this lesson:

I hope this has been helpful!

Laz

68

Thanks for this lesson, is ACL editor also available for standard ACL or is that a specific feature of Extended ACL?

69

Hello David

The ACL editor is available for both extended and standard ACLs. You can enter the ACL editor for standard ACLs like so:

R1(config)#ip access-list standard 50
R1(config-std-nacl)#?
Standard Access List configuration commands:
  <1-2147483647>  Sequence Number
  default         Set a command to its defaults
  deny            Specify packets to reject
  exit            Exit from access-list configuration mode
  no              Negate a command or set its defaults
  permit          Specify packets to forward
  remark          Access list entry comment

R1(config-std-nacl)#

Just make sure that the ACL number used is a valid standard ACL number, otherwise you will get an error message like so:

R1(config)#ip access-list standard 150
% 
% Invalid access list name.
R1(config)#

I hope this has been helpful!

Laz

70

I think there is something in Extended like
range , eq , gt , it , neq that use with ports i hope you add something about them :slightly_smiling_face:

good site for creat access-list via easy inputs

71

Hello Barakat

I have created a NetworkLessons note on the topic of ACL operators that you can take a look at. Hopefully, that will be beneficial for you.

In the meantime, if you have any suggestions for particular lessons or topics, or if you think that certain content should be added, please feel free to use the Member Ideas page below:

There you may find that others have made similar suggestions, and you can add your voice to theirs.

I hope this has been helpful!

Laz

1 Like
72

Hi Rene,
What the command I should use to open ACL from source to destination for multiple ports:
permit tcp host <src IP> <dst IP> **eq** 135, 445, 17778, 177790 ?

Thank you
Sincerely,
Andrey P

73

Hello Andrey

The syntax for the access list command doesn’t allow you to add multiple port numbers on the same line. You would have to enter a different ACL entry for each port number that you want to involve. For example, if you want to permit TCP traffic on ports 80, 443, and 8080, then you would have to do something like this:

R1(config)#access-list 100 permit tcp 1.1.1.0 0.0.0.255 host 2.2.2.2 eq 80 
R1(config)#access-list 100 permit tcp 1.1.1.0 0.0.0.255 host 2.2.2.2 eq 443
R1(config)#access-list 100 permit tcp 1.1.1.0 0.0.0.255 host 2.2.2.2 eq 8080

The resulting config in the running-config file would be:

access-list 100 permit tcp 1.1.1.0 0.0.0.255 host 2.2.2.2 eq www
access-list 100 permit tcp 1.1.1.0 0.0.0.255 host 2.2.2.2 eq 443
access-list 100 permit tcp 1.1.1.0 0.0.0.255 host 2.2.2.2 eq 8080

In a similar way, you can’t apply multiple operators such as eq, lt, gt and so on. Does that make sense?

I hope this has been helpful!

Laz

1 Like
74

Hello Laz,

The lesson mentions how we would alter an access list and remove a sequence number, but it doesnt mention how we would add more statements to an existing access list. Taking one of the extended lists from the lesson as an example:

R1(config)#ip access-list extended DROPICMP  
R1(config-ext-nacl)#deny icmp host 192.168.12.2 1.1.1.0 0.0.0.255
R1(config-ext-nacl)#deny icmp host 2.2.2.2 1.1.1.0 0.0.0.255     
R1(config-ext-nacl)#permit ip any any
R1(config-ext-nacl)#exit

Assuming that the sequence number for the first stament is 10, the second is 20, third 30 and so forth, and I wanted to add two extra statements to the list we would do this:

R1(config)#ip access-list extended DROPICMP
R1(config-ext-nacl)# 21 deny icmp host 5.5.5.5.5 any
R1(config-ext-nacl)# 22 deny icmp host 7.7.7.7 any

This would add those statements with sequence numbers 21 and 22, and after doing sh access-list we should see those statements added to the list in the order determined by the sequence numbers we used, is this the correct way of adding more statements to an existing list?

The ip access-list standard/extended command is what we would always use to modify an existing access list regardless of whether its a numbered or named standard list, or a numbered or named extended list correct?

For example if we had access-list 1 deny host 10.1.1.1, we could modify by using ip access-list standard 1?

Thank You Laz!

75

Hello Paul

By default, whenever you create access lists, whether standard or extended, if you don’t include sequence numbers in your statements, by default each statement will receive a sequence number with increments of 10: 10, 20, 30, 40 and so on, as you stated in your post.

This is done so that you can more easily edit access lists, by removing statements by specifying their sequence number, or by adding statements using sequence numbers in between the existing sequence numbers. You would add and remove statements using the ip access-list standard/extended command as you mention.

The CLI gives you these capabilities, however, I find it somewhat easier to use the other option that Rene states, which is to copy and paste the ACL into a text editor, make sure everything is in order as you want it, and then just paste it back into the CLI. However, different things work for different people, and only if you try both out will you determine what’s best for you.

I hope this has been helpful!

Laz

76

Hi,

I was wondering if there is way to insert a line between sequince numbers of the access-list on NX-OS? for example if I have this

NX-OS# sh ip access-lists test_acl_out

IP access list test_acl_out
        1 remark test-acl
        2 permit tcp 10.245.112.160/27 any 
        3 permit icmp 10.250.88.128/27 any 
        4 permit ip 10.77.2.68/32 any 
        5 permit tcp 10.23.59.0/28 any eq 1002 
        6 permit tcp 10.66.10.160/28 any eq 1002

Can I somehow insert line, lets say… between seq 4 and seq 5 without removing ACL from the switch and pasting the the updted acl back in?

Thanks!

77

Hello Alex

NX-OS has a nifty feature that lets you resolve issues like this. You can actually resequence the numbering of an ACL using the following command:

resequence {ip | ipv6} access-list <name> <starting-sequence-number> <increment>

You can find details about this command at the following NX-OS command reference.

Take a look and let us know if you have any other questions.

I hope this has been helpful!

Laz

78

This is excellent! thank you so much Lazarus!

1 Like
79

I am a little bit confused by the concept of “in” and “out” directions for ACLs. For example, would traffic traversing an SVI default gateway interface towards it’s LAN subnet be subject to an ACL applied outbound on that interface?

Intuitively it seems that “out” would asessing traffic flowing out of the router and “in” would mean assessing traffic flowing into the router, but from labbing it seems that is not the case. I have had DNS traffic blocked coming into my router from a remote subnet with only an outbound ACL applied.

If it is the case that outbound ACLs assess traffic traversing Default Gateway interface-> LAN, then what is the point of having both an inbound and outbound ACL?

Any insight or clarification would be greatly appreciated :slight_smile:

80

Hello McKay

This is a good question, and it needs clarification. When we talk about physical interfaces, it’s somewhat clearer as to what “in” and “out” mean. It’s not just a matter of “into the router” and “out of the router.” It has more to do with the specific interface that we are looking at. Ingress and egress in this sense are very specific when it comes to physical interfaces.

“In” refers to traffic entering the interface, that is, traffic passing through the cable and being received and processed by the interface.

“Out” refers to traffic exiting the interface, that is, traffic generated by the interface that is being sent to the connected cable in an outbound direction.

It’s not just a matter of into or out of the router, because all traffic will enter a router and exit a router. The question is, on which interfaces will this take place?

Now, when it comes to SVIs, because they are virtual, it is somewhat more abstract. However, there is still a clear meaning for “in” and “out”.

The inbound direction of an SVI is defined as traffic that originates on one of the hosts within the VLAN that uses the SVI as a gateway. This is traffic that uses the SVI as the next hop and is routed via that SVI.

The outbound direction of an SVI is defined as traffic that is destined for one of the hosts in the VLAN served by the SVI, where packets travel from the SVI towards one of the end devices connected to the VLAN.

When you talk about a router in this case, I assume you’re not referring to the SVI example you mentioned before. Remember, an ACL will act upon any traffic on a particular interface in the direction of application. Even if you apply it in an outbound direction, if DNS requests are indeed traversing the specific interface in an outbound direction, they will still be blocked. Also, you may be observing the blocking of DNS responses and not the requests, which still results in DNS not working. You must look at the full path of the traffic, including responses, and determine how each ACL applied (and in the direction applied) will affect that traffic.

I hope this has been helpful!

Laz

81

Lazarus,

Thank you for taking the time to explain this to me. I have my traffic working as intended now.

If I “stand behind” the SVI, traffic going “out” is going towards my LAN subnet and traffic coming is is coming from my LAN subnet. When I apply the ACLs with this logic in mind, my DNS/DHCP/Web traffic all works. and RFC1918 addresses are blocked.

What am still a little confused on is what about traffic coming into the SVI from the the DNS server, which is an external subnet? Why isn’t that assessed on the inbound ACL? It seems like only traffic between my LAN subnet and SVI is accessed by ACLs.

Here is my ACL:

ip access-list extended OUT_ACL
permit udp host 10.2.1.5 eq 53 10.1.1.0 0.0.0.255
deny ip 192.168.0.0 0.0.255.255 10.1.1.0 0.0.0.255
deny ip 172.16.0.0 0.15.255.255 10.1.1.0 0.0.0.255
deny ip 10.0.0.0 0.255.255.255 10.1.1.0 0.0.0.255
permit tcp any 10.1.1.0 0.0.0.255 established
deny ip any any log
!
int vlan 10
!
ip access-group OUT_ACL out
!

ip access-list extended IN_ACL
permit udp 10.1.1.0 0.0.0.255 host 10.2.1.5 eq 53
permit udp host 0.0.0.0 host 255.255.255.255 eq 68
permit udp host 0.0.0.0 host 255.255.255.255 eq 67
deny ip 10.1.1.0 0.0.0.255 192.168.0.0 0.0.255.255
deny ip 10.1.1.0 0.0.0.255 172.16.0.0 0.15.255.255
deny ip 10.1.1.0 0.0.0.255 10.0.0.0 0.255.255.255
permit tcp 10.1.1.0 0.0.0.255 any eq 80
permit tcp 10.1.1.0 0.0.0.255 any eq 443
deny ip any any log
int vlan 10
ip access-group IN_ACL in

Thank you for your help!!

82

Hello McKay

Glad to hear that the explanation was useful and that you’ve set up your topology as desired.

Concerning this question:

You must remember that traffic from a source on another subnet, like the DNS server on 10.2.1.5, doesn’t “enter” the SVI from the LAN side. It enters the router on a different interface (e.g., a WAN interface or another VLAN/subnet where 10.2.1.0/24 is connected) and is then routed out through the SVI to your LAN.

This entry here, which is found in the IN_ACL access list:

permit udp 10.1.1.0 0.0.0.255 host 10.2.1.5 eq 53

…matches and permits DNS requests sent from hosts on your 10.1.1.0/24 subnet sent to the 10.2.1.5 device, which I assume is your DNS server. So such traffic should be permitted. Can you clarify what you mean when you say:

What is it that you want to achieve with these ACLs and the operation of the DNS server? Let us know more so we can help you further.

I hope this has been helpful!

Laz