Hairpin NAT / NAT Hairpinning with vShield EdgePosted: August 12, 2013
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.