• I have an internal of a network-load-balancer (NLB) (resolving to private ips)
  • An NLB listener on port 80 points to a target group. An instance in the target group is the only one.

When I am on the instance and curl the DNS of NLB I get no response.
I expect the NLB to redirect to but it doesnt happen.
The NLB DNS only doesnt redirect, when I am on the - the redirection works from other instances in the same subnet


  • The security group around the EC2 is world open, inbound and outbound
  • When I curl the NLB DNS from another instance in the same subnet with the same security group and other settings - NLB resolves correctly to
  • When I curl the NLB DNS from the instance, to which NLB should resolve - NLB DOESNT resolve to
  • When I curl the instance ip from the instance - I get a response
  • When I curl the instance ip from the instance - I get a response

Is there something, what prevents NLB to resolve the request of an instance, which would route back to the instance, within the NLB listeners target group?

enter image description here

1 Answers

Skip On

that is a well-know behavior that I am going to be glad to explain. Network Load Balancer introduced the source address preservation feature - the original IP addresses and source ports for the incoming connections remains unmodified. When the target answers a request, the VPC internals capture this packet and forwards it to the NLB, which will forward it to its destination.

This behavior has a side effect: when the OS kernel detects that the egress packet has as the destination address one of the local addresses, it will forward this packet directly to the application.

For example, given the following components:

  • We have an internal NLB and a backend instance. Both are deployed in the subnet
  • The NLB has the IP and a listener on port 80 that forwards the request to the port 8080.
  • The backend instance has the address and has a web server listening on port 8080. It has a security group that allows all the incoming local traffic.

  • If the instance tries to establish a communication with the NLB; the flow of the communication would be the following:

    • The instance wants to telnet the NLB: it does a request for establish a TCP connection against the NLB DNS name on the port 80.
      • As it is an outgoing communication, it starts from an ephemeral port; the instance sends a SYN packet (1):
        • Source:
        • Destination:
      • The NLB receives the packet and forwards it to the backend instance (
      • Due the address preservation feature, the backend instance receives a SYN packet with the following information:
        • Source:
        • Destination:
      • The Operation system routes the packet internally (as its destination is the own machine), and here is when the issue happen:
        • The initiating socket is expecting the SYN_ACK from (the NLB).
        • However, it receives the SYN_ACK from (the instance itself).
        • The OS will send several TCP_RETRANSMISSION until it times out.

This will not happen with a public NLB, as the instance will need to do NAT in the VPC to use its public IP address to send the request to the NLB. The kernel will not internally forward the packet.

Finally, a possible workaround is registering the backends as per their IP address, not by their Instance ID; with this method, the traffic forwarded by the NLB will contain the NLB internal IP as the source IP, disabling the "source address preservation" feature. Unfortunately, if you are launching instances with an AutoScaling Group, it will only be able to register the launched instances by its ID. In case of ECS tasks, configuring the network as "awsvpc" forces the NLB to register each target by its IP.