When using the CF-Connecting-IP header Cloudflare sends the same RFC-1918 IP regardless of what the visitor’s true IP is. Is there a way to stop this or do I just have to remove the site from Cloudflare?
That sounds like a bug somewhere.
Are you able to reproduce?
Have you restricted incoming connections to your Origin to only allow Cloudflare IP addresses?
Is it all entries in your Origin log server?
Do you see this behaviour on HTTP 1.1, HTTP/2 and HTTP/3?
I have tested connections from a US IPv6, a US IPv4 and had clients connect from Non-US connections, all returning the same IP from Cloudflare’s header. (See connection log screenshot)
Occurring on both HTTP/2 and HTTP/3 and I am unable to test it for HTTP 1.1
The site is fully proxied by Cloudflare, so I would assume all incoming restrictions to the site are only allowed to be via Cloudflare. (With proxy disabled, it still occurs)
That would seem to indicate an issue with your web server logging configuration. Can you share the logging config?
Anybody who knows your Origin IP address can get to it, these are usually people you really don’t want to talk directly to your origin. It is best to use a local firewall to stop anybody except Cloudflare being able to send traffic to your Origin on 80/443.
If you can just use simple tcpdump or wireshark and see what headers are really coming.
Let me clarify, our system doesn’t run the way you would expect. Its a shared hosting system relying on docker. So what we are logging is coming from the request headers (within the dockers enviroment, in this case Node.js via Express) not the webserver.
Yes there is a firewall blocking direct access to the IP, its port forwarded depending on the docker container’s port (which requires a proxy_pass via the webserver)
OK. But when you disable the Cloudflare Proxy you still see RFC1918 addresses on your logs as you said above?
That is correct. The exact same RFC1918 address to be exact.
I’m guessing that there is an error in the
proxy_pass setup, such as not having
proxy_pass_request_headers enabled. Either way, if you are getting the same junk value with and without CF being in the path I would expect that the issue is not with Cloudflare.
I am coming to the conclusion that the only way to fix this is to remove the site from cloudflare entirely. Considering we did not start getting RFC1918 addresses until we moved the site to cloudflare.
Were you logging CF-Connecting-IP before moving to Cloudflare?
As a test, run the following against the origin directly. (Both the Cloudflare facing proxy, as well as the web server itself. Adjust as needed for hostname, port and origin IP)
curl https://www.example.com/ --connect-to ::ORIGINIP -H "CF-Connecting-IP: This Test Appears in the Logs"
Prior to cloudflare I was using the x-forwarded-for address which returned the true visitor IP
And if you revert to x-forwarded-for does it get resolved? Cloudflare pass XFF also.
x-forwarded-for does send through the true visitor IP along with cloudflare’s pseudo IP
XFF includes the client IP, appended to any XFF request header received by Cloudflare.
What do you mean by Pseudo IP? If you are referring to the Pseudo IPv4 migration measure for IPv6, then you can configure that a number of ways, but it does not use RFC1918 addresses.
It’s no longer sending the RFC1918 address, only the visitor IP and cloudflare’s pseudo IPv4, which is what I wanted it to be doing.
thank you for sharing with us
This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.