Use Case

Consider a case wherein ‘Client A’ is trying to reach another server ‘Server S’ using the web server's public IP address, where in both the client and server are located behind the same CGNAT. In such a case, the packets will be discarded as the normal CGNAT translation method/mapping will not suffice. ‘Client A’ wishes that the communication with ‘Server S’ using the server’s public NAT IP should go through successfully even if they reside behind the same CGNAT.

Quick recap of CGNAT & Hairpinning

Large-scale network address translation (LSN) also known as carrier-grade NAT (CGNAT) is a technology that several telecom companies and internet service providers are implementing to deal with the exhaustion of IPV4 addresses issue and extend the lifespan of IPv4 addresses until the world slowly moves to IPv6 addresses. LSN allows single IPV4 address to be shared by multiple private network subscribers thus allowing large number of users to connect using limited IPV4 addresses.

HAIRPINNING

Let us first understand the detailed problem being addressed by hairpinning with the help of an example:

Case 1: Consider a normal NAT scenario, wherein an external client (2.2.2.2) establishes a connection to the web server with private IP 192.168.1.2 and public IP 1.1.1.1. Following will be the NAT translations:

The above mentioned flow is represented in the following diagram:

This works well and as expected

Case 2: Consider a scenario where a client on the private network sends a request to web server located on the same private network using the web server's public IP address. The following NAT translations will be done.

The above mentioned flow is shown in the following diagram:

Outcome of this translation is that the packet gets discarded.
Reason: The client (198.168.1.3) receives the response packet from unfamiliar IP 192.168.1.2 and not the IP to which it had tried establishing a connection to (1.1.1.1). Hence it consider this packet invalid and discards it. 

This is where Hairpinning feature comes to the rescue.

Hairpinning allows the packets which arrive at the NAT from a private network to be translated and looped back to the private network without needing to go through the public network. This is made possible as it enables the recognition of a packet that is addressed to a host in the same private network by using a corresponding entry in the NAT table. The address translation is then done correctly and the packet is sent back to the private network. This ensures that traffic between the two hosts in same private network works properly.

Trivia: This is called ‘hairpinning’ as the flow of the packet (loopback to private network) resembles the shape of a hairpin

Support for Hairpinning in NetScaler

NetScaler (NS) supports hairpinning (such a deployment) by default and thus enables endpoints with private IP addresses to communicate with one another smoothly via NS even when both the endpoints reside behind the same CGNAT.

Additional information: This is handled by recognizing such cases and internally applying special translation logic, where in along with the Destination IP translation, even the source IP is translated is done. The NAT work smoothly and as expected since the two endpoints now recognize each other due to this dual translation.

Instructions

No special configuration is needed as the NetScaler accommodates Hairpinning by default. It supports such kind of deployments and automatically handles the packet routing.
Note: Hairpinning cannot be disabled in NetScaler.

Refer to "NetScaler: How Do I?" page for more easy to implement articles on commonly used features of NetScaler.