Here is the WireShark capture: http://sunnydaysites.com/wp-content/uploads/2015/11/wireshark.pcapng I am trying to use this tool to determine why I get connection timed out when trying to access hospitalitysolutionsgroup.us (74.86.141.52) from browser on desktop PC in Virginia connected to router (192.168.1.177). Verizon is the ISP, who said the problem is beyond their equipment. Tracert indicates that po2.fcr03.sr04.dal01.networklayer.com at 66.228.118.190 is the last stop before receiving multiple 'Request timed out'. I've contacted SoftLayer which is the owner of networklayer, but no luck. Also contacted Telstra since they are associated with 66.228.118.190. No luck. I noticed their network has a Point of Presence in my city/state, which must be coincidental. I've emailed the NOC in NJ. No answer. I thought the problem could be static.reverse.realssl.com. I see that service is down for dns1.realssl.com for 74.86.12.112. I am new to network operations and WireShark, and could use some help determining where the problem is and who to contact. Thank you! asked 13 Nov '15, 15:04  JCIMB |
One Answer:
Hi, I'd say your own analysis has squeezed all what was possible from the information which can be obtained at your end. And you are lucky in terms that the problem is most likely located very close to the remote end of the network path, because my own So I think that by 45 % it should be enough to contact the site administrators of hospitalitysolutionsgroup.us, describe them the issue and tell them the public IP of the router to which your PC is connected. Your and my tracert taken together indicate that the machine on which their web site is running has a configuration issue preventing them from routing response packets to your router. The possibility that the other interface of 66.228.118.190, looking towards the 74.86.141.52, is down accounts for another 45 %. My reasons to think so are that 66.228.118.190 in your tracert and 66.228.118.186 in mine can be reasonably supposed to share the same subnet and maybe even to operate in load sharing mode. The .190 was able to send an icmp response to your tracert, so the problem is behind it as seen from your perspective, and it is unlikely that there would be more routing hops between .190 and the 74.86.141.52 than between .186 and the 74.86.141.52. The remaining 10 % account for unlikely scenarios, like one of the routers in the path which would take source IPs into account when routing and not forwarding packets sent from 74.86.141.52 properly. Most likely, some centralized anti-virus solution could be a source of such activity, if it thinks that the hospitalitysolutionsgoup.us is a source of malware or spam. For that kind of system I'd look close to your end of the path. answered 14 Nov '15, 02:43  sindy edited 14 Nov '15, 02:44 |
To add a view from a different site. I can access the server without problem and ping/traceroute works as well.
Regards
Kurt
Thanks so much Kurt. I sent your answer to the admin of the destination website that I couldn’t reach and he replied that someone from my IP range had been doing what appeared to be an ftp attack to break into someone’s site and that my addresses had been blacklisted. He was able to fix it and now I can now reach the site.