Is there an easy way of creating an ACL for denying users?

[Dan_17717]

Hi All,

I like to create an ACL that would prevent about 50 users from accessing a particular network in our MPLS network.  I do not want to create another vlan for this. 

Let's say I want to deny this range 10.12.16.20 - 50   from accessing 10.3.0.0 network but allow then access to everthing else.  Is this how to do it?

Access-list 101 deny 10.12.16.20  0.0.0.0  10.3.0.0  0.0.255.255

Access-list 101 deny 10.12.16.21  0.0.0.0  10.3.0.0  0.0.255.255

Access-list 101 deny 10.12.16.22  0.0.0.0  10.3.0.0  0.0.255.255

-- this will go continue down to .50

Access-list 101 permit ip any any

Can I do something like this?

Access-list 101 deny 10.12.16.20 - 50  0.0.0.0 10.3.0.0  0.0.255.255

Access-list 101 permit any any

Thanks

[Richard Burts]

While it would be very convenient to be able to specify a range as the original poster suggests, Paulo is correct that this does not work. But it is not necessary to have individual lines to deny each specific host. It is possible to use ranges if they are set up on binary bit boundaries. So something like this should work and be a bit less tedious

!  deny 20 through 23

Access-list 101 deny 10.12.16.20  0.0.0.3  10.3.0.0  0.0.255.255

!  deny 24 through 31

Access-list 101 deny 10.12.16.24  0.0.0.7  10.3.0.0  0.0.255.255

!  deny 32 through 47

Access-list 101 deny 10.12.16.32  0.0.0.15  10.3.0.0  0.0.255.255

!  deny 48 and 49

Access-list 101 deny 10.12.16.48  0.0.0.1  10.3.0.0  0.0.255.255

!  deny 50

Access-list 101 deny 10.12.16.50  0.0.0.0  10.3.0.0  0.0.255.255

! now permit all other traffic

Access-list 101 permit ip any any

HTH

Rick

[Karsten Iwen · Accepted solution]

with traditional ACLs it can't be done, but it will work with the help of objects-groups:

object-group network CLIENTS

  range 10.12.16.20 10.12.16.50

!

ip access-list extended TEST

  deny   ip object-group CLIENTS 10.3.0.0 0.0.255.255

  permit ip any any

-- 

Don't stop after you've improved your network! Improve the world by lending money to the working poor:
http://www.kiva.org/invitedby/karsteni

[Richard Burts]

The response from Karsten is excellent. Object groups are a relatively recent addition to IOS and I had not remembered that they do give the ability to specify an arbitrary range of addresses and are not restricted to bit boundaries as access lists are as mentioned in my response.

Thanks

Rick

[Dan_17717]

Thanks to all.  I will give this a try when time permits.

[Joseph W. Doherty]

Disclaimer

The  Author of this posting offers the information contained within this  posting without consideration and with the reader's understanding that  there's no implied or expressed suitability or fitness for any purpose.  Information provided is for informational purposes only and should not  be construed as rendering professional advice of any kind. Usage of this  posting's information is solely at reader's own risk.

Liability Disclaimer

In  no event shall Author be liable for any damages whatsoever (including,  without limitation, damages for loss of use, data or profit) arising out  of the use or inability to use the posting's information even if Author  has been advised of the possibility of such damage.

Posting

What Karsten has suggested, would be the "cleanest" approach, but if the IOS doesn't support it, what Rick suggested would be the way to do it using the fewest ACEs.

If using Rick's approach, as he mentioned you can set ACEs on binary boundaries, variations on the "theme" might be to include a bigger block than needed, if the overage isn't harmful.  For example, when trying to exclude hosts 20 .. 50 one ACE could block 0 .. 63.

Also remember you can mix permits and denies.  So say you wanted to block just 8 .. 63, you could permit 0..7, block 0..63 and then permit any.  Depending on your requirement, mixing permits and denies might require the fewest ACEs in your ACL.

Of course the disadvange of a complicated ACL, it's harder to understand.  However, on a sofware based router, the shorter ACL might perform better.