2

I am able to load the website's homepage from a web browser, but pinging it from the command line is resulting in 100% loss from multiple machines.

I apologize if this is out of scope. Point me in the right direction and I'll take my question elsewhere.

The traceroute looks as follows (by random, I mean I don't recognize them):

Hop (ms)    (ms)    (ms)             IP Address Host name
1     3       0       0          __random.ip__   __random.host.net__  
2     4       0       0          __random.ip__   __random.host.net__  
3     0       0       0          __random.ip__   __random.host.net__  
4     20      20      20         __random.ip__   __random.host.net__  
5     20      20      21         __random.ip__   __random.host.net__  
6     28      28      28         __random.ip__   __random.host.net__  
7     32      32      31         __random.ip__   __random.host.net__  
8     Timed out       Timed out       Timed out               -  
9     Timed out       Timed out       Timed out               -  
10    Timed out       Timed out       Timed out               -  
11    Timed out       Timed out       Timed out               -
Nick Pickering
  • 3,095
  • 3
  • 29
  • 50
  • When you say "live on the internet", what exactly do you mean? Do you mean "I am able to load the website's homepage from a web browser"? – Andy Lester Dec 16 '12 at 05:44
  • 1
    Are you hosting on a virtual server with a direct ip? Or are you part of a shared host? Does your network have some restrictions that may be blocking the received packets? – Matt Clark Dec 16 '12 at 05:44
  • @Andy Yes. Is there another definition for "live"? – Nick Pickering Dec 16 '12 at 05:48
  • @Matt The site is hosted on a dedicated server, I don't believe the network would be blocking the packets... why would it be? – Nick Pickering Dec 16 '12 at 05:48
  • Have you tried a `traceroute` to see where the connection fails? – bobthyasian Dec 16 '12 at 05:48
  • @NicholasPickering: When you say "on the internet", you're being inexact. Email is "on the internet". FTP is "on the internet". World of Warcraft is "on the internet". In fact, your pings that aren't being returned are being transmitted on the Internet. – Andy Lester Dec 16 '12 at 05:51
  • @Andy, I've updated the question details. Personally, I think the fact that it's a website being live puts everything in the right context but I can also see the ambiguity. – Nick Pickering Dec 16 '12 at 05:54
  • I ran a traceroute but I don't know how to decipher it. It jumps to different hostnames and stops dead about 7 hosts down. I don't recognize any of these hostnames as ones I work with regularly. – Nick Pickering Dec 16 '12 at 05:55
  • @NicholasPickering right- those are the routers along the way. See my answer and comments below. What kind of server is this? Windows? Linux? Do you have shell access? – Jonathon Reinhart Dec 16 '12 at 06:01
  • @JonathonReinhart It's a windows server. I have RDP access. – Nick Pickering Dec 16 '12 at 06:04

1 Answers1

4

ping is a utility which sends an ICMP "echo request" message to a machine, who, if it is supported and enabled, will reply back with the same packet that was sent to it.

The website is being served by a webserver listening on TCP port 80.

These are two totally different services, and one, both, or neither could be enabled on any machine.

What you are probably seeing is that the machine you are connecting to has a webserver running, but has ICMP requests disabled. Also, any number of firewalls could exist between you and this box, any of which could be filtering out ICMP traffic.

In fact, recent versions of Windows disable ICMP ECHO in the default firewall rules. It has to be explicitly enabled.

Jonathon Reinhart
  • 132,704
  • 33
  • 254
  • 328
  • So, there is really no connection between a ping and a web server's availability? What is the reason for disabling ICMP ECHO by default? – Nick Pickering Dec 16 '12 at 06:13
  • 2
    Exactly. They are unrelated. Some consider it a security improvement. Some network scanners will first try to ping a host to see if it is up, before trying to scan for open ports / vulnerabilities. So if it's not responding to pings, it may not get scanned. It's basically an opt-in instead of opt-out firewall mentality. "Block everything, and only enable something if it is required." – Jonathon Reinhart Dec 16 '12 at 06:20
  • 1
    Since this is a windows server, I would bet that ICMP ECHO is disabled in the Windows firewall. Which is why you can't ping it. If you really need to be able to ping the server over the internet, you could enable this. But I don't see the point. – Jonathon Reinhart Dec 16 '12 at 06:22
  • I would bet you are right as well. It was a habit within our company to ping a site to test if the server was up and running, not sure how this became a practice if they aren't really connected. It is not necessary to ping it. We recently upgraded servers, and I didn't make the connection between this and the move. Thanks for walking me through that @Jonathon. – Nick Pickering Dec 16 '12 at 06:29
  • 1
    I mean, pinging a machine is historically the method for determining if it was "alive" and connected to the network. Generally speaking, a ping is a much simpler test than an HTTP request (with ICMP being part of the OS network stack, instead of a webserver which is a separate process, requiring configuration, etc.), so it would be a "hmm, is it turned on? ping it!" kind of test. But with these relatively new firewall restrictions, it's not a 100% indicator of a server being "alive." – Jonathon Reinhart Dec 16 '12 at 06:36