Hello folks, after some time of laziness I am now back with a short note on Private VLANs. I figured use cases for the Private VLAN feature are widely unknown in the field and therefore PVLAN is probably one of the most underutilized features of vSphere out there. Avoiding redundancy on the internet I don’t want to explain PVLAN here, so please read
- http://blogs.vmware.com/kb/2012/08/private-vlan-pvlan-on-vnetwork-distributed-switch-concept-overview.html or
in case you are not familiar with the concept, yet.
Use Case 1: Saving VLAN IDs
This is probably the only use case people are usually familiar with. Here is the situation: A hosting provider is concerned with providing network connectivity to multiple customers / tenants. For security reasons maybe, customers are to be isolated on layer 2: VLANs. With a possible values ranging from 0 through 4095 for VLAN IDs, we can create up to 4096 VLANs. Some VLAN IDs will be used by the provider himself (storage, vMotion, FT, Management, etc etc). Though, I see more and more switches supporting 4096 VLANs, many of them are still restricted to a much lower number – 256 for example. You get the point? Only a fraction of possible VLAN IDs can actually be used restricting the number of customers / tenants a hosting provider can support. Further, using VLANs you will end up defining hundreds of subnets and reconfiguring your routers to support newly created networks.
With PVLAN, a provider can now try to put as many VMs into the Isolated secondary PVLAN only using a single VLAN ID but still separating hundreds of VMs from each other. In case a customer requires multiple VMs to talk to each other that traffic could go over a router in a Promiscuous secondary PVLAN or a Community could be created to relieve load from that router. But that would require a precious VLAN ID.
Use Case 2: DMZ
Yeah, you are reading this right! PVLANs can be used in a DMZ environment perfectly well! Think about it:
- In a Primary PVLAN the same IP subnet is to be used.
- PVLANs allow to further control traffic flow on layer 2 without the requirement for routers or firewalls.
Doesn’t that sound like something you want in a DMZ?
In a DMZ environment, we usually have two firewalls: an outer one protecting the DMZ from the internet and an inner one protecting the organization network from the DMZ and the internet.
The outer firewall protects VMs by filtering traffic to applications not supposed to be reachable from the internet. Still, DMZ systems can be intruded. In this case, when an attacker has gained control over a certain system in the DMZ, he or she gets unfiltered access to all other systems in the same DMZ. No firewall will stop him or her from accessing systems on certain ports.
PVLANs can help to restrict that access! Put your DMZ routers/firewalls in the Promiscuous secondary PVLAN and create Communities for multi-tiered applications. This way, intruding a VM the attacker will be contained in the Community secondary PVLAN unable to send ANY traffic to systems not part of that application.
This dramatically restrains the attacker in the number of possible targets for further attacks!
Use Case 3: Backup Network
From time to time, I see environments that use the old-school way of making backups of systems: agents in VMs, a dedicated backup network, every VM equipped with a second NIC attached to that backup network and a central backup server. What happens here is that people wrap their heads around security for production VLANs – maybe multiple of them – but then put all VMs together in a backup network that allows every VM to talk to every other VM in the company. That creates a big big broadcast domain and gives viruses and other stuff a red carpet for spreading over to other systems.
Now here is my suggestion: On that backup network create a PVLAN. Configure the backup server(s) to be in the Promiscuous secondary PVLAN and put all VMs into Isolated. This way every backup agent will be able to connect to the backup server but no VM will be able to talk to another VM!
Use Case 4: Desktop Virtualization
In a VDI environment a valid concern regarding security is the ability of desktops to communicate directly with each others. Like this, users can exchange data without using enterprise storage or even viruses could spread easily. With PVLAN just put desktop VMs into an “Isolated” PVLAN and place central storage in “Promiscuous” PVLAN. Done 🙂
Hope that inspires you a bit and I will see PVLANs more often in the future.