My website - deepcoder.co.uk - is being blocked only for computers

[DeepCoder]

My website - deepcoder.co.uk - is being blocked only for computers ?

I open my website on my PC and it won't work. Then i tried another PC and still it won't work. But when i open it on a iphone without a sim card. It works.

It only happens on my router and i reset it and restarted it but still it won't work

Could someone help me ?

[DeepCoder]

The website works with a vpn but doesn't work without a vpn

[mikeliuk]

Hi @DeepCoder ,

In the above, you have said "I can connect to it" directly via the IP address. Now you have said it doesn't work without VPN. This is contradictory.

I highly recommend that you address the issue in terms of

1. Name resolution; and

2. Reachability by the IP address.

I assume you mean that with a VPN both 1. and 2. work. Without a VPN, which of 1. or 2. fails?

When you see failure, what does nslookup resolve the domain name to, if anything?

So, assuming your screenshots are without using a VPN, it looks like nslookup resolves the correct IP but you cannot access that IP in a browser. I assume you've already tried another browser.

In a Windows 10 commandline, attempt "tracert 199.188.200.112" to see if the route to the server can be determined. Also "ping 199.188.200.112" to see if you can hit it.

Ok, now the weird thing. When I visit deepcoder.co.uk in Microsoft Edge, I see the website. When I visit the server 199.188.200.112 I get a certificate problem so the servers seem to be somehow different.

[XRaySpeX]

---

@DeepCoder wrote:

nslookup : 

https://prnt.sc/18irik1

That shows that your domain resolves correctly when you use those DNS appended to nslookup command but what do you get when you type plain:

nslookup deepcoder.co.uk

without any DNS appended, so as to see how it resolves with the actual DNS you have in place?

[XRaySpeX]

I hope you are not confusing us by running these tests over a VPN when we think you are running them normally.

[XRaySpeX]

---

@mikeliuk wrote:

In the above, you have said "I can connect to it" directly via the IP address. Now you have said it doesn't work without VPN. This is contradictory.

No, OP said earlier that IP addy connects & now says domain name works only with VPN. No contradiction!

[mikeliuk]

Hi @DeepCoder ,

Does your web server have a static IPv4 address and should that address be 199.188.200.112 ?

The below behaviour is a little weird so I'm posting for someone more knowledgeable than myself to interpret. nmap against the IP address returns quickly. nmap against the domain name returns dead slowly. It feels like there's something sitting in front of that IP address and load-balancing or something similar (e.g. a reverse proxy).

[x@x ~]$ nmap 199.188.200.112
Starting Nmap 7.70 ( https://nmap.org ) at 2021-07-04 15:45 BST
Nmap scan report for server237-5.web-hosting.com (199.188.200.112)
Host is up (0.083s latency).
Not shown: 984 filtered ports
PORT STATE SERVICE
20/tcp closed ftp-data
21/tcp open ftp
25/tcp open smtp
26/tcp open rsftp
53/tcp open domain
80/tcp open http
110/tcp open pop3
113/tcp closed ident
143/tcp open imap
443/tcp open https
465/tcp open smtps
587/tcp open submission
993/tcp open imaps
995/tcp open pop3s
2000/tcp open cisco-sccp
5060/tcp open sip

Nmap done: 1 IP address (1 host up) scanned in 25.68 seconds
[x@x ~]$ nmap deepcoder.co.uk
Starting Nmap 7.70 ( https://nmap.org ) at 2021-07-04 15:46 BST
Stats: 0:02:33 elapsed; 0 hosts completed (1 up), 1 undergoing Connect Scan
Connect Scan Timing: About 40.40% done; ETC: 15:53 (0:03:47 remaining)
Stats: 0:07:59 elapsed; 0 hosts completed (1 up), 1 undergoing Connect Scan
Connect Scan Timing: About 62.07% done; ETC: 15:59 (0:04:53 remaining)
Stats: 0:12:29 elapsed; 0 hosts completed (1 up), 1 undergoing Connect Scan
Connect Scan Timing: About 70.23% done; ETC: 16:04 (0:05:17 remaining)
Stats: 0:20:43 elapsed; 0 hosts completed (1 up), 1 undergoing Connect Scan
Connect Scan Timing: About 85.20% done; ETC: 16:11 (0:03:36 remaining)
Nmap scan report for deepcoder.co.uk (199.188.200.112)
Host is up (0.075s latency).
rDNS record for 199.188.200.112: server237-5.web-hosting.com
Not shown: 987 filtered ports
PORT STATE SERVICE
20/tcp closed ftp-data
21/tcp open ftp
25/tcp open smtp
53/tcp open domain
80/tcp open http
110/tcp open pop3
113/tcp closed ident
143/tcp open imap
443/tcp open https
587/tcp open submission
993/tcp open imaps
995/tcp open pop3s
2000/tcp open cisco-sccp

Nmap done: 1 IP address (1 host up) scanned in 1734.25 seconds

There seems to occasionally be a routing issue. 53% packet loss and then 18% packet loss. After that, two further tests were pretty steady.

[x@x~]$ ping deepcoder.co.uk
PING deepcoder.co.uk (199.188.200.112) 56(84) bytes of data.
64 bytes from server237-5.web-hosting.com (199.188.200.112): icmp_seq=2 ttl=41 time=178 ms
64 bytes from server237-5.web-hosting.com (199.188.200.112): icmp_seq=14 ttl=41 time=179 ms
64 bytes from server237-5.web-hosting.com (199.188.200.112): icmp_seq=16 ttl=41 time=191 ms
64 bytes from server237-5.web-hosting.com (199.188.200.112): icmp_seq=18 ttl=41 time=162 ms
64 bytes from server237-5.web-hosting.com (199.188.200.112): icmp_seq=19 ttl=41 time=161 ms
64 bytes from server237-5.web-hosting.com (199.188.200.112): icmp_seq=20 ttl=41 time=168 ms
64 bytes from server237-5.web-hosting.com (199.188.200.112): icmp_seq=21 ttl=41 time=159 ms
64 bytes from server237-5.web-hosting.com (199.188.200.112): icmp_seq=22 ttl=41 time=165 ms
64 bytes from server237-5.web-hosting.com (199.188.200.112): icmp_seq=23 ttl=41 time=164 ms
64 bytes from server237-5.web-hosting.com (199.188.200.112): icmp_seq=24 ttl=41 time=162 ms
64 bytes from server237-5.web-hosting.com (199.188.200.112): icmp_seq=25 ttl=41 time=159 ms
64 bytes from server237-5.web-hosting.com (199.188.200.112): icmp_seq=26 ttl=41 time=165 ms
64 bytes from server237-5.web-hosting.com (199.188.200.112): icmp_seq=27 ttl=41 time=163 ms
^C
--- deepcoder.co.uk ping statistics ---
28 packets transmitted, 13 received, 53.5714% packet loss, time 472ms
rtt min/avg/max/mdev = 158.624/167.455/190.994/9.195 ms
[x@x ~]$ ping 199.188.200.112
PING 199.188.200.112 (199.188.200.112) 56(84) bytes of data.
64 bytes from 199.188.200.112: icmp_seq=2 ttl=41 time=195 ms
64 bytes from 199.188.200.112: icmp_seq=3 ttl=41 time=168 ms
64 bytes from 199.188.200.112: icmp_seq=4 ttl=41 time=166 ms
64 bytes from 199.188.200.112: icmp_seq=8 ttl=41 time=279 ms
64 bytes from 199.188.200.112: icmp_seq=9 ttl=41 time=164 ms
64 bytes from 199.188.200.112: icmp_seq=10 ttl=41 time=169 ms
64 bytes from 199.188.200.112: icmp_seq=11 ttl=41 time=165 ms
64 bytes from 199.188.200.112: icmp_seq=12 ttl=41 time=158 ms
64 bytes from 199.188.200.112: icmp_seq=13 ttl=41 time=165 ms
64 bytes from 199.188.200.112: icmp_seq=14 ttl=41 time=166 ms
64 bytes from 199.188.200.112: icmp_seq=15 ttl=41 time=158 ms
64 bytes from 199.188.200.112: icmp_seq=16 ttl=41 time=162 ms
64 bytes from 199.188.200.112: icmp_seq=17 ttl=41 time=166 ms
64 bytes from 199.188.200.112: icmp_seq=18 ttl=41 time=169 ms
64 bytes from 199.188.200.112: icmp_seq=19 ttl=41 time=165 ms
64 bytes from 199.188.200.112: icmp_seq=20 ttl=41 time=163 ms
64 bytes from 199.188.200.112: icmp_seq=21 ttl=41 time=159 ms
64 bytes from 199.188.200.112: icmp_seq=22 ttl=41 time=162 ms
^C
--- 199.188.200.112 ping statistics ---
22 packets transmitted, 18 received, 18.1818% packet loss, time 153ms
rtt min/avg/max/mdev = 157.804/172.269/279.194/27.067 ms

[mikeliuk]

cPanel shared hosting. The IP address probably serves multiple websites and it decides what to serve or where to direct the traffic depending on what domain name was given. This makes direct access by IP address impossible.

I'm not a web hosting specialist and can only speculate that the web hosting reverse proxy is confusing accesses to that website on that IP address (and port 443) with established connections to the cPanel management stuff. To test this, the VPN access can used to access the website management functionality (deliberately maintaining established connections with the same IP address) and then a check of the website to see if the problem is seen.