How does client IP preservation on an AWS Network Load Balancer change what a registered target sees as the source address, and what two things does turning it on commonly break?

## What preservation actually does A layer-7 proxy terminates the client's connection and opens a new one to the target, so the target always sees the proxy's address and learns the client's address from a header. A Network Load Balancer works differently: when client IP preservation is enabled it rewrites only the destination, leaving the source address untouched. The target's own TCP stack reports the real client IP. Nothing needs to parse a header, which is why NLB is attractive for protocols that have no header to put an address into. The behaviour is a target group attribute, `preserve_client_ip.enabled`, and the default depends on the target type: - `instance` targets: enabled by default. - `ip` targets with TCP or TLS: disabled by default, so the target sees the NLB node's address in the subnet. - UDP and TCP_UDP traffic: preservation applies and is not something you turn off. The important interview point is not memorising the matrix but knowing that **the default is not uniform**, so "what does my target see?" is a question you answer by looking at the target group, not by assuming. ```bash aws elbv2 modify-target-group-attributes \ --target-group-arn arn:aws:elasticloadbalancing:eu-west-1:111122223333:targetgroup/app/abc \ --attributes Key=preserve_client_ip.enabled,Value=false ``` ## Breakage one: security groups written for a load balancer This is the classic incident. A team moves a service from an ALB to an NLB and keeps the target's security group rule, which allows the load balancer's security group or the load balancer subnets' CIDRs. With preservation on, forwarded packets arrive carrying the *client's* address, which matches none of those rules, and every real request is dropped. What makes it genuinely confusing is that the target still shows as healthy. Health-check probes originate from the NLB node addresses inside your subnets, so a rule allowing the load balancer subnets keeps health checks passing while all customer traffic is silently discarded. "Healthy target, zero successful requests" is the signature of this bug. The fix is to write the target's inbound rules for the actual client population: the internet for a public service, a peered CIDR for an internal one, or a specific partner range. Since NLBs can also carry their own security groups (for load balancers created with them), the modern pattern is to put the coarse controls on the NLB's security group and keep the target's rules aligned with whatever the target really sees. ## Breakage two: the hairpin If an instance inside the VPC connects to the NLB and that same instance is a registered target, the flow can be balanced back to itself. With preservation on, the packet arrives at the instance with a source address equal to its own address and a destination equal to its own address. The stack does not treat that as a valid inbound connection, and the client sees a hang rather than a clean refusal. The same class of problem appears when a target reaches a service through the NLB it is registered behind. The robust fixes are architectural rather than clever: don't route intra-VPC calls through the public path, split the caller and the target into separate target groups or separate load balancers, or disable preservation on that target group. ## When you disable it, how do you keep the client address? Turn on the target group attribute `proxy_protocol_v2.enabled`. The NLB then prefixes each connection with a Proxy Protocol v2 header carrying the original source and destination. The target application must understand it — nginx, HAProxy and many language runtimes do — and this is the catch: a server that does not expect the header will read those binary bytes as if they were the first bytes of the protocol and fail immediately. Proxy Protocol is all-or-nothing per target group, so enabling it and the listening software must be changed together. ## How to answer it in an interview State the mechanism first ("NLB does not rewrite the source; the target sees the client"), then the consequence ("so security groups must be written for clients, not for the load balancer"), then the two failure signatures — healthy-but-unreachable targets and hairpinned same-instance flows — and finish with the two ways to convey the client address when you cannot preserve it: Proxy Protocol v2 at layer 4, or a layer-7 proxy that adds a forwarding header.