0

Maybe it's a dumb question, so please bear with me as I am novice to networking. While trying to debug a connection problem to a server today I observed the following two things -

I am able to ssh (port 22) on the target server successfully However, when I run tracert , then I am getting 'request timed out' result. Does it makes sense? I mean, if I am able to ssh using a FQDN I should be able to tracert (trace route version of windows) as well, is that right? What am I missing here?

Please let me know if I need to give more details.

3 Answers 3

2

I am able to ssh (port 22) on the target server successfully However, when I run tracert , then I am getting 'request timed out' result. Does it makes sense? I mean, if I am able to ssh using a FQDN I should be able to tracert (trace route version of windows) as well, is that right? What am I missing here?

It makes perfect sense. If the server (and any firewalls in front of the server) allow SSH traffic inbound to the server but prohibit ICMP traffic inbound to the server then your results are exactly what I'd expect to get. I'm not saying that's definitively the case here, but it sure sounds like it.

3

traceroute or tracert in Windows is almost always the wrong tool to use to debug any kind of application, specifically the most known ones, like all based on TCP, with their default settings.

This is because they use by default UDP and/or ICMP packets to trace the path by progressively incrementing the TTL of the packet and expecting each intermediary node hit by a packet reaching a TTL of 0 to reply with an ICMP packet with its own IP address as source, so that it gets detected, and finally for the whole path to be discovered.

This, nowadays, more often breaks than works, and even if it does work the results (specifically the time to answer and the drop percentage) will be almost meaningless and always uncorrelated to the real protocol you wish to debug, like TCP port 22 in your case, for ssh.

Because most networks filter ICMP packets (and often wrongly based on some old attacks that are now myths) and typically route UDP differently than TCP and with different priorities applied.

So the path seen by default can be entirely different, including not available at all, from what the application real traffic would look like.

Hence, I recommend to never use this tool like that (and for the same reason, not ping either). On the contrary any modern one can be passed parameters, like -T --port=22 (sometimes just tcptraceroute $host 22), to force it to use TCP packets, on the specific port you need, 22 for ssh. By doing so you, you will observe exactly what happens when you open your ssh connection (some networks may even apply some filtering for this case, by "detecting" traceroute traffic that is slightly different than normal one, especially if you also do DPI, but this is less often the case than ICMP filtering or different paths/priorities for UDP and TCP).

2
  • very useful comments. What do you mean by this -'On the contrary any modern one can be passed parameters', what modern ones are you referring here? Mar 7, 2018 at 5:46
  • @ShibasisSengupta Modern versions of the traceroute tool. And I do not know what tracert accepts as arguments. But on Unix you can do traceroute -T Mar 7, 2018 at 6:24
0

Just to add to the comment re modern tools, you can look at specific tools which use TCP instead of ICMP:

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .