Restricting vlan access

[howithink]

Hello everyone!

So this is how my network is laid out:

ASA (firewall and vpn appliance) ====3850 (layer 3/internal router with 5 vlans defined)===2960 (Layer 2)

On our 3850 L3 device i have 5 vlans defined. One of the vlan is called "production" vlan and one of other vlan is called "services"

All vlans have access to all other vlans and each device can ping other devices in other vlans.

Devices in the "services" vlan need to authenticate to AD, DNS, DHCP located in the "production" vlan. All is good so far.

When a user users vpn, they come through have access to all vlans (using split-tunneling).

***********

Now there is a need to restrict the "services" vlan so that it cannot communicate with "production" vlan, but yet i want "production" vlan to still access all the resources (servers) in the "services" vlan. I also want servers in "services" vlan to still authenticate to AD, DNS and DHCP which are located in the "production" vlan.

Is that possible ?

[howithink]

I was thinking what if i create 2 access-lists and apply them to the outside interface of vlan "services"

Because i still need access to AD authentication, dns and dhcp which are on 2 servers in the "production" vlan:

access-list 100 permit ip any host 192.168.20.50 (AD1,DNS,DHCP)

Access-list 200 permit ip any host 192.168.20.51 (AD2, DNS)

Int vlan 10 (services)

ip access-group 100 out

ip access-group 200 out

************************

now my question is will that work? That should restrict everyone in the "services" vlan to not access anything else except these 2 specific machines for AD authentication. 

Also, am i applying these at the correct location? in vs. out.

any thoughts?

[DimaL]

You could try to do this using VACLs - exampls of cfg - http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst6500/ios/15-0SY/configuration/guide/15_0_sy_swcg/vlan_acls.html#wp1055516

[howithink]

OK so i spoke to cisco tac support and they're saying this is not possible. If you apply an access-list to deny traffic from it to another vlan, it works both way. So its all or nothing, which doesn’t make sense to me, but we worked on it for couple of hours and no success. They minute we would restrict access, all other vlans would lose connectivity to this particular vlan (services). 

Is there any other way i can restrict access to devices from a vlan going out, but yet i on another vlan can still access devices on this restricted vlan?

[Jon Marshall · Accepted solution]

They are right because acls are not stateful so they don't keep track of the connection.

What you need to able to do is say -

1) allow vlan x to make connections to vlan y and allow return traffic back

but

2) stop vlan y making connections to vlan x.  The problem is as soon as you do this you are also blocking the return traffic when vlan x made the initial connection because the acl has no idea it is return traffic as opposed to traffic initiated from y.

There are some solutions but because you have a switch you are limited ie. -

1) you can use the "established" keyword for TCP connections only. This would allow the return traffic from vlan y even though you were blocking traffic initiated from y.

I suspect it would be available on your switch (can't say for sure) but obviously the main limitation is it only works for TCP

2) reflexive acls. These would solve your problem because they dynamically build acl entries for the return traffic.

But i checked and it appears they are not supported on the 3850

3) a separate device between the vlans such as a router using reflexive acls or running a firewall, or a dedicated stateful firewall. 

You could migrate the services vlan to the ASA and route if off there which would allow you to control the traffic and in which direction but obviously it depends on the amount of traffic etc. as the ASA could become a bottleneck.

Edit - the ASA solution also depends on how it is already setup and if you have a spare interface you could use which would make it a lot easier to setup.

I should also say that a thread i was involved in a while back was dealing with the same issue and another poster suggested VACLs would solve the problem but i can't see how because they are not stateful either so you would face the same issue.

The OP in that thread never came back to say one way or the other.

Jon

[howithink]

Thanks Jon. It used to be on an ASA, but as you mentioned, due to bottleneck and constraints we took it off of ASA and on to a l3 switch some years back. And due to AD authentication which also includes some udp ports, reflexive acls won’t work. vacls wont work either as you mentioned, tac said the same thing. I guess i'll have to figure something else out. 

Thanks everyone!

[Jon Marshall]

No problem.

Just to clarify, reflexive acls do support both TCP and UDP but like i say the documentation says they are not supported on your switch.

I suspect you meant the "established" keyword, but just wanted to make sure.

Jon