CF IP proxy not accessible from my ISP but OK from other sources

DNS & Network
#1

A curious connectivity issue that I don’t think is caused by my configuration - has anyone any ideas for things I could try?

My website’s Cloudflare assigned IP is 162.159.137.85 - i.e. when I enable the DNS proxy “orange cloud” feature, this IP is returned when pinging the domain.

When using the proxy feature, I can’t access the website via my UK ISP (TalkTalk) on two IPs: 79.69.xxx.xxx and 79.75.xxx.xxx, the connection just times out.

I’m seeing no difference in specifying http: , https: or nothing on the URL line and my other two websites on the same server, proxied by CF on different IPs, are working as expected.

I can access the website from my mobile phone 4G, Vultr ( 192.248.xxx.xxx ), the Cloudflare Diagnostic Center tool or via an uptime test (e.g. Uptrends).

When I switch off the CF proxy, all works fine for me through my ISP, though I am now exposing my server IP to the wider Internet.

Is there a way of forcing a CF IP proxy change? Many thanks for any thoughts.

Note: I thought this was rather similar behaviour to that reported here: https://community.cloudflare.com/t/weird-timeout-issue/370526/36 but the problem there had already been resolved at CF. I thought it best to open my own topic here.

#2

What’s the domain?

#3

Sorry sandro - my leaving this out wasn’t helpful !

www.sculpturescript.com is the domain. I have CF proxy turned on at the moment.

Hope that this helps

#4

Proxying is currently enabled, right?

I am asking because these IP addresses are unusual. Was your domain with another provider, which may have also used Cloudflare, before you added it to Cloudflare?

#5

No - I’ve been running these for well over a year.

The CF proxy address (162.159.137.85) is part of the CF IPv4 ranges, I think - though not one I’ve seen before.

192.248.xxx.xxx is where I’m running the website on a Vultr instance, with A records in the CF-hosted DNS for root and www.

79.69.xxx.xxx and 79.75.xxx.xxx IPs are my TalkTalk ISP IPs - so I’m acting as a client there in testing my website.

Thanks for looking to help!

#6

Proxying is currently on.

#7

162 is typically not an address which is assigned to a domain.

Are you using a standard Cloudflare setup or have you signed up via any third party?

Which operating system are you using?

#8

That is interesting.

I did (temporarily) trial Siteground as a hosting solution two years ago, and used CF through their website, but didn’t like the solution and returned my domains to my own personal CF account, so I login and maintain directly via the CF website.

The website is hosted on a Vultr instance, Linux with a standard LAMP stack. I log in to CF and view my websites on a Windows 10 machine.

Thanks

#9

Does the right content load? Was that content ever on that other host?

Can you run the following command and post the output?

tracert 162.159.137.85
#10

The right content is loading and at least some of it was never on Siteground.

tracert output from Windows:

C:\Windows\System32>tracert 162.159.137.85

Tracing route to cve-2020-0601-00.cloudflareresearch.com [162.159.137.85]
over a maximum of 30 hops:

  1     1 ms     1 ms     1 ms  10.231.0.1
  2     *        *        *     Request timed out.
  3    14 ms    12 ms    13 ms  host-78-144-8-122.as13285.net [78.144.8.122]
  4     *        *        *     Request timed out.
  5     *        *        *     Request timed out.
  6     *        *        *     Request timed out.
  7     *        *        *     Request timed out.
  8     *        *        *     Request timed out.
  9     *        *        *     Request timed out.
 10     *        *        *     Request timed out.
 11     *        *        *     Request timed out.
 12     *        *        *     Request timed out.
 13     *        *        *     Request timed out.
 14     *        *        *     Request timed out.
 15     *        *        *     Request timed out.
 16     *        *        *     Request timed out.
 17     *        *        *     Request timed out.
 18     *        *        *     Request timed out.
 19     *        *        *     Request timed out.
 20     *        *        *     Request timed out.
 21     *        *        *     Request timed out.
 22     *        *        *     Request timed out.
 23     *        *        *     Request timed out.
 24     *        *        *     Request timed out.
 25     *        *        *     Request timed out.
 26     *        *        *     Request timed out.
 27     *        *        *     Request timed out.
 28     *        *        *     Request timed out.
 29     *        *        *     Request timed out.
 30     *        *        *     Request timed out.

Trace complete.

when compared to the successful equivalent command from the server instance:

traceroute to 162.159.137.85 (162.159.137.85), 64 hops max
  1   *  *  *
  2   45.63.102.161  15.159ms  20.832ms  21.888ms
  3   *  *  *
  4   *  *  *
  5   195.66.225.179  128.509ms  31.844ms  5.559ms
  6   172.70.160.4  1.157ms  0.972ms  1.090ms
  7   162.159.137.85  0.931ms  0.997ms  0.807ms
#11

That traceroute seems to suggest the request never leaves your provider’s network.

That’s something you should probably clarify with your provide, as Cloudflare has no control over their routing. On the other, I still wonder why you get such an address assigned in the first place.

The site is generally loading fine

sitemeer.com/#https://www.sculpturescript.com

but a 162 address is unusual nonetheless. I’d also try to delete any possible Cloudflare integrations with other providers (e.g. the one you mentioned). Often such setups get stuck and override your own settings, however that’s usually not related to the IP address Cloudflare resolves.

#12

I’ll check that with the provider - it seems odd that a UK IP would refuse to route to a US mainstream server.

I’ll also check to see if my Siteground account is still open to check on the integrations question.

#13

That connection should not go to the US in the first place, but I’d definitely clarify that with the provider, as well as making sure no other provider still has your domain “hijacked”.

#14

Hi sandro,

No particular feedback from provider as to what the problem might have been or why this was the solution: turn my domestic routers off for an hour, thus getting a new IP address assigned.

Now it works.

On the interesting problem of the US CF IP address - I can’t find any references to integrations in either my CF or Siteground accounts (indeed the latter is completely empty). Would it be OK for me to note my DNS details, delete the domain from my CF account, wait a day for things to settle and re-add it to see if the allocated IP is changed?

#15

If your domain was stuck on some other configuration, I am afraid just deleting it from your account wouldn’t fix it. It would need to be deleted from that other configuration, if such exists.

Still, you can certainly try it, though I’d probably try with another account.

#16

Many thanks - I’ll mark this as solved as I’m up and running now. The US IP thing is unusual but doesn’t appear to be hurting, so I’ll leave it for now.

#17

It’s usually a US registered IP address. That’s not unusual, the unusual thing is the 162 address.

It almost seems as if your ISP IP address was blocked somewhere along the route to Cloudflare, but that’s something only your ISP could confirm.

#18

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