Blue Gears – NAS/iSCSI Storage within the virtual network

A common question on the VMware Communities Forums is what is the best way to attach NAS or iSCSI storage to the virtual infrastructure. In the blog Blue Gears – Virtual Networking I mentioned that there are several networks and that there exists a Storage network. The storage network is used for data transmittal from VMware ESX hosts to and from the remote storage, in this discussion NFS and iSCSI storage. Since this transmittal of data must happen as fast as possible the pNICS used for this network should not be shared. For best performance the pNICs should only transmit storage data and not data from any other network. For redundancy purposes, there should be two pNICs assigned to this network. In addition, for best security this network should be isolated from any other network. This does not mean using subnets or VLANs, but true segregation. However if you trust VLANs, go ahead and use them. It should be noted from a security perspective, that all data over a storage network is clear text. A common misconception is that all IP based storage networks require the VMware ESX service console to also participate within the storage network. This is not true. A NFS storage network does not require service console participation. iSCSI storage networks on the other hand do require service console participation for CHAP authentication only. No disk data is transmitted by the service console to the iSCSI Server just the challenge handshake authentication protocol. This happens even if CHAP is not being used within your environment. Most people often equate the need for service console participation to imply they should create a secondary service console portgroup within their environment on the same vSwitch hence pNICs of the storage network. This is not necessary and could double your network footprint and provide an alternative attack vector. The service console needs to participate within the iSCSI network, which can be accomplished using a router, gateway, or preferably a firewall between the service console and the iSCSI network. For performance and redundancy reasons, storage networks should be on their own pair of pNICs on a private vSwitch. For security reasons, the storage network should be isolated from all other networks and the service console should only participate with iSCSI through a properly configured firewall. Lastly, no VMs should be able access the same storage that ESX accesses except through properly configured firewalls or direct to their own storage products unrelated to the ones ESX can access. Virtualization expert Edward L. Haletky is the author of VMWare ESX Server in the Enterprise: Planning and Securing Virtualization Servers, Pearson Education (2008.) He recently left Hewlett-Packard, where he worked in the Virtualization, Linux, and High-Performance Technical Computing teams. Haletky owns AstroArch Consulting, Inc., providing virtualization, security, network consulting, and development. Haletky is also a champion and moderator for the VMware Communities Forums, providing answers to security and configuration questions.