CORE: Dell N4032 (6.3.0.18) Access: Dell N2048 (6.3.1.13)
We are in the process of setting up a serviced office that will serve multiple businesses. Each "customer" will naturally be on their own VLAN, and each VLAN will require access to the Internet and some other VLANs.
There will be some open VLANs like a "Public Print" VLAN and so forth. There will also be "Server" VLANs which potentially all other VLANs will need to access (or some may not, i.e. filtered)
We have core L3 switches, 20 L2 Access Switches and two HA firewalls.
The question is whether we do the routing for the VLANs on the L3 switches themselves, or via the Firewall.
My thoughts - if we route via the firewall (i.e. Router on a Stick), all inter-VLAN traffic is going to have to go via our Firewall device, which will naturally put on a load on it's overall throughput (especially with DPI enabled). The pro being it's a hell of a lot easier to configure the firewalling between the VLANs this way.
If we route via the L3 switch, we benefit from the full throughput of the firewall for the WAN (which will be a 1Gbps connection), but the con being having to use "Policy Based Routing" on the 2 Core Switches which is generally a pain to administer.
Is there a best practice in a situation like this? What should I consider to make a decision?
UPDATE
The issue using the ACLs on the switch is as follows.
- There is a maximum of 100 ACLs
- We will have "Customer VLANs" that will require access to the Internet, to a VOIP VLAN, a Server VLAN and Print VLAN.
- They however should not have access to the other "Customer VLANs".
Problem is all "Customers" will be within one /16 - i.e.
[Parent subnet being 10.100.0.0/16]
Customer 1 - 10.100.0.0/24
Customer 2 - 10.100.1.0/24
Customer 3 - 10.100.2.0/24
I need to apply the ACLs on the VLAN so when traffic hits that VLAN it is blocked from accessing other customer VLANs.
Currently I have something like this:
1000 deny 10.100.0.0 0.0.255.255 192.168.50.0 0.255.255.255
1010 deny 10.100.0.0 0.0.255.255 192.168.60.0 0.255.255.255
1020 permit any any
This is then applied to all Customer VLAN interfaces. This solves the issue of blocking access to Server VLANs and other private VLANs, however, this doesn't prevent these VLANs from then accessing other customer VLANs (within the 10.100.0.0/16).
Problem is we could end up having 50 plus customers, which would mean an inconceivable number of ACLs (given each ACL can only have 10 entries, and each ACL would need an ACE for every other customer). This hits the max number of ACLs the switch supports almost instantly.
I just can't see another way of doing this at this stage without using our firewall as a "Router on a Stick". Any advice is greatly appreciated.
Update #2
Strange a I attempted this today with an ACL on a Customer VLAN as below (applied "IN" on the interface)
1000 deny 10.100.0.0 0.0.255.255 192.168.50.0 0.255.255.255
1010 deny 10.100.0.0 0.0.255.255 192.168.60.0 0.255.255.255
1015 deny 10.100.0.0 0.0.255.255 10.100.0.0 0.0.255.255
1020 permit any any
UPDATE #3
When applying suggested ACL below - it prevents access between devices on the same VLAN. The ACL is L3:
ip access-list Block_Customers
1000 deny ip any 10.100.0.0 0.0.255.255
1020 permit any any
!
However, then, two devices on this VLAN, with IPs that can speak to each other i.e. 10.100.1.0/24, can no longer ping one another. If I remove the ACL, they once again can ping each other.
This is wrong right, my traffic on one VLAN is L2, why is this L3 ACL applying?
UPDATE #4
If I apply the ACL as suggested and...
Two devices on the same VLAN on different switches, they cannot ping in each other (without the ACL they can ping so the trunks must be working). They can ping the Internet.
Two devices on the same VLAN, on the same switch, they can ping each other, but can no longer ping the SVI IP Address on the core switch on that VLAN. They can however ping the Internet, so traffic can reach that IP.
10.100.0.0/16
, and permit everything else. That would prevent communication from any customer to any other customer. That one ACL could be used on all the customer networks. Granted, the question is on topic here, but it may be better suited to Network Engineering, depending on the switch model.