Both clients A and B are on the same subnet. The server is outside (a virtual server hosted by an ISP)

I have an ASP.NET application in a virtual directory on the server. In IE or firefox, if I enter http://74.208.192.xxx/subdir/subdir/../Default.aspx, it works from both the clients!
The server has default firewall settings but web server enabled (Port 80 is open).

From client A (note the different 'reply to' address when the ping succeeds.

My main problem is I have a web service (asmx) file and the web service client program is not able to access it from client B, but able to access it from client A. I am trying to find out why and thought this ping issue may shed some light.

As mentioned, the reason why your ping is successful to 74.208.192.xx:80 is because it's somehow being resolved to some other IP address, and that's the one you're actually pinging.

Since you can connect using a browser from both your clients, I'd guess the problem is not related to connectivity as such, but perhaps something with your web service client, or a firewall on the client computers interfering with it.

I'd check to see if your client (SOAP I assume) has any way of printing out diagnostic information. That might let you find out what's wrong.

You might also try loading the asmx page with your browser(s) and see what pops up, or whether you get any errors. When I load an asmx with the browser, I get an HTML page with a list of methods; see if you can get this far from both your clients.

If you want to check whether a given port is open on a given host, just use telnet aaa.bbb.ccc.ddd port, f.e. telnet 74.208.192.xxx 80.

If you try to ping something different that a plain IP address, weird things may happen, because the ping command and/or the underlying TCP/IP stack can try to resolve that string to some other address than the one you're trying to contact. As you can see, your ping command gives you this output:

Pinging 74.208.192.xx:80 [208.67.216.xxx] with 32 bytes of data:

This means it's not actually pinging the IP you asked, but a completely different one.

I had the same problem. When I did a tracert I got same request timeout. But, I was able to ping the client b from server. While doing a tracert from server to client b. I saw the FQDN(fully qualified domain name) of client b. then, I went back to client and used the same fqdn which was same in my case and replaced the ip part with my destination server ip in that fqdn. I was able to ping the server.

summary: if you are unable to ping a server, you can try pinging the server with FQDN, which resolved the problem in my case.