10-11-2012 08:55 AM - edited 03-07-2019 09:24 AM
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.
10-11-2012 09:02 AM
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 ***
10-11-2012 09:15 AM
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.
10-11-2012 09:32 AM
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.
10-11-2012 09:50 AM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide