This article by Lipika Pal, the author of the book VMware vCloud Director Essentials, teaches you to configure organization network services. Edge devices can be used as DNS relay hosts owing to the release of vCloud Networking and Security suite 5.1. However, before we jump onto how to do it and why you should do it, let us discuss the DNS relay host technology itself.
(For more resources related to this topic, see here.)
If your client machines want to send their DNS queries, they contact DNS relay, which is nothing but a host. The queries are sent by the relay host to the provider's DNS server or any other entity specified using the Edge device settings.
The answer received by the Edge device is then sent back to the machines. The Edge device also stores the answer for a short period of time, so any other machine in your network searching for the same address receives the answer directly from the Edge device without having to ask internet servers again. In other words, the Edge device has this tiny memory called DNS cache that remembers the queries.
The following diagram illustrates one of the setups and its workings:
In this example, you see an external interface configured on Edge to act as a DNS relay interface.
On the client side, we configured Client1 VM such that it uses the internal IP of the Edge device (192.168.1.1) as a DNS server entry.
In this setup, Client1 requests DNS resolution (step 1) for the external host, google.com, from Edge's gateway internal IP. To resolve google.com, the Edge device will query its configured DNS servers (step 2) and return that resolution to Client1 (step 3).
Typical uses of this feature are as follows:
To configure DNS relay in a vShield Edge device, perform the following steps. Configure DNS relay when creating an Edge device or when there is an Edge device available.
This is an option for an organization gateway and not for a vApp or Org network.
Now, let's develop an Edge gateway in an organization vDC while enabling DNS relay by executing the following steps:
Let's look an alternative way to configure this, assuming you already have an Edge gateway and are trying to configure DNS Relay. Execute the following steps to configure it:
In this section, we learned to configure DNS relay. In the next section, we discuss the configuration of a DHCP service in vCloud Director.
vShield Edge devices support IP address pooling using the DHCP service. vShield Edge DHCP service listens on the vShield Edge internal interface for DHCP discovery. It uses the internal interface's IP address on vShield Edge as the default gateway address for all clients. The broadcast and subnet mask values of the internal interface are used for the container network.
However, when you translate this with vCloud, not all types of networks support DHCP. That said, the Direct Connect network does not support DHCP. So, only routed and isolated networks support the vCNS DHCP service. The following diagram illustrates a routed organization vCD network:
In the preceding diagram, the DHCP service provides an IP address from the Edge gateway to the Org networks connected to it.
The following diagram shows how vApp is connected to a routed external network and gets a DHCP service:
The following diagram shows a vApp network and a vApp connected to it, and DHCP IP address being obtained from the vShield Edge device:
The following actions are required to set up Edge DHCP:
As a prerequisite, you should know which Edge device is connected to which Org vDC network. Execute the following steps to configure DHCP pool:
In this section, we learned about the DHCP pool, its functionality, and how to configure it.
It's imperative that we first understand the basics of CloudVPN tunnels and then move on to a use case. We can then learn to configure a VPN tunnel.
A VPN tunnel is an encrypted or more precisely, encapsulated network path on a public network. This is often used to connect two different corporate sites via the Internet. In vCloud Director, you can connect two organizations through an external network, which can also be used by other organizations. The VPN tunnel prevents users in other organizations from being able to monitor or intercept communications. VPNs must be anchored at both ends by some kind of firewall or VPN device. In vCD, the VPNs are facilitated by vShield Edge devices. When two systems are connected by a VPN tunnel, they communicate like they are on the same network.
Let's have a look at the different types of VPN tunnels you can create in vCloud Director:
While only a system administrator can create an organization network, organization administrators have the ability to connect organization networks using VPN tunnels. If the VPN tunnel connects two different organizations, then the organization administrator from each organization must enable the connection. A VPN cannot be established between two different organizations without the authorization of either both organization administrators or the system administrator. It is possible to connect VPN tunnels between two different organizations in two different instances of vCloud Director.
The following is a diagram of a VPN connection between two different organization networks in a single organization:
The following diagram shows a VPN tunnel between two organizations. The basic principles are exactly the same.
vCloud Director can also connect VPN tunnels to remote devices outside of vCloud. These devices must be IPSec-enabled and can be network switches, routers, firewalls, or individual computer systems. This ability to establish a VPN tunnel to a device outside of vCD can significantly increase the flexibility of vCloud communications. The following diagram illustrates a VPN tunnel to a remote network:
To configure an organization-to-organization VPN tunnel in vCloud Director, execute the following steps:
This section assumes that either the firewall service is disabled or the default rule is set to accept all on both sides.
In this section, we learned what VPN is and how to configure it within a vCloud Director environment. In the next section, we discuss static routing and various use cases and implementation.