How to connect virtual environments to DMZ network architecture

Connecting virtualized environments to DMZ network architecture creates new challenges. Network managers must learn new design methodologies to protect virtual traffic in the DMZ.

In a physical environment, DMZ networks provide a buffer between the internal network and the Internet, securing

servers that connect to both. Yet new security challenges arise when connecting virtual environments to DMZ network architecture, requiring network managers to try new design methodologies.

How DMZ networks work for physical environments

DMZ networks acting as a buffer between your internal network and the Internet are protected by firewalls that block network traffic based on IP addresses and TCP/IP port numbers.

In a physical environment, servers are connected to an isolated network switch that is protected by a physical firewall that has interfaces to the DMZ switch, the internal network and the external network. The server itself only has direct network connectivity in the DMZ, and its network connections to the internal and external networks are protected by the firewall. If the server were compromised, an attacker would only have access to the DMZ network and would not be able to access the internal network without getting through the firewall.

Any server that exists in the DMZ should only be connected to the DMZ switch and should never have physical connections to both the DMZ network and the internal network. If a server is connected to both networks it essentially acts as a bridge, and when compromised, offers attackers a direct route to the internal network without going through the firewall. However, segregating your internal network, the DMZ network and the external Internet works well.

Problems connecting virtual machines to the DMZ network

With virtualization, the traditional methodologies of isolating physical servers onto a DMZ network don’t work well for several reasons:

  • Virtualization is all about consolidating many virtual server instances onto a single physical server. As a result, a host becomes a melting pot of many VMs that have different functions and requirements. A typical host connects to multiple physical networks to handle the VLAN requirements of the VMs. It is common to use 802.1Q VLAN tagging so fewer NICs are needed to support many VLANs on a single physical NIC. Having to dedicate hosts to a DMZ environment can wreck the economics of virtualization where consolidation ratios are typically high to maximize resource usage.
  • The physical network is extended into a virtual host that has its own network of virtual NICs and switches that are managed separately from the physical network. Physical firewalls don’t extend into the virtual network, and traffic that never leaves the host is unprotected.
  • Every host also has a management console running on it—or a virtual machine that controls all the VMs running on the host. If the management console is compromised, so are all the VMs on the host, so it should never be connected to a DMZ network.

As a result, when connecting your virtual environment to a DMZ network architecture, you need design methodologies to adapt to the virtualization architecture.

Methods for connecting VMs to DMZ network architecture

There are several options available for connecting hosts and VMs to a DMZ network architecture, and all of them have one thing in common: The management console of the host is connected to an internal network. This seems to defy the basic principle that a physical server should never be connected to both public and private networks, as it can act as an open bridge between them. While you wouldn’t want to do this with a server running a traditional operating system, it is OK to do this with a bare metal (Type 1) hypervisor like vSphere.

A Type 1 hypervisor is designed to isolate and compartmentalize virtual machines and vSwitches. If a VM is compromised and people have full access to the OS of the VM, while they can exploit the VM at the OS layer, they cannot access or exploit the hypervisor to gain access to other VMs or host networks. This is a proven design and VMware has never had a reported incident with ESX and ESXi hypervisors being compromised this way.

However, that management console should be located on an internal network, but not on the DMZ, where it can provide access to every VM running on a host, making it a rich, fat target.

Using vSwitches to manage VMs on the DMZ network

The rest of the network architecture of a host that is connected to a DMZ can be done several different ways. A virtual switch (vSwitch) can support multiple physical NICs as well as multiple VLANs when tagging is used. A host can have multiple vSwitches, but physical NICs must be dedicated to a vSwitch and cannot be shared among them. It is common to have multiple vSwitches that are dedicated to certain host functions or groups of VMs. In addition, vSwitches typically have multiple physical NICs for failover and load balancing. 

When creating a DMZ network architecture on a host, there is one golden rule to follow: Dedicate a vSwitch to the DMZ and do not share it with any internal VLANs. Doing this isolates DMZ traffic to its own physical NIC so it is not shared with any traffic from VMs on private networks. A vSwitch is essentially a software Layer 2 switch that exists in the RAM of a host that has physical NICs (uplinks) that are connected to the virtual NICs that are assigned to VMs. Each vSwitch is isolated from each other and there are no backend interconnects that connect vSwitches to each other. If a VM on one vSwitch needs to connect to a VM on another vSwitch on the same host, it needs to traverse the physical network so traditional physical network security can be used to protect and isolate traffic between vSwitches. By dedicating a vSwitch to a DMZ, you can use a traditional physical firewall to protect it and it keeps it isolated from other vSwitches on a host that may be connected to internal networks.

How VLAN tagging can support multiple VLANs in the DMZ network

You can further segregate your DMZ network by using VLAN tagging inside the vSwitch to support multiple VLANs in the DMZ. However, it might be desirable to physically isolate virtual machines, in which case you could create multiple vSwitches that each have its own physical NIC that are connected to the DMZ network.  This allows each vSwitch to be protected by a physical firewall; it also forces intra-VM traffic to go through a physical firewall.

So, you’ve dedicated one or more vSwitches on a host to a DMZ network—do you dedicate the whole host as well to DMZ-only VMs? You can if you want to provide better security and separation with your VMs that connect to internal networks, but it is not uncommon to have both vSwitches connected to internal networks, and vSwitches connected to external networks on the same host. As we covered earlier, this is OK because the hypervisor keeps the traffic from each vSwitch separated from other vSwitches. Below is a diagram of a typical network configuration for a host that is connected to a DMZ network that has separate vSwitches for DMZ network VM traffic, internal network VM traffic and management console traffic:

This design allows you to maximize your host resources, as you may only have a few VMs that need to connect to a DMZ. Dedicating a whole host to them would be a waste of resources. Each vSwitch has its own physical NIC that connects to separate physical switches that are protected from other networks by physical firewalls.

Connecting to the Internet always carries some risk, but it is possible to connect a host to a DMZ network if you make smart design decisions. A secure DMZ network architecture should combine proper design and security controls at both the virtual and physical levels. By doing this you can safely extend the advantages that virtualization provides to your DMZ environment.

Read four best practices for connecting virtual environments to the DMZ.

This was first published in June 2011

Dig deeper on Data Center Network Infrastructure



Enjoy the benefits of Pro+ membership, learn more and join.



Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to: