• The good thing, it’s FREE with ESX Advance/Enterprise/Enterprise Plus version.
• Yes, it’s simply a transparent firewall utilizing VMsafe API, so there is no need to change the default public IP on VMs, vShield Zone (ie, firewall) comes with limited functions comparing to real stuff like Netscreen, but it does get the job done by limiting ports, source, destination, direction on L2/L3 and L4 layer, one extra nice thing is vShield Zone comes with a bunch of dynamic ports based application such as FTP, DNS, etc.
• In version 4.1, there is no more separate OVF for vShield agent, it’s been renamed to vShield Zone, and deployment of vShield Zone is simply by clicking the Install link on the menu, it’s so much simpler to install a firewall on each ESX host with v4.1, no need to create any template for vShield Zone like in the old days as well. In additional, A new vSwitch, called vmservice-vswitch, is also created. It has no physical NICs assigned to it and has a VMkernel interface with a 169. IP address. This vSwitch should not be modified. It’s used exclusively by the Zones firewall VM, which has two vNICs connected to it. Through the vNICs , the Zones VM communicates with the LKM in the VMkernel. One vNIC is used forcontrol, and the other is for data path communication.
• The original version of vShield operated in bridged mode and sat inline between vSwitches so that all traffic to the protected zones passed through it. The new method of monitoring traffic at the vNIC, instead of the vSwitch, eliminates the vSwitch reconfiguration that previously occurred, and it provides better protection. In bridged mode, VMs in a protected zone had no protection from other VMs in the protected zone, but now that vShield Zones operates at the vNIC level, every VM is totally protected.
• So if something happens to the Zones virtual firewall VM (e.g., it’s powered off), the networking on a host will go down, because nothing can route without the virtual firewall VM. If you migrate a VM from a Zones-protected host to an unprotected one, vCenter Server automatically removes the filter, so a VM won’t lose network connectivity on its new host.
• Also in the new version of 4.1, VM Flow is gone (it was available free in is previous version), you need to upgrade to VShield App get have it back again. For my environment, I use PRTG’s packet analyzer on switch mirror ports, so such feature is not required.
• In this new version 4.1, committed firewall policy is applied in real time, there is no need to login to console and issue validate sessions anymore.
• vShield Zone firewall can apply to 3 levels, Data Center, Cluster and Port Groups (?), I usually deploy it at Cluster level due to DRS.
• If you have a cluster, then it’s highly recommended to install vShield Zone on all ESX hosts as VMs may got vMotioned between ESX hosts in the cluster and they will still be protected by vShield Zone (ie, firewall).
• Install vShield Zone process does not need to reboot the ESX host, but uninstall vShield Zone does require reboot the ESX host, after the reboot, often you will find the originally configured vShield Zone switch is not removed, so you need to remove it manually.
• It’s nice to see the extra tab in vCenter interface, but I still prefer to manage vShield using the web interface.
• You can always get more features by upgrading to other advanced vShield Products like vShield Edge as those will provide features like VPN, routing, load balancing, etc.
• Under Maintenance Mode, vShield Zone for a particular ESX host SHOULD NEVER NOT be vmotioned away although vShield Manage can. You will need to manually shut it down (by using CLI shutdown) after DRS automatically migrates all other VMs on the host and reboot the host. I am still trying to figure out how to set maintenance mode DRS recommendation for vShield VM, if you know, please do let me know, thanks.

Part of the above were quoted from Eric Siebert’s newly revised Installing VMware vShield Zones for a virtual firewall and don’t forget to review his article on “Top 10 VMware security tips for vShield users”

Update: Oct 30, 2011

I found the solution to my last question in how to avoid vShield Zone VM to be moved away during Maintenance Mode by DRS, the answer is at the end of the Install vShield Zone PDF (Page 13, can’t believe I missed this extremely important piece of information). Basically, you need to set vShield Zone VM Restart Priority to Disable under HA and Automation Level to Disabled under DRS.

To prove it’s working  I did a test, I put the host in to Maintenance Mode, DRS was able to vmotion away everything to other available nodes except the vShield Zone VM, then it shuts it down nicely, everything is done automatically.

Bravo!