Over the past few days, I figured I would give vShield Zones a shot. It's a brand new feature to vSphere and touted as a "virtual firewall" inside of your VMware environment. VMware describes vShield Zones as: "Monitor and enforce network traffic within your virtual datacenter to meet corporate security policies and ensure regulatory compliance. VMware vShield Zones enables you to run your applications efficiently within a shared computing resource pool, while still maintaining trust and network segmentation of users and sensitive data."
A few reasons why people would want to use vShield Zones:
- You have Virtual Machines in your datacenter, but they can't talk to each other for any reason. For instance, you work in a large company and business units don't want their application server to have contact with anything else in the company except their people or their servers.
- You want all your VMs to talk, but not on every single port. If certain applications on multiple servers need to talk on a specific port, you can cut down on loud noise traffic by only allowing certain ports to talk.
- The DMZ. Set your VMs up with an IP address to the outside world and start blocking requests.
- From Eric Siebert's article below: "In some cases, a physical firewall can’t protect a VM. For example, if you have multiple VMs on the same vSwitch and port group on a host server, the network traffic between them never leaves the host to travel over the physical network, so a physical firewall cannot provide protection. Virtual firewalls are also complementary to physical firewalls and provide an additional layer of protection for your virtual machines."
Here is what I found out by deploying vShield Zones into my lab.
- Implementation isn't the easiest thing. I would certainly read through the WHOLE administrator guide before I deployed this into production.
- Read these articles by Eric Siebert: Why use vShield Zones? & Installing and configuring vShield Zones & Quick tips for managing vShield Zones
- There are a bunch of options for vSwitches during vShield installation that makes it confusing and the documentation doesn't help. Why do I need a management port? I thought that's what the vShield Management VM did.
- You cannot setup vShield Zones on a vDS through the auto-installer...yet. If you want vShield Zones on a vDS, read the step-by-step in the vShield Zones Administrator PDF. There is also CLI work involved. (Note: vShield Zones are compatible with the Cisco Nexus 1000v, but get ready for 10x more CLI work)
- Implementing a vShield Zone can be very intrusive to your environment. New vSwitches and port groups are created and after that's been done, you must move the VMs to either protected or unprotected networks. The vShield VM that is created is put into every port group that is specified during setup (pic below on point 5). Talk about confusing.
- Now you have to go through the trouble of configuring alike vShields on every vSwitch/Port Group so you can take care of DRS and vMotion rules. You can't install a single vShield and have it deployed on multiple ESX hosts. Each vShield can only take care of 1 ESX host. A vShield is a VM, so you have to create vShield, then vShield1, vShield2, etc because you can't have multiple VMs with the same name. The auto-install feature will create new port groups on each that are aligned with the VM name. Such as vShield-1_protected on ESX1, and vShield-2_protected on ESX2. For DRS, HA, and vMotion to work properly you have to manually go back and edit each port group so they are all identical.
- By default, vShield operation prevents vMotion from moving protected virtual machines between ESX hosts. To enable vMotion, disable the virtual intranet check on the vpxd.cfg file on your vCenter server. Read the Administrator Guide.
- DRS and HA rule settings need to be changed for your vShield VMs so they are never moved
- You cannot set firewall rules based on IP addresses. Firewall rules are done at the Datacenter Or Cluster level. *EDIT* After playing around a bit further, I found out that it is possible to create firewall rules based on any IP address or subnet. *PICTURE UPDATED*. I would like to be able to see the VM name in place of a known IP address.
The one cool thing I can say about vShield Zones are the pretty graphs on the type of traffic that is seen flowing through the vShield. This is a nice reporting feature so you can see a history of when certain types of traffic are hitting your VM. ACL rules on most Layer 3 Routers/Switchs and Firewalls will only give you the amount of hits against a rule. This is the one feature that makes vShield Zones stand out.
If you are already dealing with one of the three scenarios listed above (Server Isolation, DMZ, etc), I'm sure that you are already making it happen at a Layer 3 Router/Switch through an ACL (Access Control List) or at the Firewall to the outside world. VMware isn't exactly re-inventing the wheel here, but almost taking it back in time.
What happens when you deploy vSheild Zones into production:
- You take network security out of the Network Team and put it on the VMware/Server Team.
- Network security relies on a fairly new product that isn't a huge selling point of vSphere.
- You bring another layer of complexity into your virtual infrastructure. Virtual Distributed Switches (vDS) were a God send because of their ability to create identical Port Groups on every ESX host to overcome failed vMotion, HA, and DRS migrations. vShield Zones is only adding more gasoline to that fire by creating additional vSwitches and Port Groups that do not get identically named on deployment.
- vShield Zones will protect all your VMs sitting in the "VSprot_vShieldVM" Port Group in your Datacenter or Cluster, but they won't protect anything else in your environment. Yet, if you put ACL rules in at the Layer 3 Router/Switch or Firewall you can protect both virtual and physical devices.
- Layer 2 and Layer 3 rules only allow you to Deny/Allow 10 different kinds of ICMP traffic and "Other IPv4". Well, what's that other IPv4?
I don't see vShield Zones becoming a core part of any virtual infrastructure. The addition of complexity with limitations makes it something not very appealing to someone like me who takes care of the virtual environment, network infrastructure, and network security. vShield Zones could be beneficial to a SMB who doesn't want to fork over the money for a Cisco ASA, but I wouldn't risk my network. If you ever have a host failure or a vShield VM goes down, there is going to be a good amount of work involved playing cleanup.