Https connection to a resource, located on Cloudflare, is refused from my ip

cdn

#1

Hi all. I am running an Emby server from my office. A part of it’s design requires for plugins to be installed. These plugins are located on Cloudflare (https://embydata.com) and this is where my troubles begin. The IP I am connecting (or rather Emby server app) from is refused https:// connection. We’ve tested all the possible problems in my company and with the developers of the Emby server and, after studying the dump file came to an understanding that this IP 77.94.165.51 is somehow banned/blacklisted, you name it on Cloudflare. Is there anything that can be done about this? Thanks.


#2

This could have several reasons

Website owners can ban single addresses, net ranges, even entire networks, ASNs or countries. Maybe you’re violating other security rules.

Your IP could have been banned automatically by Cloudflare due to bad reputation.

You should contact the site owner first.


#3

Can you post a screenshot of the error? Also, post the URL where you encounter the issue.


#4

Hi, thanks for a reply. The site’s owners are the developers of the Emby server. Since I am a valued member of the Emby community and they spent three days trying to figure out what has happened with my server’s access to the plugins vault - it is not on their side or behalf. We actually established that together. We, cojointly think that the problem is with Cloudfare - hence the reason I contacted you. I don’t see any specific reason why my IP should not get access to that particular site, as it is merely for downloading and updating the said plugins.

Thank you.

Regards,

Kirill


#5

Hi, thanks. The URL is meant to be accessed by an app, so no screenshot. However, to make tests, I have tried to access it via a browser - the screenshot is from the browser.

The URL itself is: https://embydata.com

Thank you.


#6

I suspect it’s not even connecting to Cloudflare, as I can get to the embydata site securely.

Can you try the following command from your computer’s command-line:
curl -Iv https://embydata.com (that a Capital i then a v)

And post the output here?


#7

Can you post the output of

ping embydata.com
nslookup embydata.com
ping www.embydata.com
nslookup www.embydata.com

#8

And a traceroute please. Best would be a tcptraceroute to embydata.com 443

Your wrote ‘from the office’ there’s a chance that your connection is locally blocked or proxied.


#9

kaynemo$ curl -Iv https://embydata.com

  • Rebuilt URL to: https://embydata.com/
  • Trying 104.27.190.149…
  • Connected to embydata.com (104.27.190.149) port 443 (#0)
  • Server aborted the SSL handshake
  • Closing connection 0

curl: (35) Server aborted the SSL handshake

kaynemo$ ping embydata.com
PING embydata.com (104.27.190.149): 56 data bytes
64 bytes from 104.27.190.149: icmp_seq=0 ttl=58 time=17.668 ms
64 bytes from 104.27.190.149: icmp_seq=1 ttl=58 time=12.301 ms
64 bytes from 104.27.190.149: icmp_seq=2 ttl=58 time=9.542 ms
64 bytes from 104.27.190.149: icmp_seq=3 ttl=58 time=10.423 ms
64 bytes from 104.27.190.149: icmp_seq=4 ttl=58 time=9.849 ms
64 bytes from 104.27.190.149: icmp_seq=5 ttl=58 time=12.029 ms
64 bytes from 104.27.190.149: icmp_seq=6 ttl=58 time=10.085 ms
64 bytes from 104.27.190.149: icmp_seq=7 ttl=58 time=10.003 ms
64 bytes from 104.27.190.149: icmp_seq=8 ttl=58 time=9.752 ms
64 bytes from 104.27.190.149: icmp_seq=9 ttl=58 time=9.276 ms
^C
embydata.com ping statistics —
10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 9.276/11.093/17.668/2.393 ms

nslookup www.embydata.com
Server: 10.0.4.2
Address: 10.0.4.2#53

Non-authoritative answer:
Name: www.embydata.com
Address: 104.27.191.149
Name: www.embydata.com
Address: 104.27.190.149

kaynemo$ traceroute embydata.com 443
traceroute: Warning: embydata.com has multiple addresses; using 104.27.190.149
traceroute to embydata.com (104.27.190.149), 64 hops max, 443 byte packets
1 10.0.2.1 (10.0.2.1) 8.543 ms 2.369 ms 2.744 ms
2 77.94.165.49 (77.94.165.49) 19.047 ms 43.866 ms 32.660 ms
3 77.94.163.1 (77.94.163.1) 21.494 ms 32.223 ms 24.569 ms
4 ae3-atlant-mmts9-msk.naukanet.ru (77.94.160.48) 41.117 ms 20.963 ms 20.727 ms
5 77.94.160.79 (77.94.160.79) 20.498 ms 21.721 ms 17.383 ms
6 spx-ix.as13335.net (194.226.100.129) 40.644 ms 16.027 ms 20.688 ms
7 104.27.190.149 (104.27.190.149) 16.807 ms 24.685 ms 29.839 ms


#10

tcptraceroute
You may have to install it on your box first.

[email protected]:~$ tcptraceroute www.embydata.com 443
Selected device eth0, address 192.168.0.243, port 41414 for outgoing packets
Tracing the path to www.embydata.com (104.27.191.149) on TCP port 443 (https), 30 hops max
1 192.168.0.3 0.183 ms 0.172 ms 0.181 ms
2 fa8-4.xxx.xxx.xxx (212.xxx.xxx.xxx) 0.725 ms 0.945 ms 0.775 ms
3 tengige0-1-1-1-t40-mse1.xxxxxxxxx (195.xxx.xxx.xx) 11.836 ms 10.457 ms 10.473 ms
4 tengige0-1-1-1-t40-mse1.xxxxxxxxx (195.xxx.xxx.xx) 10.028 ms 10.198 ms 10.109 ms
5 linx-lon1.as13335.net (195.66.225.179) 9.995 ms 10.901 ms 10.079 ms
6 104.27.191.149 [open] 9.827 ms 9.835 ms 9.822 ms


#11

aynemo$ tcptraceroute www.embydata.com 443
Selected device en1, address 10.0.3.227, port 56540 for outgoing packets
Tracing the path to www.embydata.com (104.27.190.149) on TCP port 443 (https), 30 hops max
1 10.0.2.1 4477.037 ms 1.146 ms 5.598 ms
2 77.94.165.49 4.600 ms 2.195 ms 1.829 ms
3 77.94.163.1 5.273 ms 1.823 ms 1.214 ms
4 104.27.190.149 [closed] 1.038 ms 5.353 ms 0.932 ms


#12

There you go. Traffic to Cloudflare is blocked.


#13

So you are saying it is on our side?


#14

Yes it’s not neccessarily the government. But since Russia blocked a bunch of IP adresses, mainly to make Telegram unusable, it might be a colleteral damage. Or an issue on your ISPs side.

You could retry with port 80 but i guess it will show the same result.

Good luck


#15

Ок. Thank you, good folks for the time and effort. I am back at step one. ))) Since I do get access from another location, it is probably NOT the government, no matter how many resources the actually do block, or attempt to (I mean MY government). Maybe it is an ISP and I will get my IT guys working on this again. Thank you again!


#16

Sorry, this is what my IT guys say, and this is a quote:

“If the last hop shows the message [closed] then it means that the destination machine responded, but is not listening on that port.”


#17

Compare the traces. Your traceroute has 7 HOPs the tcptraceoute 4, not showing any peering point. It would still have to pass

6 spx-ix.as13335.net (194.226.100.129) 40.644 ms 16.027 ms 20.688 ms


#18

I relayed this to my IT and asked for a time-out so they can think about this. Thank you.


#19

Ok. Did some more research. The ISP that serves our office is the fastest to respond to any government bans (hence the reason the resource is available from my home, for instance, I guess I have a lazy ISP at home). So you are right - it IS being blocked by a government order by our ISP (damn!). The only thing to do is either for you to change the frontend ip, or for us to keep using vpn while it lasts.


closed #20

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