Firewalls in a Small Private Cloud
Mrs. Y, the network security princess, sent me an interesting design challenge:
We’re building a private cloud and I'm pushing for keeping east/west traffic inside the cloud. What are your opinions on the pros/cons of keeping east/west traffic in the cloud vs. letting it exit for security/routing?
Short answer: it depends.
Digging Deeper
We had a nice Skype conversation discussing all sorts of interesting topics, including VXLANs, hybrid clouds, vShield Edge, introspection firewalls (what I would call NIC-level firewalls), numerous vendors … and we were not getting anywhere, until we remembered the basic rule of network design: scope the problem first.
Here’s what we found out:
- Will you have a multi-tenant cloud with individual groups (departments, app teams) deploying their own app stack? No.
- Will you keep the traditional paradigm of segments separated by firewalls? Yes.
- Will the tenants configure their own firewalls? No, security will be centralized.
- Do you need load balancers in front of the servers? Not really.
- How many servers are you going to virtualize? A few hundred.
- How many vSphere hosts will you need for that? Low tens.
- How many different security zones (segments) will you have? Low tens.
Conclusion#1: You don’t need VXLAN. VLANs will do just fine for a low number of servers and segments.
Conclusion#2: You could use VM-based firewall (ex: vShield Edge) or a physical appliance (ex: ASA) for inter-segment firewalling and routing. There’s no functional difference because individual tenants won’t manage their own firewalls ... unless you plan to use vCloud Director, in which case you might consider the fact that vShield Edge nicely integrates with vCloud Director. On the other hand, vShield Edge still hasn’t reached feature parity with traditional firewalls like ASA.
Conclusion#3: Whatever you do, you can still deploy NIC-level firewalls like vShield App or VSG … just don’t expect them to be managed by vCloud Director (because it still doesn’t talk to them).
More information
Network virtualization and virtual firewalls are well covered in my virtualization webinars:
- Introduction to Virtual Networking will give you an overview;
- Cloud Computing Networking describes numerous technologies you can use to build virtual networks, and their scalability;
- VMware Networking Deep Dive covers the technical details of vSphere’s vSwitch, Nexus 1000V and virtual firewalls (including VSG, vShield App and vGW);
- VXLAN Technical Deep Dive focuses on VXLAN-based virtual networks and VXLAN gateways.
All webinars are included with the yearly subscription.
Shouldn't that be conclusion #4...?
Now how to troubleshoot random IP addressing, random vlan IDs, and server sprawl. I really think my group should take charge of VCD and I think Vmware feels the same after their application realignment. I'm not even sure VCD can provision servers any longer with latest update.
Why dismiss VXLAN at the 100s of servers (10s of physical hosts) so soon? Could be useful for inter-DC mobility. Thoughts or should I wait for the webinar :)
-Jason
A controller would be ideal to manage the VXLAN gateways and even manage the overlays for that matter. Okay...hear more soon.
-Jason
VXLAN as specified in current drafts (and as implemented today) has no control plane, thus no controllers. Sad but true.
Okay, control plane to stay as-is if it must for now, but a controller and/or Vcenter to manipulate and auto configure VXLAN gateways would still be of value for those daring enough to extend a VXLAN between sites. Possibly just a mirror of the VXLAN gw at the other site...just thinking out loud now. ;)
Also VXLAN provides us with two functions: LAN extension and scalable network isolation. As many of us have learned the hard way, LAN extension needs to be deployed with care lest you L2 problems in one location suddenly become L2 problems in all your locations ie ... broadcast storms or some network worm outbreak. OTV solves fault isolation amongst location. In saying that broadcasting across WAN in my opinion is sloppy. Its not a preferred inter connect DC solution
Allen Baylis