Problem accessing sites secured by Cloudflare with IPv6

Hey community,
I have a problem accessing websites secured by Cloudflare with my IPv6 prefix on work.
We noticed it a few weeks ago when a colleague was not able to access the login-page on gitlab.com. Gitlab itself works without a problem, but after clicking on “Login”, one gets stuck in a redirect loop “Checking your browser”.
We tried multiple devices and browsers, but without any success.
Together with our IT support, I analyzed the network configuration and traffic, but everything looks okay. The server responds in a normal way. Then we learned that the problem is solved by disabling IPv6. Using IPv4, everything works normally, I get directed to the login page within a few seconds, with IPv6 one gets directed after ~12 minutes. But IPv6 is necessary for the work.
The problem also exists on other sites (for example udemy.com), but not all. After checking the common ground, I learned that all problematic sites are secured by Cloudflare. A internet research showed multiple results regarding Cloudflare blocking a whole IPv6 prefix. They were all created at the same time (seems to be one crosspost), but it describes exactly my problem: Cloudflare problems with IPv6 range visiting any website. Unfortunately, the comments don’t help me, ProjectHoneyPot doesn’t know any of my IPv6 addresses I used during my tests.
I also checked the network for any “bots” or similar, but everything looks okay.
I created an account and a ticket at Cloudflare but it seems that due to a high demand support tickets per mail are currently prioritized for paying customers and they told me to ask the community and include “problem accessing sites secured by Cloudflare with IPv6” in the details.
Do you know, if there is any possibility to check if my IPv6 Prefix is being blocked? Or do you have any other idea what could be the problem?

Greetings
Max

That sounds remarkably similar to a problem I had some time ago; same symptoms, same fix by disabling IPv6 for some but not all website. Sounds like we’ve been through similar troubleshooting steps too.

Turned out that my own IPv6 prefix was being blocked, because it was listed incorrectly by the geolocation service (Maxmind) that cloudflare uses. It listed me in Russia, instead of the UK. In fact an entire /40 prefix was wrongly listed as Russia. The websites that I had trouble with had decided to limit connectivity (via Cloudflare’s service) to Russian sources.

So, check your listed IPv6 geolocation. If it’s wrong, you can submit a change request yourself. It took a week or so if I recall correctly. the lookup is here:

https://www.maxmind.com/en/geoip-demo

Note that Cloudflare support NEVER helped me in the slightest; never even replied to several requests for support or me informing them when I finally discovered the issue. Absolutely atrocious for a company that can (and did) arbitrarily block one’s access to a large part of the internet because of their own mistake. At least Maxmind fixed it eventually, when told to.

1 Like

Hey @foxyrick
Thank you for your reply. I forgot to mention that I already checked the geolocation of my IP address with a link from the Thread on HE-forums: GeoIP2 Databases Demo | MaxMind. It shows my geolocation correctly as “DE”, so this should not be the problem.

I’m sorry that the support didn’t reply to you, at least they replied to me and told me to ask the community.

How do you know, that the websites limited the connectivity? Did you create a support ticket on their sites or is there some tool?

Greetings
Max

1 Like

Someone from another forum helped me out by telling me to try to access a certain file on the website, that returned some information including the incorrect country code. I’ll try to find what in case it’s useful to you… give me a few minutes to search.

Found it: append
/cdn-cgi/trace
to the website URL.

It’s not that the info said I was being blocked, as such, but I made the inference from the country code myself along with some tests from another prefix.

Thank you for the path
unfortunately, I’m currently not in the office, therefore I can’t test it. But I tested it at home and it shows:

fl=50f37
h=gitlab.com
ip=2003:db:XX:XX:XX:XX:XX:XX
ts=1618915431.862
visit_scheme=https
uag=Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:87.0) Gecko/20100101 Firefox/87.0
colo=OTP
http=http/2
loc=DE
tls=TLSv1.3
sni=plaintext
warp=off
gateway=off

The most interesting key seems to be “loc”, but it should be the same as in the previously mentioned GeoIP database of MaxMind. I will test it once I’m in the office again.

Thank you for your help.

1 Like

Today I was able to try the site gitlab.com/cdn-cgi/trace in my office:

fl=71f652
h=gitlab.com
ip=2a02:5a0:XX:XX:XX:XX:XX:XX
ts=1619073303.919
visit_scheme=https
uag=Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:88.0) Gecko/20100101 Firefox/88.0
colo=FRA
http=http/2
loc=DE
tls=TLSv1.3
sni=plaintext
warp=off
gateway=off

As expected, the result looks okay.

The site https://gitlab.com does not run on cloudflare! So the cloudflare community can’t help you with the issue with that site. Nor does udemy.com. So neither site has a cloudflare certifcate, so I don’t think it’s running on cloudflare! Show me the sites in your cloudflare dashboard please. So I can see if they are running on cloudflare. Also here are the results for the links.

Hi @AppleSlayer
The Homepage of Gitlab is about.gitlab.com. On this site, I don’t have any problem. But when I click on “Login”, then I get redirected to https://gitlab.com/users/sign_in. When you check the AAAA-Record of gitlab.com, you see, that it is 2606:4700:90:0:f22e:fbec:5bed:a9b9. Then you can check the WhoIs Entry of that IPv6 address and you see, that it belongs to CloudFlare.
The AAAA-Entry of www.udemy.com resolves to 2606:4700::6810:4155 and the WhoIs entry belongs to Cloudflare, too, because they own the whole 2606:4700::/36 (AS13335).
Regarding the certificates: The certificates are independent of the website hoster. If you want, you can get your domain at provider A, buy your certificate at provider B and host your site at Provider C, so this is unrelated.

Greetings
Max