Only allow Specific Traffic to a VLAN

[mumbles202]

Have a quick question regarding inter-vlan routing on a 3750.  Overview of network is ISP --> ASA --> 3750 (acting as my core and default gw).  I have 5 vlan interfaces on my 3750, all w/ 192.192.x.x subnets, a 6th w/ 192.168.100.x, and a 7th w/ 192.168.200.x.  I have enabled "ip routing" on the switch and can successfully ping from subnet A to subnet B as long as both devices are using the correct DG for their vlan, which is the switch.  I have a few ports that are trunked as well that go to ESX hosts which break out the vlans according to the subnet the vm should be attached to.  The ASA is set to nat internal traffic for all the vlans.

Now my question:  short of applying an ACL to each vlan interface to block traffic from other 192.192.x.x subnets is there a better way to accomplish this?  I want my 192.168.10.x subnet to be able to reach all the subnets, but don't want 192.192.10.x to be able to talk to 192.192.20.x for example.  I was thinking to create an acl like this:

access-list 120 permit ip 192.192.10.0 0.0.0.255
access-list 120 deny ip 192.192.0.0 0.0.255.255 192.192.10.0 0.0.0.255
access-list 120 permit ip any 192.168.100.0 0.0.0.255 192.192.10.0 0.0.0.255

and then applying this to the interface for the appropriate vlan. 

[John Blakley]

Generally, you'd create an acl and apply it to your vlan svi. Your acl should look something like:

(Assuming you have a 192.168.100.1 as a vlan svi)

access-list 120 deny ip 192.168.100.0 0.0.0.255 192.192.10.0 0.0.0.255

access-list 120 permit ip any any

int vlan 100

ip address 192.168.100.1 255.255.255.0

ip access-group 120 in

You're going to need an acl for each svi if you're wanting to control all subnets from talking to only certain other subnets on the switch. By default, switches, with routing enabled, will transfer traffic between all svis.

HTH,

John

** Please rate useful posts ***

[mumbles202]

Thanks.  That was my thinking initially, just wanted to see if a better way existed.  So for my example I'd be using something like this:

access-list 120 deny ip 192.192.10.0 0.0.0.255 192.192.11.0 0.0.0.255
access-list 120 deny ip 192.192.10.0 0.0.0.255 192.192.12.0 0.0.0.255
access-list 120 permit ip any any

int vlan 10
ip address 192.192.10.1 255.255.255.0
ip access-group 120 in

access-list 121 deny ip 192.192.11.0 0.0.0.255 192.192.10.0 0.0.0.255
access-list 121 deny ip 192.192.11.0 0.0.0.255 192.192.12.0 0.0.0.255
access-list 121 permit ip any any

int vlan 11
ip address 192.192.11.1 255.255.255.0
ip access-group 121 in

My concern w/ doing it that way was adding new subnets down the road and having to go back and update the acl's, but I guess that will just need to be done as part of the process.

[ALIAOF_]

I am assuming 192.168.20.x/24 network is your database or critical network that you want to keep secure etc.  Best way to do that would be to put it behind the ASA and then use the ACL on the ASA.  That helps with the PCI and/or HIPAA compliance too.

[mumbles202]

No, it's not a DB subnet or server subnet.  All my 192.192.x.x subnets are for testing specific apps/policies/etc so there is no need for them to ever talk to each other.  My 192.168.x.x subnets do, on occassion, have to communicate w/ those subnets.  My 192.168.x.x subnets have my 3750 as their DG, and the 3750 has a default route in place that points to the firewall.  Actually I did have the 192.192.x.x vlans configured as sub-interfaces on one of the ports on the ASA and things worked to a degree.  If a device had 192.192.10.1 (ASA) as it's gateway it was able to get to internet but internal 192.168.x.x traffic failed (except icmp).  If we made it's gateway the switch internal traffic was fine but internet traffic failed if i remember correctly.  I remember it being an issue w/ asymmetric routing and to remedy it we moved the devices on the 192.192.x.x subnets to the switch for their DG, removed the corresponding sub-interface on the ASA, and created a static route on the ASA pointing to the switch for the 192.192.x.x subnet.  In the process, however, it seems we created a small issue.

Now that I think about it I'm wondering if removing the L3 vlan interface on the 3750 would have fixed the issue in the first place.  I'll try to mock it up in GNS3 today to see if I can duplicate it and see which way works.