In a previous post I explained how to deploy a routed network in an automated way using VMware Cloud Assembly and NSX-T. In this article I will explain another network construct that is included in Cloud Assembly: a NAT network.
VMware Cloud Assembly is part of VMware’s next generation automation & orchestration platform vRealize Automation 8. vRealize Automation 8 comes in two flavours: an on-premises installation and a SaaS option called vRealize Automation Cloud. In this post I’m using vRealize Automation Cloud (fka Cloud Automation Services).
If you’re new to networking concepts in Cloud Assembly using NSX-T, I recommend you first read the Basic Networking Architecture, Basic Setup of Cloud Assembly and Setup Networking paragraphs in this article.
NAT network architecture & configuration
The NAT network architecture that we’re going to use is detailed in the following diagram:
At first sight the architecture looks the same as the routed network architecture, with one major difference: the 192.168.99.0 is NATed and the network segment will not be advertised by the TIER0-01 router to the edge router. VMs connected to the 192.168.99.0 network are not reachable from the outside, however a connection from 192.168.99.0 to the other networks (including the internet) is possible because a source NAT (SNAT) rule is configured automatically. This SNAT rule is using an IP address on the 172.16.210.0/24 network, and draws an IP address from a pool of IP addresses. An extra IP address is configured on the same interface where the 172.16.210.2 address lives.
I’ve configured a separate network profile in Cloud Assembly that is used to deploy a NAT network:
This profile looks very similar as the profile for a routed network. Again we configure the CIDR for the “general” network, the subnet size is used for the smaller network that are deployed as part of each deployment. Notice that a different subnet is used for each NAT network that is deployed. This is different when compared to vRA 7; with vRA 7 the same subnet for the NAT network was used over and over again.
The profile will have a capability tag “network:nat” added to the profile, so we can refer to it in a blueprint.
The NAT blueprint looks very similar to the routed network blueprint, with one major difference: the networkType is “outbound” – this is the Cloud Assembly name for a NAT network.
Deploying the blueprint
So let’s have a look at what happens when you deploy this blueprint. Of course the deployment history will be filled with all steps that are executed, including the allocation and deployment of network and virtual machines.
The deployment will create two virtual machines, a Tier-1 router, a network segment and SNAT rule. Let’s have a look at these components in the vCenter Server and NSX-T manager.
One of the NATed VMs is connected to the vRAC-000455 network as has a 192.168.99.x address assigned. The second VM (vRAC-000457) is also connected to this network is using 192.168.99.4. In NSX-T we will have a new Tier-1 router available what is routing the new NATed network:
An uplink port to the Tier-0 router is configured, and the vRA-000455 network segment is also connected to the new Tier-1 router:
And of course we will have a NAT ruled created 💪!
In this case the SNAT rule is using 172.16.210.15 to communicate to the outside world. This IP address is used on my 172.16.210.0/24 transit network that is linked to the Tier-0 router and Edge router.
Currently is not possible to create DNAT rules in an automated way (unless of course you’re into some custom scripting using vRO for example), of course you can create DNAT rules yourself in the NSX-T manager:
This will create a NAT forwarding rule to access one of VMs through SSH. In this case I’m (re)using the 172.16.210.15, it’s also possible to configure a different IP address for the NAT rule.
This completes the configuration of a NAT network in Cloud Assembly, I hope you will this article useful. You can alway leave your comments below.