No VMotion around virtual or physical firewalls, please

Chris Hoff’s BlackHat presentation titled “The Four Horsemen of the Virtualization Apocalypse” was described here by Ellen Messmer to Chris’ dislike. Her spin may have been slightly too negative, but in any case she reports interesting points, among them Chris’ comment that it just won’t work if you VMotion a virtual firewall (VFW). While Chris is right in general, moving a VFW will in fact work in some simple corner cases, basically when both locations are indistinguishable in networking terms (same subnet, same VLANs, no NAT on the VFW itself etc.). So you can VMotion a firewall, but just a little bit … if you are not so lucky all hell breaks lose.

What’s more worrying is that all the same problems will happen if you VMotion any VM in presence of any firewall (virtual or physical): either you VMotion between two locations that are identical in terms of routing, VLANs etc. or you are in trouble. Any relative motion between firewall and VM will create the same troubles.

The really revealing bit about Chris’ comment is that most VMware deployments are still so simple that all VMotion happens in the simple corner cases. So don’t get too close to your firewall when you do VMotion.

ps. I have, of course, my own agenda here.

Virtual machines and the virtual DMZ

An article by Edward Haletky made me think about ESX and the DMZ in general. The schematic picture is simple: services that need to be accessible from the Internet are in the DMZ (the demilitarized zone between the internal enterprise network and the Internet, in case you wonder), all others are in the internal network. In between, we place a 3-port firewall, one port for the Internet, one for the DMZ, and one for the internal network.

In reality, it’s of course, never that simple. Let’s ignore all the complexities of real life physical networks for a moment and think about virtualization in the most simplistic case imaginable. We run public web servers, mail servers, databases, and application servers insides VMs on ESX servers. Obviously public web servers and mail must be in the DMZ, databases must not. So what do we do? One option I have seen is separate ESX servers. Not pretty, because you tie down VMs to a small set of hosts in the DMZ. And for the services console, we have set up a separate network anyway, because we do not want it in the DMZ. The second option is dedicated DMZ NICs. Somewhat better than option 1, it means that certain network interface cards are connected to the DMZ; we can share VM hosts between DMZ and internal guests and do the separation on the virtual network (on vSwitches or VLANs in the case of VMware ESX). Still fairly inflexible.

The case for the virtual alternative to option 1 and 2 is pretty straightforward. Going virtual means to combine vSwitches, VLANs and virtual firewalls to establish a virtual DMZ (VDMZ). Putting a VM in a VDMZ is a clear and simple concept; it means to put the VM on a VLAN that is connected to the DMZ and to shield it with a virtual firewall inside the ESX server.

Dedicating physical NICs for the DMZ is wasteful, both in terms of the cost of the NICs and the lost flexibility. Either I have to dedicate two NICs (assuming that I need redundancy) for the DMZ on every single server, or I have to limit the servers that can host DMZ VMs – which is awfully close to option 1.

Talking to many VMware users, there are still some concerns to overcome. Virtual DMZs are sometimes perceived to be less secure. I cannot share the sentiment having seen too many misconfigured physical firewalls and too many untraceable wires connecting segments that should not be connected, but in the end, the practices from physical networks will carry over. As mentioned in the beginning, real life physical networks consist of multiple DMZs, mostly separated by VLANs. So it’s certain that the much more virtualization minded VMware crowd will go for virtual DMZs, too.