ACL for Admin Lan

[eugeneworon]

Hello!
Could you tell me how to create an extended IP access list (extended NAME_XXX), so that, for example, the administrator network has access to everything, but only restricted networks can access it? For example, I have the following networks:

192.168.10.0/24 – Vlan 10 User1 - Access to the administrator's network is denied.
192.168.20.0/24 – Vlan 20 Lan User2 - Access to the administrator's network is denied.
192.168.30.0/24 – Vlan 30 Lan User3 - Access to the administrator's network is denied.
192.168.100.0/24 – Vlan 100 Lan Server - Administrator network access allowed.
192.168.168.0/24 – Vlan 168 Lan Admin – Access to any network is allowed.

[Aref Alsouqi]

I don't think you can do that with the extended ACLs because they are not user-aware ACLs. The extended ACLs would look at the source IP, destination IP, ports, and protocol, they have other features but not users identity. Where are you planning to deploy that ACL?

[aleabrahao · Accepted solution]

Try this.

ip access-list extended NAME_XXX

Admin network can reach anything
permit ip 192.168.168.0 0.0.0.255 any

Server network can access Admin network
permit ip 192.168.100.0 0.0.0.255 192.168.168.0 0.0.0.255

Deny user VLANs to Admin network
deny ip 192.168.10.0 0.0.0.255 192.168.168.0 0.0.0.255
deny ip 192.168.20.0 0.0.0.255 192.168.168.0 0.0.0.255
deny ip 192.168.30.0 0.0.0.255 192.168.168.0 0.0.0.255

Allow all other traffic
permit ip any any
`
In short it would look like this:

permit ip 192.168.168.0 0.0.0.255 any
permit ip 192.168.100.0 0.0.0.255 192.168.168.0 0.0.0.255
deny ip 192.168.10.0 0.0.0.255 192.168.168.0 0.0.0.255
deny ip 192.168.20.0 0.0.0.255 192.168.168.0 0.0.0.255
deny ip 192.168.30.0 0.0.0.255 192.168.168.0 0.0.0.255
permit ip any any
Apply inbound on VLAN (example VLANs 10, 20, 30)

[Joseph W. Doherty]

For an ordinary extended ACL, for TCP based traffic, allowing traffic from the restricted networks into the admin network can be allowed only if the established bit is set.

For other non-TCP traffic, you're stuck unless the device supports Reflexive ACLs, and even then it may not support all kinds of your traffic.

I'm assuming your question is a student excersize.  So, see how far you can get with the information I've provided.

[Joseph W. Doherty · Accepted solution]

BTW, from reading my colleagues replies, I believe we understand your requirements differently.

Basically, there's a conflict between statements like:

192.168.10.0/24 – Vlan 10 User1 - Access to the administrator's network is denied.

And

192.168.168.0/24 – Vlan 168 Lan Admin – Access to any network is allowed.

I'm assuming what such statements intend is that VLAN 10 cannot initiate a conversation (two way traffic flow) with the admin network but that it can reply to the admin network.

Simple example: an admin network host can successfully ping or telnet a V10 host, but the converse is blocked.

Or, to put it another way, logically the admin network should be behind a firewall.  If so, I've previously provided the key information needed to accomplish that using ACL features.

In the real world, to generically protect the admin network, it probably would be behind a firewall.  Or, it might be protected by very extensive ACL(s) with many specific ACEs or using some variation of the ACL capabilities I'm pointing you to (and/or NAT/PAT).

[eugeneworon]

---

@Joseph W. Doherty  написал (-а):

Or, to put it another way, logically the admin network should be behind a firewall.  If so, I've previously provided the key information needed to accomplish that using ACL features.

---

Yes. It's really easier to restrict access this way

[David Ruess]

Hello,

If the USER and ADMIN IPs are static you could try and restrict the IPs to theose networks like below:

deny ip host 192.168.10.1 admin_Network wildcard_mask

deny ip host 192.168.20.1 admin_Network wildcard_mask

deny ip host 192.168.30.1 admin_Network wildcard_mask

permit ip host 192.168.100.0 0.0.0.255 admin_Network wildcard_mask

permit ip 192.168.168.0 0.0.0.255 admin_Network wildcard_mask

permit ip any any

-David

[eugeneworon]

Got it, added: permit tcp 192.168.10.0 0.0.0.255 192.168.168.0 0.0.0.255 established, and SMB access worked.

Networks are dynamic

[Joseph W. Doherty]

BTW, depending how tightly you want to configure the ACL, you could use an ACE, on the Admin network interface like:

Permit TCP any any established 

[Joseph W. Doherty]

Another BTW, traditionally, on software processing routers, interface ACLs consume CPU cycles and can add latency to traffic forwarding.

So, ideally, to maximize performance, you want to avoid using interface ACLs, but if you do use them, have as few ACEs as possible, and if logically possibly, place the ACEs in descending matching frequency, this to exit the ACL ASAP.

Years ago, Cisco introduced, on some routers, Turbo ACLs (aka compiled ACLs) which, I recall, reduced ACL processing impacts even for ACLs with as little as 3 ACEs (also recall, benefits proportionally improved as the number of ACEs increased).  (NB: don't know the current status of this feature, but it highlights the impact of ACL software based processing.)

Again, the above mentions the potential impact of ACL processing on software based routers.  Switches (and possibly some later gen routers) have dedicated hardware to process ACLs, so generally ACLs have almost, or even totally, no impact to such devices except in cases such as ACLs overflowing the dedicated hardware resources.  If that happens, throughput of a switch may very, very (very) much decrease.