Hairpin NAT / NAT Hairpinning with vShield Edge

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.

hairpin2

hairpin1

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.

hairpin3

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.

hairpin5

Or depending on your needs, you can create a single SNAT rule that includes the entire external IP range.

hairpin6

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.

hairpin7

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.

Advertisements

4 Comments on “Hairpin NAT / NAT Hairpinning with vShield Edge”

  1. supplier baju murah tangan pertama says:

    My brother suggested I might like this website. He was totally right.
    This post actually made my day. You cann’t imagine just how much time I had
    spent for this information! Thanks!

  2. Hari Rajan says:

    Thanks buddy , it helps me a lot , but surely some question in mind . I will update it here with in couple of hours and looking forward your help on this to understand.

  3. Watch Movie says:

    Pretty! This was a really wonderful article. Thanks
    for providing this info.

  4. Tom says:

    Great article..really helped me a lot. One additional thing I figured out is that if you want to have an application connect to its own server using the public IP then you will also need to set up SNAT on the internal network too.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s