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:

All webinars are included with the yearly subscription.

11 comments:

  1. What about the Juniper vGW.
    Shouldn't that be conclusion #4...?
  2. vGW is functionally (broadly) equivalent to vShield App, only faster because it does all the filtering in the kernel module. See my other vGW posts for details.
  3. The vShield family was recently (Oct 15) announced End of Availability. VMware says vShield Edge, App and Data Security capabilities have been integrated and enhanced in vCloud Networking and Security 5.1. The whole announcement is here: http://www.vmware.com/products/vshield/overview.html
    Replies
    1. Yeah, and then you start reading 5.1 manuals and it's still vShield Edge, vShield App etc ;)
  4. I have a feeling VCD (or Cisco alternative CIAC) will eventually make vxlan, with random IDs, an absolute requirement in the next year or two. VM techs are already complaining about having to get pre-assigned Vlans, pre-configured Vlans, and even pre-assigned addressing. The automation is making management drool so much that I do not think the network group can keep fighting it.

    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.
  5. Ivan, like the thought process. Also thinking before those conclusions, some questions around automation and orchestration, which hypervisor and vswitch technology were being used, and number of DCs would have been great to know too.

    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
    Replies
    1. VXLAN is _NOT_ an inter-DC solution. It's way worse than OTV ... and you won't have to wait long, the webinar starts in an hour ;)
    2. Clearly, I don't like that response. Many people use that as a blanket response. I know you're not one of them, but for DC migrations and such it could make sense. Not saying completely A/A DCs with traffic trombones, etc.

      A controller would be ideal to manage the VXLAN gateways and even manage the overlays for that matter. Okay...hear more soon.

      -Jason
    3. I did NOT comment on viability of inter-DC subnets (but you probably know my opinion), I just said that VXLAN is _NOT_ a viable inter-DC solution.

      VXLAN as specified in current drafts (and as implemented today) has no control plane, thus no controllers. Sad but true.
  6. Yep. I think I know where you stand on that.

    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. ;)
  7. Hi Ivan I enjoy all your posts. Don't you think we're headed back to proxy firewalls with integrated VM features? Wouldn't it address this problem ?

    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
Add comment
Sidebar