CF_CONNECTING_IP not showing real users ip address

What is the name of the domain?

What is the issue you’re encountering

A bot is not showing it’s IP address in the CF_CONNECTING_IP header (it’s showing Cloudflare’s IP) and it’s refreshing the homepage thousands of times a hour

What steps have you taken to resolve the issue?

I have verified that 104.28.32.0 and 104.28.92.0 get detected via my PHP code, but are NOT detecting the real user IP address in the CF_CONNECTION header.

What is the current SSL/TLS setting?

Full

Here is where I posted about this issue before: CF_CONNECTING_IP With Cloudflare IP Validation using PHP - #10 by Laudian

I know that there is some confusion with how I have my IP Address rules posted… but I have verified that both 104.28.32.0 and 104.28.92.0 fall into the rule and SHOULD be converted to the real visitors IP address.

Here is my ‘example’ code:

<?php

	$ip='104.28.92.0';
	$lip=ip2long($ip);
	if($lip >= '2728263680' && $lip <= '2728394751' || 
		$lip >= '1745879040' && $lip <= '1746927615' || 
		$lip >= '2889875456' && $lip <= '2890399743' ||
		$lip >= '2918526976' && $lip <= '2918531071' ||		
		$lip >= '1729491968' && $lip <= '1729492991' ||
		$lip >= '1729546240' && $lip <= '1729547263' ||
		$lip >= '1730085888' && $lip <= '1730086911' ||
		$lip >= '3320508416' && $lip <= '3320509439' ||
		$lip >= '2372222976' && $lip <= '2372239359' ||
		$lip >= '1822605312' && $lip <= '1822621695' ||
		$lip >= '3193827328' && $lip <= '3193831423' ||
		$lip >= '3161612288' && $lip <= '3161616383' ||
		$lip >= '1746403328' && $lip <= '1746927615' ||
		$lip >= '2197833728' && $lip <= '2197834751' ||
		$lip >= '3324608512' && $lip <= '3324641279'){
			echo "THE OLD IP IS $ip";
			$ip='IP IN RANGE. NOW LOOKING FOR CF_CONNECTING IP HEADER'; //$_SERVER['HTTP_CF_CONNECTING_IP'];
			echo "NEW IP IS $ip!";
	}
echo "The ip is $ip";

Yet , this bot (Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko)) is refreshing my homepage every 30 seconds under the IP address:

104.28.92.0
104.28.32.0

When I look in my Analytics & Logs for Cloudflare, it says the Source IP’s are Cloudflare; Here is a screenshot:

There appear to be thousands and thousands of requests coming from CLOUDFLARENET, there’s even User-agent ‘Mozilla/5.0’ pulling 800 requests every 30 minutes…

Here are the exact headers that my host is receiving:

Host: www.infinitesweeps.com
X-Real-IP: 162.158.140.160
X-Forwarded-For: 104.28.32.244,104.28.32.244, 162.158.140.160
cf-ray: 8e02d2b9ef3974c6-PHX
priority: u=0, i
CF-IPCountry: US
accept-encoding: gzip, br
cdn-loop: cloudflare; loops=1
X-Forwarded-Proto: https
accept-language: en-US,en;q=0.9
CF-Visitor: {"scheme":"https"}
accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko)
CF-Connecting-IP: 104.28.32.244

It has the Cloudflare IP address in the CF-Connecting-IP: 104.28.32.244

Not the real users IP address. This allows them to avoid all limitations like logins and more to the website.

Please help or tell me how I can block these. It appears it’s coming FROM cloudflare. Don’t the Cloudflare workers identify themselves as such? What’s going on here?

The ONLY pattern that appears to be different is the Order in header requests. It appears these illegitimate requests have these three headers appended to the end:

accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko)
CF-Connecting-IP: 104.28.92.177

It’s like a Cloudflare Worker is stripping the header somehow and then appending this bogus information to the end to have a Cloudflare IP address. How do I block this or what do I do?

What’s the confusion here? This looks like a repeat of the last thread. You keep saying it’s not sending the cf-connecting-ip header, yet it’s the last line in the example you posted.

“What’s the confusion here? This looks like a repeat of the last thread. You keep saying it’s not sending the cf-connecting-ip header, yet it’s the last line in the example you posted.”

It’s showing a Cloudflare IP address in the CF-CONNECTING-IP header. Not the connecting IP address.

I’m sorry I probably should clarify: When I say not sending the CF-CONNECTING-IP, it’s not sending the real users IP Address.

Basically $_SERVER[‘HTTP_CF_CONNECTING_IP’]; is giving me the same results as $_SERVER[‘REMOTE_ADDR’]

It’s like there are bots using Cloudflare Workers to request my website over and over.

Please help - here are examples of the difference between the requests

Here is a “bad request”

Host: www.infinitesweeps.com
X-Real-IP: 162.158.140.233
X-Forwarded-For: 104.28.92.177,104.28.92.177, 162.158.140.233
cf-ray: 8e02e4f0ea8b2588-PHX
priority: u=0, i
CF-IPCountry: US
accept-encoding: gzip, br
cdn-loop: cloudflare; loops=1
X-Forwarded-Proto: https
accept-language: en-US,en;q=0.9
CF-Visitor: {"scheme":"https"}
accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko)
CF-Connecting-IP: 104.28.92.177

Here is a good request:

Host: www.infinitesweeps.com
X-Real-IP: 162.158.140.191
X-Forwarded-For: 87.120.116.68,87.120.116.68, 162.158.140.191
cf-ray: 8e02e518ea1a0bad-PHX
CF-Connecting-IP: 87.120.116.68
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
accept-encoding: gzip, br
X-Forwarded-Proto: https
cdn-loop: cloudflare; loops=1
CF-Visitor: {"scheme":"https"}
CF-IPCountry: BG
Accept-Language: en-US,en;q=0.5
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.114 Safari/537.36

The bad headers have the wrong order for ‘accept:’ ‘user-agent’ and ‘CF-Connecting-IP’ headers and they always point back to Cloudflare IP address, not the real users IP address.

Who is the real CF-Connecting-IP ? Cloudflare can’t request pages its self?

Look at the headers… that’s everything my host receives for these requests.

Please write me a simple code on how to get the users IP address from the ‘bad request’ . The only IPS are Cloudflare.

CF-Connecting-IP: 104.28.92.177
CIDR:           104.16.0.0/12
NetName:        CLOUDFLARENET

X-Forwarded-For: 104.28.92.177,104.28.92.177, 162.158.140.233
CIDR:           162.158.0.0/15
NetName:        CLOUDFLARENET

The “good” requests have the users real IP address, the bad requests show Cloudflare as the users IP address.

Every 10 seconds I am getting a “bad request” to my homepage that has a CF-Connecting-IP of Cloudflare.

I don’t understand how I’m explaining this wrong.

Note to self: I put in a temporary rule to make Cloudflare a “hosting provider”.

Bump!

What, exactly, makes you think they’re using Workers?

I’m trying my hardest to not make this a repeat of the last thread, because that would be a tremendous waste of time.

1 Like

"What, exactly, makes you think they’re using Workers?

I’m trying my hardest to not make this a repeat of the last thread, because that would be a tremendous waste of time."

Why does Cloudflare just want to argue with me?

What should I think if the request doesn’t have a visitors IP address?

How do I get the users IP address? NOt Cloudflares ip address?

Out of everything I post, you guys nit pick it and come back with “You spelled the word wrong” Out of everything I posted, you say “Why do you think it’s from a worker”?

You don’t answer ANY questions about NOT SHOWING REAL USERS IP ADDRESS (it’s in the title) and I showed example code and more.

How is somebody refreshing my page 20,000 times a day a “waste of time”? Every 10 seconds this same bot refreshes my page to steal my content, which Cloudflare is supposed to block.

How can I block this person? The headers say: ‘CF-Connecting-IP: 104.28.92.177’ - One cannot just block Cloudflares IP ranges - there is legitimate traffic (like in a newsletter) that comes proxied from the Cloudflare servers. These requests are NOT proxies email requests. There are literally a couple users switching from VPN’s, to Cloudflare Connecting IPS back to VPNs (5 requests from VPN, the next 5 from Cloudflare, then 5 more from a different VPN). It’s like the Cloudflare is a proxy.

That IP is not in the 104.24.0.0/14 range published by Cloudflare (which stops at 104.27.255.255), so it’s not from the proxy. It’s a WARP user so it is the client IP address as you would expect so you can block it on Cloudflare or your server.

2 Likes

Dude, I replied in the other thread about that. I have an extended rule to make the ip from 2 lines into 1. I will comment again here (by wasting tons of time) to come back with something irrelevant for you!!!

INSTEAD OF USING 104.24.0.0/14

I USE

CIDR: 104.16.0.0/12
NetRange: 104.16.0.0 - 104.31.255.255

IT"S THE SAME THING AND IRRELEVANT. You guys keep attacking me instead of answering the question!!! We argued about this last time! WTF!!!

104.27.255.255 = 1746665471

1746665471 clearly falls inside of
$lip >= ‘1745879040’ && $lip <= ‘1746927615’ ||

I have tested this for probably 20 hours now and we’re going back to something irrelevant 100% for sure.

As I said, the proxy IPs stop at 104.27.255.255, if you are flagging 104.28.xxx.xxx onward as Cloudflare proxy IPs by using too wide a netmask, that’s your problem, because they are not used by Cloudflare proxies. They are used for other things such as WARP clients. (I’m using WARP right now and I have a 104.28.xxx.xxx IP so that is my “real” IP address that will appear in the CF-Connecting-IP header).

Perhaps write your code correctly and use the 2 104.x.x.x subnets that Cloudflare list, which is after all why they specify them like that.

https://cf.sjr.org.uk/tools/ips#detail

3 Likes

Ahh I see, I never knew there was something called WARP.

I am looking into this now. If I update my rules to only allow these new IP ranges, what will happen to the WARP ranges?

What i mean is, if most people use Firewall to block CLoudflare ips, wouldn’t WARP users not be able to access the website?

I’m so sorry for all the typing, I whois the ips and they were cloudflare so I added those into the rules too.

Can I disable WARP?

The published Cloudflare IP address list is only the IP addresses of the proxies which Cloudflare users can trust and must allow to access their origins so the proxy works.

Cloudflare has other IP addresses for non-trusted uses such as Warp, but they don’t list them. It’s up to you if you want to block them.

1 Like

Thank you for still replying, I really appreciate it. It probably is all my fault and again i’m sorry. I have one more question:

So WARP traffic is safe to assume that most websites are blocking this traffic?

WARP traffic appears to be for in network administrating. right? I could give employees basically a WARP account and allow them to access the website, correct? So if these WARP users are not from “me”, then it’s safe to block them?

Sorry for double (maybe triple asking). I’m just trying to confirm because this is LOTS of traffic and I don’t want to block a real user and/or get penalized. It’s been rough with these attackers against me lately… 20,000 requests requests today through WARP…

This area seems very vague to me, I think Cloudflare should write more info about it (why do I need it enabled again? ) About Cloudflare WARP

No idea. I don’t.

That’s one use. It’s can also be used by anyone for secure DNS and VPN-like use (Cloudflare doesn’t allow you to specify an exit location, exit is from the serving PoP) so use as an anonymiser for abuse is possible like any VPN, Tor, etc.

Why not just challenge rather than block all such requests to see if that helps?

1 Like

Well, now that I know that these WARP ips are only from 104.28.xxx.xxx - that is probably a solution. I was afraid to challenge / block “cloudflare” ips, because I’m essentially challenging the server.

But, now that my stupid self finally sees that the 104.28.xxx.xxx is still Cloudflare, but a different service, I can hopefully make headway now LOL.

Right now in my server setup, I’ve assigned these ips as ‘VPN’ which has different login restrictions and more. I THINK this will work for my setup.

Thank you so much again and sorry man, call me “ex seizure boy” and certain things (Cloudflare is one of them) my brain just doesn’t allow me to process or something like a “stuck point”.

P.S. If I got stuck in this stupid confusion, i’m sure others do and will. It would be awesome to like somewhere in the logs or somewhere, to split the AS13335 into like AS13335-b or something that distinguishes that “Hey, this is a WARP USER” - because we all use Cloudflare to Block VPN etc. and this is like a loophole in my mind, this was very hard to figure out and then once I know WARP it’s like “OHHHHHH!”.

Here’s a LINK that helps pretty much explain what WARP is instantly: https://one.one.one.one/

It’s a VPN tool… explained as ‘1.1.1.1 with WARP replaces the connection between your device and the Internet with a modern, optimized, protocol.’ :smiley:

Anyway, thanks again - I think I got it all fixed FINALLY!

UPDATE: About 1 week later I started receiving 127.0.0.1 requests and after tracking it down. It appears that the WARP users were testing the system by including the Cloudflare Connecting IP Header.

I know this was a bad config on my end - but i’m sure there are others that have this same bad configs.

Maybe it would be wise for Cloudflare to look into any requests from 104.28.xxx.xxx having a Connecting IP Header to automatically block because that is not what WARP is intended to be used for.

1 Like

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.