Concerning oreeh's 3rd option in which you deploy "DMZ" VMs on the same VI3 infrastructure in which you deploy "LAN" VMs:
Each ESX server has a dedicated NIC going straight to the DMZ and thus each ESX server has a DMZ vSwitch cooresponding to that physical nic. The only difference between a DMZ VM and a LAN VM is that the DMZ VMs have NICs only bound to that DMZ vSwitch and none others. This is not akin to putting the same traditional server across both the LAN and the DMZ. That would be if you had a VM with 2 nics, one on the LAN vSwitch and one on the DMZ vSwitch. That would break anyone's security policy, and rightly so.
The risk, of course, is that there might potentially be a way to attack a VM one day in a way that attacks the ESX host running it, at which point one or more LAN computers have now been compromised from the Internet. This risk might be mitigated by 2 factors:
1) Having a DMZ ESX host communicating with a LAN VirtualCenter server and other LAN ESX hosts doesn't seem inherently any more secure than what' described above. It sounds much more complex but not really more secure. I think the only way to make it more secure is to have 2 totally disparate VI3 envionrments. The cost of totally reproducing your VI3 environment in the DMZ entails procuring multiple SAN-attached ESX servers w/ dual HBAs, a new SAN, SAN switch(es), VI3 Enter. Ed licensing, another VirtualCenter Mgmt server, etc. This likely makes virutalization in any form in the DMZ no longer make sense for all but the largest enterprises. It may be that the benefits of virtualization in the DMZ outweighs the small added security risk you assume when implementing oreeh's 3rd option. For example, the ONLY cost incurred in deployed DMZ VMs in the existing LAN VI3 environment is the cost of a few extra GBit Nics (don't forget, SANs aren't network devices so there is no such thing as "LAN SANs" and "DMZ SANs" from a security point-of-view; there are just "SANs"). Kind of a no brainer when it comes to cost.
2) It is likely that the enterprise can have enough other layers in the security onion so that ultimately this added risk is so incredibly minuate that it is seen as a much smaller risk than opening just about any hole in the firewall, which of course you have to do from time to time to conduct any business at all. For instance: database vulnerabilities hold a much higher risk, both in potential loss and in likeihood of attack (future code-red-ish attacks, SQL Injection attacks, cross-site-scripting attacks, etc) but yet we still have backend databases connected directly to our DMZ servers through tightly controlled firewall holes. We all recognize the risks of connecting web servers to database servers by opening firewall ports, yet every company does it. Likewise, we all recognize the risks of the future possibility that someone might find a zero-day exploit that connects DMZ VMs to their LAN ESX hosts.
My argument is that this risk is minimal compared to other risks security-folks put up with on a daily basis. This is because of the complexity of the attack vector, the no-frills ESX architecture, good VMWare patch mgmt, and all the other security infrastructure protecting the DMZ VMs in the first place (anti-virus clients, firewalls, good code review, patch mgmt, etc). Plus the HUGE cost savings realized by doing it oreeh's method may very well outweigh the potential damage a successful attack would likely incur in the first place.
Personally I think this is an education issue in which the security-policy-making people of the world need to better understand the truth of what is happening here within ESX Server. It is inheriently different than anything Microsoft, Sun, Apple, RedHat, etc produces. This is not a general-purpose operating system. Perhaps once the industry fully moves toward and implements ESX 3i and gets rid of that suspicious-looking Linux console, the security-policy folks finally will be left with no excuses.
Benny Hauk
Systems Admin, VCP3/VCP4
LifeWay Chrstian Resources
