BladeSystem Virtual Connect
Showing results for 
Search instead for 
Did you mean: 

Multiple Security zones on a blade chassis

Trusted Contributor

Multiple Security zones on a blade chassis

Keith had a customer question:




I was wondering if you could help me with a security principle issue.  Currently our security policy dictates that we use separate hardware for unprotected or internet facing servers vs stuff behind the firewalls.  How secure or are there reasons to practice that principle down to the chassis level while using Virtual connect.   What special considerations are necessary to combine that traffic on the same device?




From Cullen:




In my view, this is something they can do safely but need to have a few controls in place.


Typically the primary concern is to make sure that no devices communication on both an external network and an internal one.  This prevents them from being a jumping off point for attacks, as well as preventing them from routing or bridging the networks.


Virtual Connect doesn’t route, won’t send packets from one network to another, and won’t bridge between two uplink ports, so they should be able to have some internal uplinks and other external uplinks and keep them logically separate within Virtual Connect.


The issue then is one of server profile configuration.  Someone could configure a server and connect it to both an internal and an external network.  This needs to be prevented on the front end and detected on an ongoing basis.


To prevent it:

  1. Ensure the policy is clear and well communicated.
  2. Limit the Virtual Connect access to those people who have a need and ensure they’re trained.
  3. Name networks in such a way that it’s obvious whether they’re internal or external.
  4. Institute some form of change and deployment management with review to ensure invalid connections aren’t requested.


To detect it:

  1. Perform periodic reviews of server profiles to ensure no server is connected to both an internal and an external network.


In theory, the periodic review of the server profiles could be automated (a process scans the server profiles, determines what networks each server is connected to, and checks those to make sure they’re all internal or all external – or whatever rules are appropriate) but I’m not aware of an existing tool for this.




Your comments or best practices?

Occasional Advisor

Re: Multiple Security zones on a blade chassis

This policy is old world thinking.  Seperate hardware worked when that was the only choice you had, but with virtualisation you will be needlessly doubling up on hardware, And since your firewall has multiple security zones on it, the policy is already being broken. Also a SAN will contain data from different zones so you have to break your own rules again.

My previous setup had a policy to virtualise everything. We didn't have blades there, but we had a farm of Virtual servers with external, internal and DMZ servrs on them connected to one SAN with all the data, all connected to a pair of switches with all VLANs on them (external, internal and DMZ) and a pair of firewalls managing security.

The environment was 50 servers consolidated into 10 pieces of hardware (1 Storage, 2 switches, 2 firewalls, 5 ESX servers) contained within a single rack. The hardware costs were halved, and support and mantenence was cheaper and quicker as everything could be done on a handful of boxes. Don't let 20th century thinking hold you back from the benefits of virtualisation.


Trusted Contributor

Re: Multiple Security zones on a blade chassis

Virtual Connect 3.30 was released just today and implements the feature you are asking for.

They are called Network Access Groups.

You define that a bunch of Uplink networks (VLANs) belong to the "DMZ" access group, and a bunch of other Uplink networks belong to Production.

Then when the Server Profile is first created, you must select a NAG.
After a NAG is selected, the only Networks visible for use on that server profile will be the ones associated with the NAG selected.

This prevents an admin from accidentally merging DMZ and Prod into the same Server Profile but still allows 2 adjacent blades in the same chassis to connect to different networks.
Trusted Contributor

Re: Multiple Security zones on a blade chassis

DOH! I just realized that because of the way the threads are being migrated over, "Keith" will likely never be notified of my response.