Jump to content



Photo

When traceroute and ping no longer work... what next?

ping traceroute path internet

  • Please log in to reply
9 replies to this topic

#1 mimform

mimform

    Neowinian

  • Joined: 18-January 14

Posted 18 January 2014 - 19:29

I have remote sites here and there and sometimes, there are problems along the way so I need to poke around and see what's going on. Is it a provider along the way? Is it is something along the network before or after the internet, etc. You get the point.

 

Problem is that more and more companies are starting to disable icmp and related tcp/udp ports so running say traceroute and others even on tcp/udp ports don't make any difference.

 

When traceroute, ping and other similar tools don't give you insight into a network because some of the providers along the path, what other tools, tricks, methods are there to test connectivity and timing from point A to B over the internet?
 

I've been searching for over a week, trying out countless tools such as tcptraceroute, mtr, alf and others but still keep getting the dreaded * * * responses.

 

Figured it's time to reach out and find a pro or two.

 

Thanks.

 




#2 +RedReddington

RedReddington

    member_id=28229

  • Joined: 14-May 03

Posted 18 January 2014 - 19:53

More and more companies are blocking ICMP??? Are they?

What type of connections do you have? I am assuming you are using VPN's. Are they managed by you?

#3 Gerowen

Gerowen

    Neowinian Senior

  • Tech Issues Solved: 2
  • Joined: 28-August 05
  • Location: Hills of Kentucky
  • OS: Ubuntu Linux

Posted 18 January 2014 - 20:00

I use Zenmap (A GUI for nmap) occasionally for scanning devices on a network to see what ports are listening, but using it assumes that you can see the device you are wanting to scan.



#4 MillionVoltss

MillionVoltss

    Neowinian Senior

  • Tech Issues Solved: 1
  • Joined: 21-May 04

Posted 18 January 2014 - 20:34

( Has no networking skills ) Can you do the ping from the Client in a shell or something to yours ?



#5 +RedReddington

RedReddington

    member_id=28229

  • Joined: 14-May 03

Posted 19 January 2014 - 10:32

I could understand maybe at a push ICMP (ping) been disabled but does your traceroute show all ***. post some examples and maybe a diagram of your setup.

#6 The_Decryptor

The_Decryptor

    STEAL THE DECLARATION OF INDEPENDENCE

  • Tech Issues Solved: 5
  • Joined: 28-September 02
  • Location: Sol System
  • OS: iSymbian 9.2 SP24.8 Mars Bar

Posted 19 January 2014 - 10:34

MTR? pathping?

A hop along the way blocking ICMP or such shouldn't break the entire route, and tools like that should still work in that situation.

#7 sc302

sc302

    Neowinian Senior

  • Tech Issues Solved: 35
  • Joined: 12-July 05
  • Location: NJ, USA

Posted 21 January 2014 - 00:17

If you control the end points you enable for testing. You need to be able to test basic communications. if you heave business class firewalls you will be able to look at the logs to see what is hiring your firewall.

#8 OP mimform

mimform

    Neowinian

  • Joined: 18-January 14

Posted 22 January 2014 - 18:44

Thanks for all of the replies.

 

No, I don't control all of the points, only A to B but I need to see what is down in between them.

 

No, I don't only see * * *, so no, it doesn't break the entire route. Just saying that too often, when providers disable ICMP and assosicated tcp/udp ports, then there is little to go on because the tracetroute ends.

 

Yes, I use juniper SSG series firewalls and yes, I do see the logging but that doesn't help much since I can't see the full path from point A to B when something in between is down.

 

No, I can't use scans because that typically makes providers somewhat nervous, even if they are logged and reported. Our own devices do the same thing but if I see too many scans, I start wondering why.

 

Yes, I do have the remotes ping back to us when we have problems but no one can get any better traceroute when those services are diabled.

 

My question is really not about ping or traceroute but what other options might be available when these tools become useless.



#9 sc302

sc302

    Neowinian Senior

  • Tech Issues Solved: 35
  • Joined: 12-July 05
  • Location: NJ, USA

Posted 22 January 2014 - 20:54

Calling the site, if they have a vpn with a split tunnel, do they continue to have internet access?  If they don't have a vpn with a split tunnel, do they have an internet facing port on their firewall?  Can you enable ssl or https administration for that site and use another site (possibly a computer at home that is possibly on a different network entirely) to try to administrate it. 

 

basically, if you can't hit it from work and you can't hit it from home there are serious issues to work on which are usually out of your control once setup properly.  If it is all internal, then there are internal network issues that you have to work with. 

 

Short of really pinging each site from a site that exists outside of your network, calling the provider to assist with troubleshooting, being able to remote into each site, tracerouteing, there really isn't much else you can do as far as basic troubleshooting...you don't own everything between you and them so hard to get a good read on it...generally though if they have disabled icmp and you have a good trace route from one site to the other you can guage pretty well when a site is down and around where it is dying....you need to know how many hops it takes for a normal trace to hit your site.  You can pretty much guage when it is your site having issues or when someone else is if it stops responding after 2 hops for example when it normally takes 30, but if it dies on 30 you know it is your end.  it isn't exactly rocket science, if it makes sense and you have previously tested before you can guage pretty well what is going on.



#10 OP mimform

mimform

    Neowinian

  • Joined: 18-January 14

Posted 28 January 2014 - 19:53

Thank you very much for all of the info. It is helpful and I will note that there aren't any other tools which may not be well known.