By Jim Hannan
Organization Networks are the bridge between vApp networks and external networks. Organization Networks are layer 2 networks; they can be configured to route external networks with a NAT appliance called vShield Edge. An Organization Network allows vApps to communicate internally with one another. An Organization Network can also connect the Organization vApps to external networks.
The three basic types of Organization Networks are:
- Direct-connection networks
- NAT-routed networks
- Internal networks
Figure 4 – Creating an Organization Network
Direct-connection Networks are networks that require direct connection with no translation (like a web server). A web server should be given an IP address on the same network as the attached external network. This allows clients to connect directly through SSH or web services.
NAT-routed networks are connected to external networks though a NAT connection. NAT-routed networks are the most common method of granting outgoing access to Internet servers from vApps in a cloud. NAT-routed networks are typically used when the vApp, or group of VMs, need access to the Internet but should not be accessible from the Internet or intranet. Another NAT option is fencing, where there are two sets of IP addresses: internal and external.
Internal networks allow the VMs or vApps to communicate internally, but do not allow external access to the Internet, external services, or networks. Internal Networks are commonly used for TEST/DEV networks. Connection to VMs is only possible through remote console connections.
Network Pools are used as templates to create networks at the Organization and vApp levels. Network Pools must be backed by a network resource:
- Cloud Network Isolation Backed (VCNI)
- Port Groups (typical for Enterprise, non-Plus customers, and Cisco Nexus)
Network Pools are required for the following Organization Networks:
- NAT-routed with external access
- Organization Internal Networks
Figure 5 – Creating Network Pool
vApp Networks can be created by the vApp Users. A vApp network is a layer 2 only network. They are the most isolated networks available in vCloud Director. Unlike External Isolated Networks, vApp Networks do not allow for connectivity between vApps. vApp Networks have one particular use: maintaining network stacks that require a specific IP address.
vApp Fenced Networks
vApp Networks can have fenced networks to allow multiple copies of the same vApp running with identical IP addresses. vCloud Director deploys a vShield Edge device (router) that connects to a organizational network. Fencing uses NAT, giving the VMs external and internal IP addresses. The fenced configuration should be deployed with, or start with a direct-connection (Org Network).
vCloud Director uses a vShield component called vShield Edge to provide network security services. The vShield Edge device is deployed at both the Org Network level and, optionally, the vApp layer in a fenced configuration. The vApp network allows for granular control of the network traffic including, but not limited to:
- Deny All (Inbound or Outbound)
- Deny Some (specify port Inbound and Outbound)
- Static Routes
- NAT Mapping
Figure 6 – vShield Edge
The vShield Edge services are capable of the following:
- NAT Mapping
- Firewall (default deny inbound)
Firewall rules can be created to allow certain traffic (ssh or RDP). Doing so requires a NAT external address and NAT mapping.
Figure 7 – Firewall blocking or allowing traffic
Figure 8 – NAT external IPs
Figure 9 – NAT Mapping (External to Internal)
As I mentioned in Part I, vCloud Director administrators will agree that networking is the most complex and configurable feature in vCloud Director. The real power and flexibility of vCloud Director is in the networking portion where the available network configurations are virtually endless.