Closed felipejfc closed 7 years ago
This has been tested pretty extensively. I think you might be missing some other part of the equation because the router already sets the following:
proxy_set_header X-Forwarded-For $remote_addr;
The value of $remote_address
is determined by PROXY protocol, if enabled, or otherwise by the X-Forwarded-For
header on the inbound (to the router) request.
The two biggest things I would be wary of that could be getting in your way:
You mentioned PROXY protocol being enabled on the router... have you also enabled it on the load balancer in front of the router? e.g. ELB, HAProxy, etc.?
Is router.deis.io/nginx.proxyRealIpCidrs set correctly on the router deployment? Unless this is correctly set to an IP range that includes your load balancer, neither PROXY proto headers nor the HTTP X-Forwarded-For
header would be trusted in determining the value of $remote_addr
. (This is a security mechanism. In its absence, it is too easy for anyone to spoof an IP.)
fwiw, I believe the second item above is your issue...
When you added:
proxy_set_header X-Forwarded-For $proxy_protocol_addr;
I believe what you've done is skipped the assertion of whether the source of the end-user IP was trustworthy, which is implicit in $remote_addr
, but not in $proxy_protocol_addr
.
thanks @krancour, setting
router.deis.io/nginx.proxyRealIpCidrs
worked! maybe we should document this?
regards
Without this config it is not possible to grab the client's real ip address in the requests sent to the router and whitelist feature for example is useless. I've tried turning on proxy protocol in both router deployment and service but I was only able to grab the client's real ip and use whitelist successfully setting:
in nginx