Skip to content

Why does EC2 not see the NLB source IP, yet the client receives responses as if they came from the NLB? Is NLB acting like a partial DSR?

0

I’m trying to clearly understand the data path for Network Load Balancer (NLB) in AWS.

Specifically, in the traffic flow:

Client → NLB → EC2(Target)

❓ What I observe / understand so far

EC2 does not see the NLB’s IP. The EC2 instance shows the client’s original source IP, meaning NLB does not perform SNAT. (This is documented: "NLB preserves the source IP".)

That means EC2 must be sending return traffic directly to the client’s IP, not back to the NLB IP.

However, the client receives responses as if the traffic always came through the NLB — meaning the return path is somehow still tied to the NLB’s data plane.

❓ So my core question is:

If NLB does not perform SNAT and the EC2 instance sees the real client IP, how does the return traffic path get enforced to still pass through the NLB’s Hyperplane ENI? More specifically: Is the EC2 instance returning traffic directly to the internet gateway (like traditional DSR)? Or does AWS enforce that return packets always traverse the NLB’s Hyperplane node? If so, how is that enforced when the EC2 instance does not see the NLB as the source IP?

❓ What I’m trying to understand:

It looks similar to DSR, because: EC2 sees the real client IP NLB does not terminate the TCP connection EC2 appears to answer “directly” to the client But it’s not full DSR because (as docs mention) return traffic must pass through the load balancer.

So:

How does AWS ensure that EC2 → Client return traffic still goes through the Hyperplane ENI, even though EC2 does not see the NLB IP? If there is an AWS internal mechanism (connection tracking, reverse path enforcement, Hyperplane routing rules, etc.) it would be helpful to understand at a high level.

Thanks in advance!

asked 8 months ago408 views

1 Answer
1
Accepted Answer

When using AWS Network Load Balancer (NLB) with client IP preservation enabled, you're observing a behavior that resembles Direct Server Return (DSR) but with some important AWS-specific differences.

With client IP preservation enabled, the NLB preserves the original client's IP address when forwarding traffic to targets. This means your EC2 instance sees the client's original IP address rather than the NLB's private IP address. This is beneficial for applications that need to know the true source of traffic.

However, unlike traditional DSR where return traffic bypasses the load balancer completely, in AWS's implementation, the return traffic from your EC2 instance still flows through the NLB. This happens through AWS's underlying network infrastructure and the Hyperplane technology that powers NLB.

The mechanism works as follows:

  1. Client sends traffic to the NLB's public IP address
  2. NLB forwards this traffic to the target EC2 instance while preserving the client's original IP address
  3. The EC2 instance processes the request and sends response packets addressed to the client's IP
  4. AWS's network infrastructure ensures these return packets are routed through the NLB before reaching the client

This routing behavior is enforced at the AWS network level, not at the EC2 instance level. The EC2 instance doesn't need to be aware of the NLB's IP address because AWS's network infrastructure handles the routing. This is part of the "flow symmetry" that AWS maintains for NLB connections.

It's worth noting that client IP preservation has specific requirements:

  • For IPv4 clients, it works when the target is in the same VPC as the NLB or in a peered VPC
  • For IPv6 clients connecting to IPv6 targets, client IP is always preserved
  • For cross-protocol scenarios (IPv4 to IPv6 or vice versa), the source IP will always be the NLB's private IP

If client IP preservation isn't possible or enabled, the EC2 instance will see the NLB's private IP address as the source. In cases where you need the client IP but can't use client IP preservation, you can enable proxy protocol, which adds the client IP information to the TCP payload.
Sources
Scaling the dual-stack network design in AWS - IPv6 on AWS
ELB client IP address | AWS re:Post

answered 8 months ago

AWS
EXPERT

reviewed 8 months ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.