Although vCloud Director organizations are responsible for their own network security, the service provider should protect external networks with a firewall.

Within the vCloud Director system, VXLAN and VLAN networks enforce separation of packet traffic that is equivalent to what can be achieved using separate physical networks. They also offer a range of routing and firewalling options that give organizations fine-grained control over access to their workloads from external systems and those within the organization. These features are described in detail in the vCloud Director documentation at For the most part, a service provider who has designed effective protection for the system itself (including a Web Application Firewall, SSL-terminating load balancers, and well-signed digital certificates) need not take an active role in establishing or maintaining the security of organization VDC networks.

External Access to Tenant Workloads

When configuring access to organization workloads (vApps) from the Internet or an enterprise network, the service provider should keep in mind the firewall requirements of the vSphere infrastructure deployed and used by vCloud Director. Most likely, some vApps will either need access to the Internet or need to be accessed remotely, whether via RDP, SSH, and so on, for management, or via HTTP or other protocols for end users of those services. For that reason, two different virtual machine data networks are recommended (as seen in the architecture diagrams in Resource Allocation and Isolation) for different uses; each requires network firewall protection.

Virtual machines that need accessibility from outside the cloud (for example, from the Internet) would be either connected to a public network or a private NAT-routed network with port forwarding configured for the exposed services. The external network to which these organization VDC networks are connected would require a protecting firewall that allows in agreed-upon traffic to this DMZ network. That is, the service provider should ensure that not every port and protocol is allowed to initiate a connection to the external DMZ network. At the same time, it must ensure that enough traffic is allowed that organizations' vApps can provide the services for which they're intended. This typically includes port 80/TCP and 443/TCP, but could include additional ports and protocols. The service provider must determine how best to strike this balance, understanding that from a security standpoint, unnecessary ports and protocols should be blocked.

In general, it is recommended that vApps that need accessibility to and from the Internet be connected to a routed organization VDC network configured to allow only the required types of inbound and outbound connections. This gives the organization control over NSX firewall and port forwarding rules. Such a configuration does not eliminate the need for a network firewall to separate the external network used by these organization VDC networks; this is because public organization VDC networks do not have any vCloud Director firewall protection. The separate firewall is needed to create a DMZ (this function could be performed by a separate NSX Edge instance, however).

Similarly, a private NAT-routed organization VDC network is used for a virtual machine data network that allows virtual machines to access the Internet. As mentioned above, an NSX Edge provides the NAT and firewall capabilities for this internal virtual machine data network. Again, the external network portion of this routed network should be on the DMZ, so a separate network firewall separates the DMZ from the Internet connection itself.