We have a VLAN for the Kernel, another for Service Console, and once the ESX server is built, there will be a separate vswitch just for them with multiple uplinks. We have a different VLAN for provisioning. Plus others for production traffic. Unfortunately, the same provisioning VLAN will be used for building new virtual machines and other physical host OSes as well, so setting the native VLAN to the provisioning VLAN is probably not going to fly.

Although I was hoping to avoid it, I’m pretty sure the only acceptable solution to our security folks will be to configure additional uplinks as access ports to use for provisioning and swap things around after the OS is deployed (although we’re using HP virtual connects, so we may do it there).

Perhaps eventually, the install kernels will jump into the 21st century and figure out a way to support VLANs.

Thanks,

The short story is that using the native vlan does open you to some additional risk. An attack does need to originate from an access port on the same vlan as the native vlan. In my case, normally I will suggest a “management” vswitch used only for ESX things like the service console, vmotion, and nfs mounts for ISOs. The only vlan’s exposed to the risk would be any vlans except the native. This pretty much comes down to the vmotion vlan. Following best practice, this should be a non-routed vlan. If I am fully understanding this, the return traffic from the vmotion network to the attacker should not make it as there would be no return route. The attack would need to consist of a single packet or packets with no return necessary.

Also, many clients I work with have dedicated vlans just for ESX service console and vmkernel interfaces. This would also help narrow down the attack sources.

You can assess your own risk vs reward. Deploying ESX without the native vlan leaves you the following options.

1. Designate a port per rack for deployment. This would be an access port on the same vlan as your service console. Plug in the deployment cable for building. Post build, add the tagging to the service console with esxcfg-vswitch.

2. Same as #1 but build with UDA.

3. Dedicate network interfaces to the service console and use access ports. With HA, it is a best practice to have to vmnic’s on this switch for heartbeat redundancy.

4. Install by hand and script the post installation configuration.

So if you use blades in a lights out datacenter. Good luck.

Also, your comment somehow was held in moderation by wordpress until I approved it. It may have been anti-spam. Anyway, that explains the delay in your comment appearing.

If you set the Native VLAN on the Cisco switch trunk port in this manner, do you expose the network to the VLAN hopping attack via double encapsulation? This is described here:

http://www.cisco.com/en/US/products/hw/switches/ps708/products_white_paper09186a008013159f.shtml

and also mentioned by Scott Lowe here:

http://blog.scottlowe.org/2008/03/05/vmotion-and-vlan-security/

Thanks,

Great write-up! The build problems you discussed when not using the native VLAN are exactly what prompted my article, as I have a number of customers that are experiencing problems with builds when they do not use the native VLAN.