Enable load-balancer handling, and configuration options.#9
Enable load-balancer handling, and configuration options.#9gh2k wants to merge 3 commits intocloudflare:masterfrom
Conversation
|
Have tested the 'deny' options with the following results: No deny options:
DenyAllButCloudFlare
DenyAllButLoadBalancer
Both DenyAllButCloudFlare and DenyAllButLoadBalancer
|
The issue only appeared to show for requests coming via a load balancer and /not/ via CF, at which point the IP would be reported as a cloudflare IP
|
👍 to merge this, I have the same problem. |
|
Likewise - same issue here - would be great to get this |
|
If 'CloudFlareBehindLoadBalancer' is implemented, could it also take into consideration a custom X header for setting the SERVER_PORT value? For example if the LB passes an X-Port, to set SERVER_PORT to that value. We've noticed a few client applications having issues due to checks being made against the SERVER_PORT, versus the HTTPS environment variable which is set going by the CF-Visitor header. |
|
I have been using a different approach for this: we simply do not allow outside traffic to the ALB except for the CDN IP ranges using a Lambda function which updates groups with a particular tag. Since you're already implicitly trusting the load-balancer at that point there's much less benefit to using |
When running an app behind both CloudFlare and a load balancer (such as AWS ELB) the remote IP address can be misreported. This is particularly the case if you are expecting requests to come both via CloudFlare -> ELB and also directly through ELB.
Added a 'CloudFlareBehindLoadBalancer' directive that suggests that the remote IP should be processed from a load balancer before being checked for the cloudflare header.
Also added DenyAllButLoadBalancer to return 403 unless a request has come via a specified load balancer.
Out of the box, configured defaults such that enabling CloudFlareBehindLoadBalancer handles ELB requests with no further configuration required.