Comments on: The vSwitch ILLUSION and DMZ virtualization

By: Virtual Firewall Appliances – Trust Misplaced?

Virtual Firewall Appliances – Trust Misplaced? — Wed, 25 Jan 2012 23:31:20 +0000

[...] This is done to minimize the resource impact to the host server. Brad Hedlund of Dell has done some excellent work in validating this functionality. So beyond the potential software bridge in the hypervisor, we [...]

By: Michel

Michel — Sat, 15 Oct 2011 03:15:48 +0000

I found this article very instructfull for a current project I have.

Thank you all for your insights!

By: HenryG

HenryG — Fri, 12 Aug 2011 08:06:55 +0000

I probably understood 1% of this … but great and lengthy article … wow, i guess you’re passionate about this! =)

By: Mike Voss

Mike Voss — Tue, 10 May 2011 02:27:29 +0000

Great article, and I agree with your points. I had this very discussion with a customer and pushed them towards logical separation, but they insisted on having their DMZ VMs on physically separate ESXi hosts from their intranet VMs. My argument for running everything on a single physical cluster was this–they had vlans for the DMZ and intranet VMs all running on the same physical switches. So why have physical separation at the server level when you still have logical separation at the switch level? If they had been using physically separate switches, then I would have advised them to stay consistent. In the end, I suppose because server virtualization was new to them they weren’t ready to trust it like they do with traditional VLANs. Just give them time and they’ll come around…

By: Ben Stege

Ben Stege — Fri, 25 Mar 2011 11:11:57 +0000

Wow, absolutely fantastic article! Confirmed my suspicion, I always learned that different security zones on one piece of hardware wasn’t a good idea. But that was 10 years ago, times are changing and it seems that hardware isn’t king any longer, time will tell…

By: Marek

Marek — Wed, 09 Feb 2011 09:38:35 +0000

what about aproach of hypervisor bypass using PALO adapter? if we create separate vNIC for each DMZ server. can this be considered as physical network separation? The upper switch, for example nexus5k will have separate uplink port for each DMZ server.

By: Tom howarth

Tom howarth — Sun, 06 Feb 2011 16:53:02 +0000

A well written article, however there is on glaring mistake. vSphere can have more than a single vDistributed Switch per host machine, it is only the Nexus1K that has the single switch per host limitation

By: Brad Hedlund

Brad Hedlund — Wed, 26 May 2010 20:25:26 +0000

Stephane,
Under a policy of strict physical network separation, you would definitely keep Vmotion isolated inside each zone. By providing physical network separation between zones, you have by definition already provided physical separation for access to storage over IP. Whether or not the data itself is resting on the same storage system is certainly up for debate. You could link all zones into a common ESX management framework, or not, it all depends on what your security policy tolerates and who’s enforcing it.

Cheers,
Brad

By: Stephane

Stephane — Wed, 19 May 2010 13:08:18 +0000

Brad,

Great article ! Thanks !

I get confused by the way. Let’s imagine corporate security policy states there should be physical isolation between security zones. On the ESX cluster running the untrusted VMs, you would still need some virtual networking to connect to Vmotion network / ESX host management network / possible IP storage network. How can you comply to physical isolation policy in that case ?

cheers

By: John Howell

John Howell — Wed, 31 Mar 2010 22:40:12 +0000

This was the approach I have just used in desiging a DR network for a client who wanted to share a single cluster of ESX Hosts with multiple groups with different security requirements.
I got upfront the decision to allow virtual seperation for the DR network (production requires physical airgaps) as rack space and copper switchport counts were at a premium.
However you also need to take into account location physical security.
These hosts are locked in a rack with limited physical access. The management network switches for them are located in the same racks, the Guests network switches are located in a shared comms rack. Cabing to that rack is provided by inter-rack ties.
So for this config I still used 3 VSwitches – two interfaces were given to a management VSwitch, one interface to a VMotion switch, and two interfaces given to the guest switch, then using VLAN tags for the network seperation.
The next vulnerability then is attacks against guests to cause leaks between running guests. For this reason we still seperate guests facing public networks from guests on the private networks by limiting the VLANs on each host.
This way capacity can still be easily managed remotely by simply changing the guest VLANs supported on certain hosts depending on the disaster scenario we are configuring for