Starting with vCloud 5.1.x, I’ve noticed that occasionally when I’m provisioning vApps that there are no networks available even though there should be. I believe that this is an issue with the change from org networks to org vDC networks from vCloud 1.x to 5.1. Org vDC networks are now associated with an org vDC and I think that sometimes this relationship doesn’t get picked up correctly. These steps were performed on vCloud 5.1.2.
Here is an example of no networks being available even when the org vDC that was chosen has multiple networks available
Besides trying to re-create the vApp, the only fix that I’ve found is to go back to the previous step in the vApp create wizard and toggle the Virtual Datacenter selection. I’m not sure if this will work if you only have one Virtual Datacenter.
The initial Virtual Datacenter selected was vmware-alloc-vaai. I swapped it to payg-vc5c and then back to vmware-alloc-vaai.
Now continue with the wizard and the networks are available.
With vCloud you often create routed networks where you create external IPs that are mapped to internal IPs on VMs internal to the routed network. The external IPs are created on the vShield Edge Gateway by creating a DNAT to the internal IPs. Users external to the routed network access the external IPs when trying to access VMs internal to the routed network. What IPs should users internal to the routed network use when accessing VMs that are also on the internal network? If they try to access external IPs, they will be unable to do so unless the proper DNAT/SNAT rules are in place. They can use internal IPs with no problem, but users often want to access the same IP regardless of which network they are on. Accessing an internal resource by its external NAT IP is called NAT Hairpin or NAT Hairpinning. Let’s see what rules we need in place to make this happen.
I created a simple vApp with two VMs for this example.
The external network is gold-external. The internal network is vmware-eng.
VM NAT mappings
External > Internal
VM1: 192.168.50.3 > 10.0.10.3
VM2: 192.168.50.4 > 10.0.10.4
Let’s create the two NAT rules that will allow external users to access internal VMs via their external IPs. Note that these rules are applied on the external interface (gold-external) of the vShield Edge Gateway.
With only these rules in place, external users can access internal VMs via their external IP, but internal users can’t access other internal VMs using external IPs. Note that if an internal user tries to ping an internal VM by its external IP, they will receive a response. However, the response is coming from the vShield Edge Gateway and not the actual VM that they are trying to reach. You can use a packet capture program such as tcpdump on Linux and Wireshark on Windows to see this.
To create the Hairpin NAT functionality we will need to duplicate the above NAT rules on the internal interface (vmware-eng) as well as create SNAT rules for each VM.
Or depending on your needs, you can create a single SNAT rule that includes the entire external IP range.
If the VMs on the internal network need to reach the external network without a related connection, you can add the final NAT rule below.
This last rule will NAT all internal VM traffic to the external IP of 192.168.50.2. If each internal VM needs to have its own external NATed IP, you will need to create those rules individually.
With the rules above, both external and internal users can access internal VMs via the VMs’ external IPs. If anyone knows another way to make this happen, please let me know.