Unable to see the CF-IPCountry and CF-Connecting-IP header

#1

I went through the support page here - https://support.cloudflare.com/hc/en-us/articles/200170986

Even after enabling the IP Geolocation functionality in the Network tab, I am unable to see the “CF-IPCountry” in the response headers of my site.

Also, the CF-Connecting-IP header and the other headers mentioned in that support article are not visible when I check my requests. Do I need to make some settings changes in the CloudFlare dashboard to make those headers visible in the requests?

The headers that are sent in the response are -

>> curl --head http://www.stylifyyourblog.com/ -i
HTTP/1.1 200 OK
Date: Thu, 13 Jul 2017 07:52:16 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Set-Cookie: __cfduid=d32d633f9467f1b10294070b53557eda61499932336; expires=Fri, 13-Jul-18 07:52:16 GMT; path=/; domain=.stylifyyourblog.com; HttpOnly
Expires: Sun, 06 Aug 2017 07:52:16 GMT
Cache-Control: public, max-age=2073600
Last-Modified: Thu, 13 Jul 2017 05:40:28 GMT
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
CF-Cache-Status: HIT
Server: cloudflare-nginx
CF-RAY: 37daa9712354642d-FRA
#2

Hi @prayag.verma,

It’s important to understand that your cURL there is showing HTTP Response headers. The CF-Connecting-IP and CF-IPCountry header are HTTP Request headers.

Keep in mind when Cloudflare is enabled a HTTP request goes like this:

Visitor > Cloudflare > Origin Server

Your origin server will receive the HTTP request headers from Cloudflare. Depending on what scripting technology you use on your origin server, there are different ways of outputting the HTTP Request headers the server receives if you just want to view them for testing. For example with PHP there are a few different ways of doing this:

#3

With curl -i or curl -I you only see the HTTP Response header. The CF-IPCountry and CF-Connecting-IP are Request Header to your backend.

If you want to see the headers content, try setting a PHP script that will print the request headers on your website and visit it.

#4

You can add some code on your Origin web server to echo the request headers added by CF into the response headers:

In NGinx something like:
add_header CF-Connecting-IP $http_cf_connecting_ip always; add_header CF-IPCountry $http_cf_connecting_ip always;

(I added them from the top of my head, so please check they work before using)

A few things about relying on those request headers.

You need to make sure that you do not allow CF to cache the responses. Otherwise you run the risk of making a response based on the assumed IP or Country, but the second request to the CF server will be served from cache and your Origin logic will not be applied. Cloudflares cache key is Origin Request Header (for CORS), proto, host, path (and perhaps query string if configured), so client IP or country is not relied on for caching.

You need to ensure that the headers have not been spoofed. The best way to do this is using Authenticated Origin Pulls. You can have good assurance that the header has been set by CF, and not by another party you knows where your origin is. (I do not think that firewall rules on the origin are enough, as an attacker could use a cloudflare account with Host Header Override to get through your firewall rules and send spoofed CF-IPCountry headers)

If you perform caching on your Origin, make sure you include those Headers in the Cache-Key.

#5

Thanks @michael , @tanto259 and @simon for the all the information. This cleared the doubts that I had.

I am new to this and wrongful assumed that those headers would be sent in the response. Thanks for explaining things in detail

My main goal was to pass the visitor IP address to Nginx so that those could be used by fail2ban. I was able to do that now. ( I utilized this as well - How do I restore original visitor IP with Nginx )

#6

Q1. I check the Cloudflare IP’s every couple months, use the NGINX realip module and have rules set in a /etc/nginx.custom.d/realip.conf file, and this has worked fine for years. Now, I see our own origin server address when someone fills out a form and a plugin (this being gravity forms wp) records it incorrectly. This did not happen for years. Otherwise my server logs do record the correct IP’s but the plugin prints out useful data and now I can’t follow it.

Separate note:

It probably would be a better idea if CloudFlare pushed out when these changed (not like they don’t send out millions of emails anyway…).

Q2. So, why did I have 199.27.128.0 in there a while back (and it is a CF ip) and now I see it’s not on the current list? I don’t think I’m crazy but you never know.

This is my latest file content mimicking CF https://www.cloudflare.com/ips/:

set_real_ip_from 103.21.244.0/22;
set_real_ip_from 103.22.200.0/22;
set_real_ip_from 103.31.4.0/22;
set_real_ip_from 104.16.0.0/12;
set_real_ip_from 108.162.192.0/18;
set_real_ip_from 131.0.72.0/22;
set_real_ip_from 141.101.64.0/18;
set_real_ip_from 162.158.0.0/15;
set_real_ip_from 172.64.0.0/13;
set_real_ip_from 173.245.48.0/20;
set_real_ip_from 188.114.96.0/20;
set_real_ip_from 190.93.240.0/20;
set_real_ip_from 197.234.240.0/22;
set_real_ip_from 198.41.128.0/17;
set_real_ip_from 127.0.0.1/32;
real_ip_header CF-Connecting-IP;

set_real_ip_from 2400:cb00::/32;
set_real_ip_from 2405:8100::/32;
set_real_ip_from 2405:b500::/32;
set_real_ip_from 2606:4700::/32;
set_real_ip_from 2803:f800::/32;
set_real_ip_from 2c0f:f248::/32;
set_real_ip_from 2a06:98c0::/29;
real_ip_header CF-Connecting-IP;

Thanks,
Stu

PS - we us strict crypto with CF certs

Protocols: TLSv1 TLSv1.1 TLSv1.2
Ciphers on: EECDH+CHACHA20:EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256:EECDH+3DES:RSA+3DES:!MD5

#7

@Stuart if you’re seeing your origin server IP and not a Cloudflare IP that sounds like something unrelated to Cloudflare. I would expect if it were Cloudflare related for you to see a Cloudflare IP. Are you running any form of proxy or cache on your origin such as Varnish?

Regarding the IP ranges, these do not change very often, for a feel for this take a look at the change detection log (a 3rd party service) for the IPv4 ranges:

https://www.changedetection.com/log/cloudflare/ips-v4_log.html

That said, we definitely appreciate giving you better notice of any changes is important and this feedback has been shared internally so we’ll make sure we communicate better in future.