Description: add the proxy protocol support on HTTP LB in order to discover the real client's real IP. See envoy documentation here
Use case:
- On Premise deployment using a downstream LB : On Premise, a TCP LB (BIG-IP) can load-balance traffic to a pool of CE nodes and a SNAT is performed. The downstream LB shares the client's real IP to CE using proxy protocol. CE can handle Mesh or/and AppStack features.
- DNS spoofing: a customer could have bought a lot of DNS domains in order to prevent DNS spoofing. An https redirect is done by the reverse-proxy, listening on the spoofed DNS domain, to redirect traffic to the legitimate DNS domain. If we want to do that on F5 XC RE, it will consume a lot of HTTP LBs for very few traffic. One solution is to create a TCP LB on RE that forwards traffic to an HTTP LB listening on a CE interface. HTTP LB requires to know the real client's IP by using proxy protocol configured on TCP LB (see idea https://www.f5cloudideas.com/ideas/MESH-I-242)
Benefit:
- F5 XC CE App Stack can support a deployment with a downstream LB that doing SNAT
- Have a solution, with an affordable price, for customers that have a lot of DNS domains to publish on Internet with very little traffic on it
The "true client ip header" feature on http lb allows to use an IP address present in an HTTP header as the client IP address.
But today there is no configation in HTTP LB to retrieve the client IP proxyfied by a downstream TCP LB doing SNAT. Using Proxy protocol resolves this limitation, see NGINX docs here for example.