Cisco Nexus 9000 Series Fabric Switches ACI Mode Multi-Pod and Multi-Site TCP Denial of Service Vulnerability

A vulnerability in the Multi-Pod or Multi-Site network configurations for Cisco Nexus 9000 Series Fabric Switches in Application Centric Infrastructure (ACI) mode could allow an unauthenticated, remote attacker to unexpectedly restart the device, resulting in a denial of service (DoS) condition.

This vulnerability exists because TCP traffic sent to a specific port on an affected device is not properly sanitized. An attacker could exploit this vulnerability by sending crafted TCP data to a specific port that is listening on a public-facing IP address for the Multi-Pod or Multi-Site configuration. A successful exploit could allow the attacker to cause the device to restart unexpectedly, resulting in a DoS condition. 

Cisco has released software updates that address this vulnerability. There are no workarounds that address this vulnerability.

This advisory is available at the following link:
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-n9kaci-tcp-dos-YXukt6gM

This advisory is part of the August 2021 Cisco FXOS and NX-OS Software Security Advisory Bundled Publication. For a complete list of the advisories and links to them, see Cisco Event Response: August 2021 Cisco FXOS and NX-OS Software Security Advisory Bundled Publication.

Security Impact Rating: High

CVE: CVE-2021-1586

Related:

  • No Related Posts

How to Accommodate “Hairpinning” Behaviour in NetScaler

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.

User-added image

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:

Source IP

Destination IP

1

2.2.2.2

1.1.1.1

2

2.2.2.2

192.168.1.2

3

192.168.1.2

2.2.2.2

4

1.1.1.1

2.2.2.2

The above mentioned flow is represented in the following diagram:

User-added image

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.

Source IP

Destination IP

1

198.168.1.3

1.1.1.1

2

192.168.1.3

192.168.1.2

3

192.168.1.2

192.168.1.3

The above mentioned flow is shown in the following diagram:

User-added image

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.

Related:

  • No Related Posts

How to Accommodate “Hairpinning” Behaviour in NetScaler

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.

User-added image

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:

Source IP

Destination IP

1

2.2.2.2

1.1.1.1

2

2.2.2.2

192.168.1.2

3

192.168.1.2

2.2.2.2

4

1.1.1.1

2.2.2.2

The above mentioned flow is represented in the following diagram:

User-added image

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.

Source IP

Destination IP

1

198.168.1.3

1.1.1.1

2

192.168.1.3

192.168.1.2

3

192.168.1.2

192.168.1.3

The above mentioned flow is shown in the following diagram:

User-added image

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.

Related:

  • No Related Posts

How to Accommodate “Hairpinning” Behaviour in NetScaler

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.

User-added image

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:

Source IP

Destination IP

1

2.2.2.2

1.1.1.1

2

2.2.2.2

192.168.1.2

3

192.168.1.2

2.2.2.2

4

1.1.1.1

2.2.2.2

The above mentioned flow is represented in the following diagram:

User-added image

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.

Source IP

Destination IP

1

198.168.1.3

1.1.1.1

2

192.168.1.3

192.168.1.2

3

192.168.1.2

192.168.1.3

The above mentioned flow is shown in the following diagram:

User-added image

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.

Related:

  • No Related Posts

How to Accommodate “Hairpinning” Behaviour in NetScaler

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.

User-added image

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:

Source IP

Destination IP

1

2.2.2.2

1.1.1.1

2

2.2.2.2

192.168.1.2

3

192.168.1.2

2.2.2.2

4

1.1.1.1

2.2.2.2

The above mentioned flow is represented in the following diagram:

User-added image

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.

Source IP

Destination IP

1

198.168.1.3

1.1.1.1

2

192.168.1.3

192.168.1.2

3

192.168.1.2

192.168.1.3

The above mentioned flow is shown in the following diagram:

User-added image

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.

Related:

  • No Related Posts

How to Accommodate “Hairpinning” Behaviour in NetScaler

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.

User-added image

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:

Source IP

Destination IP

1

2.2.2.2

1.1.1.1

2

2.2.2.2

192.168.1.2

3

192.168.1.2

2.2.2.2

4

1.1.1.1

2.2.2.2

The above mentioned flow is represented in the following diagram:

User-added image

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.

Source IP

Destination IP

1

198.168.1.3

1.1.1.1

2

192.168.1.3

192.168.1.2

3

192.168.1.2

192.168.1.3

The above mentioned flow is shown in the following diagram:

User-added image

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.

Related:

  • No Related Posts

How to Accommodate “Hairpinning” Behaviour in NetScaler

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.

User-added image

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:

Source IP

Destination IP

1

2.2.2.2

1.1.1.1

2

2.2.2.2

192.168.1.2

3

192.168.1.2

2.2.2.2

4

1.1.1.1

2.2.2.2

The above mentioned flow is represented in the following diagram:

User-added image

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.

Source IP

Destination IP

1

198.168.1.3

1.1.1.1

2

192.168.1.3

192.168.1.2

3

192.168.1.2

192.168.1.3

The above mentioned flow is shown in the following diagram:

User-added image

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.

Related:

  • No Related Posts

How to Accommodate “Hairpinning” Behaviour in NetScaler

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.

User-added image

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:

Source IP

Destination IP

1

2.2.2.2

1.1.1.1

2

2.2.2.2

192.168.1.2

3

192.168.1.2

2.2.2.2

4

1.1.1.1

2.2.2.2

The above mentioned flow is represented in the following diagram:

User-added image

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.

Source IP

Destination IP

1

198.168.1.3

1.1.1.1

2

192.168.1.3

192.168.1.2

3

192.168.1.2

192.168.1.3

The above mentioned flow is shown in the following diagram:

User-added image

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.

Related:

  • No Related Posts

How to Accommodate “Hairpinning” Behaviour in NetScaler

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.

User-added image

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:

Source IP

Destination IP

1

2.2.2.2

1.1.1.1

2

2.2.2.2

192.168.1.2

3

192.168.1.2

2.2.2.2

4

1.1.1.1

2.2.2.2

The above mentioned flow is represented in the following diagram:

User-added image

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.

Source IP

Destination IP

1

198.168.1.3

1.1.1.1

2

192.168.1.3

192.168.1.2

3

192.168.1.2

192.168.1.3

The above mentioned flow is shown in the following diagram:

User-added image

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.

Related:

  • No Related Posts

How to Accommodate “Hairpinning” Behaviour in NetScaler

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.

User-added image

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:

Source IP

Destination IP

1

2.2.2.2

1.1.1.1

2

2.2.2.2

192.168.1.2

3

192.168.1.2

2.2.2.2

4

1.1.1.1

2.2.2.2

The above mentioned flow is represented in the following diagram:

User-added image

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.

Source IP

Destination IP

1

198.168.1.3

1.1.1.1

2

192.168.1.3

192.168.1.2

3

192.168.1.2

192.168.1.3

The above mentioned flow is shown in the following diagram:

User-added image

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.

Related:

  • No Related Posts