Some service providers choose to manage the address space within their tenant environments and allocate appropriately sized ranges of addresses to their tenants. The advantage for the service provider is that they do not have to deal will multiple customers using the same “overlapping” addresses, which greatly simplifies access from the provider’s management platforms into multiple tenant environments. However, a downside of this approach is that it is quite likely that the addresses allocated to a customer could be in use elsewhere within the customer’s wider network. To prevent this duplication of addresses creating a problem, service providers enforce a layer of NAT at the boundary of the service. In cases such as this, the customer’s Org VDC networks are addressed from the service provider’s coordinated address space, typically using “private” addresses sourced from the ranges defined in RFC1918 (see Section 7, References). So that the customer can reach these addresses, ranges of mutually agreed upon, often public Internet, addresses are assigned and translated to the internal addresses used within the tenant networks.

The address translation (NAT) can be configured and carried out on an external, provider-managed device within the data center typically dedicated to each tenant, or, it can be carried out on the Edge Services Gateway and managed through vCloud Director. When NAT is carried out on inbound connections and the destination IP address is changed from the one on the boundary network to the real IP address of the target, NAT is more specifically known as Destination NAT or “DNAT”. When NAT is carried out on the Edge Services Gateway, the external network that connects the tenant Edge Services Gateway to the Customer Edge router is allocated the subnet that contains the range of NAT addresses. The following figure illustrates this on the basic tenant topology used earlier.

 

The interfaces of Edge Services Gateway and upstream devices are allocated addresses from the subnet assigned to the external network, and the remainder are made available to be used for NAT to/from addresses assigned to VMs within the customer’s Org VDCs. This process is examined further in Section 5.4, External Network Address Sub-Allocation.

While this model simplifies the service provider’s network configuration, it can create problems for the customer, because some applications are intolerant of NAT and either will not work, or will require additional steps to overcome the issues caused by NAT. Because the ranges allocated to the Org VDC networks are hidden behind the NAT addresses, the real addresses of VMs and VIPs do not need to be exchanged with the upstream WAN devices. Because the addresses that are used for NAT are from the ranges that are allocated to the networks that directly connect the WAN devices to the Edge Services Gateway, the WAN devices will learn the NAT ranges as “Connected” networks and can then distribute those addresses to their upstream connections as needed.