VMware vCloud Networking and Security virtualizes networks and security to create efficient, agile, and extensible logical constructs that meet the performance and scale requirements of virtualized datacenters. vCloud Networking and Security Edge is part of the vCloud Networking and Security solution and provides network edge security and gateway services. Edge connects isolated (stub) networks to shared (uplink or external) networks by providing common gateway services such as DHCP, VPN, NAT, and Load Balancing. Also an Edge can be used to interconnect internal networks for isolation and routing with no uplink and or external access. Common deployments of Edge include the DMZ, VPN Extranets, and multi-tenant Cloud environments where the Edge provides perimeter security and L4 to L7 services for Virtual Datacenters (VDCs).
This blog outlines the detailed steps to deploy Network Address Translation (NAT) using an Edge. Edge provides NAT services to a computer or group of computers in a private network. NAT service configuration is separated into source NAT (SNAT) and destination NAT (DNAT) rules. SNAT is used to translate a private internal IP address into a public IP address for outbound traffic. Typical use case for SNAT is to provide Internet or corporate network access to servers in a private network. DNAT on the other hand is used to translate a public IP address into a private internal IP address. DNAT is commonly used to publish a service located in a private network on a publicly accessible IP address.
SNAT deployment using Edge
In the setup shown below, Edge is translating Lab-Network using addresses 192.168.1.0/24 to 10.20.181.171. This is a special case of SNAT called masquerading. In this type of SNAT the whole Lab-Network behind the Edge is “masquerading” as a single host with IP address 10.20.181.171. We can also use the Primary IP 10.20.181.170 as SNAT translated IP.
VMware vCenter view of Edge interfaces with the Lab-Network configuration is shown below.
Use the following steps to setup SNAT to allow Lab-Network servers (Server1, Server2, etc) to connect to hosts on the External Network.
Add an address that will be used for SNAT on the Edge interface that you want the Lab-Network servers to masquerade on. In this case we are using External-Network interface (vNIC 0) that is attached to network that is reachable externally.
Next we create the SNAT rule that will use this address as shown below and publish changes.
As the default firewall rule is denying all the data traffic between internal and external networks, add a firewall rule to allow internal servers access to services of the external network. In this example, allowing SNAT services to Lab-Network for HTTP, HTTPS, and SSH services only as shown below.
Once these firewall rules are published, Server1, Server2 and Server 3 can access the resources on the External-Network. With logging enabled and a syslog server configured for the Edge, following syslog messages are shown illustrating SNAT and firewall rules are working as configured.
Server1 (192.168.1.2) can access 10.20.182.28 using SSH Server2 (192.168.1.3) can access web server (10.20.182.30) using HTTPS (port 443)
Server 2 (192.168.1.3) cannot ping 10.20.182.30 as ICMP traffic is dropped
DNAT deployment using Edge
DNAT is commonly used to publish a service located in a private network on a publicly accessible IP address. Setup used for describing the DNAT deployment use case is shown below. In this use case, Edge is publishing the Web Server 192.168.1.2 on external network as 10.20.181.171. We can also use the Primary IP 10.20.181.170 for DNAT purpose.
VMware vCenter view of this setup with Edge interfaces is shown below. The external IP address 10.20.181.171 is already configured on the Edge External-Network interface (vNIC 0). We will use this address as our DNAT address.
Create DNAT rule as shown below to publish WebServer (192.168.1.2) externally as 10.20.181.171.
As the default firewall rule is denying all the data traffic between internal and external networks, add a firewall rule to open HTTP and HTTPS access to inside Web Server as shown below. Once these firewall rules are published, clients from External Network side can access the internal web server 192.168.1.2 using 10.20.181.171. With logging enabled and a syslog server configured for the Edge, following syslog messages are shown illustrating DNAT and firewall rules are working as configured.
Next we create the SNAT rule that will use this address as shown below and publish changes. 
As the default firewall rule is denying all the data traffic between internal and external networks, add a firewall rule to allow internal servers access to services of the external network. In this example, allowing SNAT services to Lab-Network for HTTP, HTTPS, and SSH services only as shown below.
Once these firewall rules are published, Server1, Server2 and Server 3 can access the resources on the External-Network. With logging enabled and a syslog server configured for the Edge, following syslog messages are shown illustrating SNAT and firewall rules are working as configured.
Server2 (192.168.1.3) can access web server (10.20.182.30) using HTTPS (port 443)
Server 2 (192.168.1.3) cannot ping 10.20.182.30 as ICMP traffic is dropped
Create DNAT rule as shown below to publish WebServer (192.168.1.2) externally as 10.20.181.171.
As the default firewall rule is denying all the data traffic between internal and external networks, add a firewall rule to open HTTP and HTTPS access to inside Web Server as shown below. 
Once these firewall rules are published, clients from External Network side can access the internal web server 192.168.1.2 using 10.20.181.171. With logging enabled and a syslog server configured for the Edge, following syslog messages are shown illustrating DNAT and firewall rules are working as configured.
HTTPS (port 443) traffic is accepted
SSH (port 22) traffic is dropped
