How AWS Reserve Client IP Impacts Routing: A How-To Guide

Select Language:

If you’re experiencing networking issues with your Network Load Balancer (NLB), especially when trying to keep the client’s original IP address, understanding how the “Preserve Client IP” setting works can help you resolve the problem.

When you turn on “Preserve Client IP” on your NLB, it keeps the initial IP address of the client when forwarding traffic to your targets. This is useful for tracking where your traffic originates. But, here’s the catch: this feature doesn’t work if the traffic passes through transit gateways before reaching the targets.

In your setup, the traffic goes through two transit gateways—let’s call them TGW 1 and TGW 2—before reaching the NLB. When you enable preserve client IP, the NLB tries to send the original client’s IP address to your targets. However, this doesn’t align well with how transit gateways route the traffic.

Why does this cause issues? Because with preserve client IP enabled, the NLB expects to send traffic directly to the targets without passing through transit gateways. It works best when the targets are within the same Virtual Private Cloud (VPC) as the load balancer or in a peered VPC in the same region. But in your case, the traffic must pass through transit gateways, which disrupts the process.

Initially, enabling preserve client IP might seem fine. The traffic flows out, and the source IP appears correct in logs. However, the return traffic often fails because the network can’t route the client’s original IP address back through the transit gateways properly. This mismatch can prevent replies from reaching back, leading to connectivity issues. Additionally, security groups and routing tables might not be configured to support the preservation of IPs across transit gateways, further complicating things.

You might notice logs showing “NO DATA” entries. This indicates that during those times, no packets were successfully sent or received. Essentially, the network wasn’t routing traffic correctly, which aligns with the issues caused by trying to preserve client IP across transit gateways.

Before turning on preserve client IP, the NLB used Network Address Translation (NAT), replacing the source IP with the NLB’s own IP. This method allowed the traffic to pass through transit gateways without issues because the routing was based on the NLB’s address, not the original client’s. When NAT is used, the connectivity remains stable across multi-gateway and region setups.

In summary, if your architecture involves multiple transit gateways, using “Preserve Client IP” isn’t recommended because it conflicts with how transit gateway routing works. Instead, it’s better to leave this setting disabled, so your traffic can flow smoothly using NAT, ensuring reliable communication between your load balancer and targets.

For more detailed information, you can review the AWS documentation on target group attributes and how they affect load balancer behavior.