For several years now, I’ve often turned to VLAN to segment company networks on Level 2. Each time, an IP subnet is attributed to these VLANs and routed through Level 3 equipment (such as routers or a firewall).
But I have noticed that people often take this segmentation too far, slicing the network up into a plethora of subnets in the hope of ensuring enough security between all of the machines.
Private VLANs are there to mitigate excess segmentation by providing an extra layer of Level 2 security.
needs met by a private VLAN
The first need that comes to mind is using a PVLAN for guest users (in offices where employees use their PCs to connect, for example). This method is often used to provide guest WiFi access. An option that restricts communication between customers can be applied on the terminal, eliminating direct communication between them (by default, communication is broadcast on a WiFi network the same way it is on a Hub, so you need to protect against data theft).
In this example, the goal is to avoid data transfer or attacks between customers, even on “hostile” cable networks. Normally, if you want to isolate these customers, you have to use one VLAN per customer, which is unthinkable. Luckily we have private VLAN.
You could also use DMZ subnets, to avoid creating too many zones on the firewall. We often need to segment DMZ servers by using an IP network and consequently an interface on the firewall (and the more interfaces on a firewall, the more volatile the traffic matrix).
solutions offered by a private VLAN
For my first need (a “guest” customer zone) security concerns dictate that it’s best to isolate each individual customer from another. But this is precisely where, very often, security goes down the tubes, and everyone ends up on the same VLAN with unrestricted access.
Instead, use a private VLAN with a guest PVLAN in “Isolated” mode. That way you have just one VLAN for all guests, and by default they can only contact the gateway, which handles all filtering and/or authentication when accessing resources.
On to our second DMZ need. You often see DMZ servers used in proxy mode with LAN->DMZ->WAN or WAN->DMZ->LAN communication, but rarely any intra-DMZ communication. For a DMZ containing several types of services (relays for e-mail, internet, SSL portals, etc), any alteration of a DMZ server by a pirate will threaten all other services in the DMZ. That’s why you often see strict separation applied between several DMZs.
With the private VLAN in “Isolated” mode, a single DMZ can contain several servers with different services but the same level of security for each one.
In the case of a group of servers that need to communicate with each other, “Community” mode would best fit. This option makes it possible for servers to communicate within a single community and access the gateway (firewall), all while remaining isolated from servers in another community.
To sum up, instead of having x number of DMZs, each with its own IP network, you can have x number of PVLAN communities, each with a single IP network and a single interface on the firewall, for an equivalent level of security.
Private VLANs, though known to many experts, are too often set aside even though they can simplify network architecture (for example, when isolating servers in a DMZ) or provide extra security that’s easy to set up (for example, for guest networks).
Now that you know more about private VLANs, you just have to wait for the right opportunity and remember to use them! ;-)
photo credit: © David Mathieu et © Konstantin Li - Fotolia.com
This blog post was originally published in French here.
I work at Econocom, where I’m currently a security architect for Cloud France solutions and its transversal services for Orange Business. I’m still new to the blog. My background is in networks and I’ve specialized in security since 2008. A huge technology buff with experience as a security integrator, I’m excited to contribute to the blog.
Edit from the Orange Business team: Guillaume left the Orange Group since he wrote his lasts posts.