Misc 20 Comments February 24, 2013

TCP Traceroute

Did you know you could traceroute over the TCP protocol?

The regular traceroute usually uses either ICMP or UDP protocols. Unfortunately firewalls and routers often block the ICMP protocol completely or disallow the ICMP echo requests (ping requests), and/or block various UDP ports.

However you'd rarely have firewalls and routers drop TCP protocol on port 80 because it's the web's port.

Check this out. Let's try to traceroute www.microsoft.com using ICMP protocol:

# traceroute -I www.microsoft.com  
traceroute to www.microsoft.com (65.55.57.27), 30 hops max, 60 byte packets
 1  50.57.125.2 (50.57.125.2)  0.552 ms  0.647 ms  0.742 ms
 2  core1-aggr701a-3.ord1.rackspace.net (184.106.126.50)  0.415 ms  0.555 ms  0.653 ms
 3  corea.ord1.rackspace.net (184.106.126.128)  0.707 ms  0.873 ms  0.984 ms
 4  bbr1.ord1.rackspace.net (184.106.126.147)  1.345 ms  1.341 ms  1.337 ms
 5  * * *
 6  204.152.140.33 (204.152.140.33)  3.614 ms  3.747 ms  3.244 ms
 7  xe-0-2-0-0.ch1-96c-2b.ntwk.msn.net (207.46.46.49)  3.319 ms  4.019 ms  4.010 ms
 8  ge-7-0-0-0.co1-64c-1a.ntwk.msn.net (207.46.40.94)  53.543 ms  53.105 ms  53.074 ms
 9  xe-5-2-0-0.co1-96c-1b.ntwk.msn.net (207.46.40.165)  52.942 ms  52.710 ms  52.670 ms
10  * * *
11  * * *
12  * * *
13  * * *

We get lots of * * * and we've no idea how the packets reach www.microsoft.com.

Now let's try UDP traceroute:

# traceroute -U www.microsoft.com
traceroute to www.microsoft.com (65.55.57.27), 30 hops max, 60 byte packets
 1  50.57.125.2 (50.57.125.2)  0.529 ms  0.599 ms  0.662 ms
 2  core1-aggr701a-3.ord1.rackspace.net (184.106.126.50)  0.480 ms  0.571 ms  0.658 ms
 3  corea.ord1.rackspace.net (184.106.126.128)  0.507 ms corea.ord1.rackspace.net (184.106.126.124)  0.463 ms  0.569 ms
 4  bbr1.ord1.rackspace.net (184.106.126.145)  1.345 ms  1.322 ms  1.290 ms
 5  * * *
 6  * 204.152.140.35 (204.152.140.35)  2.697 ms *
 7  xe-0-2-0-0.ch1-96c-2b.ntwk.msn.net (207.46.46.49)  3.665 ms ge-7-0-0-0.co1-64c-1a.ntwk.msn.net (207.46.40.94)  53.363 ms  52.597 ms
 8  xe-3-1-0-0.co1-96c-1b.ntwk.msn.net (207.46.33.190)  52.284 ms  52.643 ms xe-0-1-0-0.co1-96c-1a.ntwk.msn.net (207.46.33.177)  52.665 ms
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *

Same. Finally let's try traceroute over TCP protocol port 80:

# traceroute -T -p 80 www.microsoft.com
traceroute to www.microsoft.com (65.55.57.27), 30 hops max, 60 byte packets
 1  50.57.125.2 (50.57.125.2)  0.540 ms  0.629 ms  0.709 ms
 2  core1-aggr701a-3.ord1.rackspace.net (184.106.126.50)  0.486 ms  0.604 ms  0.691 ms
 3  corea.ord1.rackspace.net (184.106.126.128)  0.511 ms corea.ord1.rackspace.net (184.106.126.124)  0.564 ms  0.810 ms
 4  bbr1.ord1.rackspace.net (184.106.126.147)  1.339 ms  1.310 ms bbr1.ord1.rackspace.net (184.106.126.145)  1.307 ms
 5  chi-8075.msn.net (206.223.119.27)  3.619 ms  2.560 ms  2.528 ms
 6  * 204.152.140.35 (204.152.140.35)  3.640 ms *
 7  ge-7-0-0-0.co1-64c-1a.ntwk.msn.net (207.46.40.94)  52.523 ms xe-0-2-0-0.ch1-96c-2b.ntwk.msn.net (207.46.46.49)  3.825 ms xe-1-2-0-0.ch1-96c-2b.ntwk.msn.net (207.46.46.53)  3.355 ms
 8  xe-0-1-0-0.co1-96c-1a.ntwk.msn.net (207.46.33.177)  61.042 ms  61.032 ms  60.457 ms
 9  * * xe-5-2-0-0.co1-96c-1b.ntwk.msn.net (207.46.40.165)  100.069 ms
10  65.55.57.27 (65.55.57.27)  53.868 ms  53.038 ms  52.097 ms

A full network path to www.microsoft.com!

There are various different traceroute implementations and if your system doesn't have one that supports tcp protocol, I suggest you either get the new modern implementation of traceroute, or get the tcptraceroute by Michael Toren.

Comments

February 24, 2013, 19:30

To be honest, it doesn't really matter that traceroute got TCP support, even more if happened recently, because tcptraceroute is there for a long long time already (over 10 years actually). How much widely-known this tool is, is the other thing, though, and surely not as much as the first one.

February 24, 2013, 20:11

Hi. Great post. We follow your work!

mtr is a pretty good command that comes from traceroute but gives more stats about the packets using the ping command.

Just try: mtr microsoft.com

bob Permalink
February 25, 2013, 01:09

%traceroute -T -p 80 www.microsoft.com

Fails with usage() on the bleeding edge -CURRENT. What are you talking about?

February 25, 2013, 02:04

There are various traceroute implementations. Here's the one on my Arch Linux machine that has -T:

$ traceroute --version
Modern traceroute for Linux, version 2.0.14, Jan 15 2011
Copyright (c) 2008  Dmitry Butskoy,   License: GPL v2 or any later

And my other machine that runs Slackware 12.2 doesn't have the -T flag:

$ traceroute --version
Version 1.4a12
Usage: traceroute [-dFIlnrvx] [-g gateway] [-i iface] [-f first_ttl]
        [-m max_ttl] [ -p port] [-q nqueries] [-s src_addr] [-t tos]
        [-w waittime] [-z pausemsecs] host [packetlen]

I updated the post with this information.

February 25, 2013, 13:38

On my Mac this fails too:

$ traceroute -T -p 80 www.microsoft.com
Version 1.4a12+Darwin
Usage: traceroute [-adDeFInrSvx] [-A as_server] [-f first_ttl] [-g gateway] [-i iface]
	[-M first_ttl] [-m max_ttl] [-p port] [-P proto] [-q nqueries] [-s src_addr]
	[-t tos] [-w waittime] [-z pausemsecs] host [packetlen]

But a short look at the man page says:

     -P proto
             Send packets of specified IP protocol. The currently supported protocols are: UDP , TCP , GRE and ICMP Other protocols may also be specified (either by name or by number),
             though traceroute does not implement any special knowledge of their packet formats. This option is useful for determining which router along a path may be blocking packets
             based on IP protocol number. But see BUGS below.

In the BUGS section it says that the functionality for RST on the TCP stream is not implemented. I don't know how critical that is to the functionality.

Nevertheless, the Mac equivalent to yours above would be this:

traceroute -P TCP -p 80 microsoft.com
February 25, 2013, 03:20

This really isnt applicable because, for one, there is policy based routes. That means, an ICMP can be routed literally different than an TCP request on port 80 solely based on the fact that the request came in on port 80.

Tim Permalink
February 25, 2013, 04:43

Well.. that's a good thing. If you're trying to find out the path to a web server because you've having trouble making tcp/80 connections you want to be directed the same, not somewhere else because of policy.

Same could be said for any other tcp service.

February 25, 2013, 05:53

In my case, I am trying to do a tcp traceroute to google.com and I see many more * * * than I saw while using ICMP. This confirms that not all routers will reply to the TCP syn packets.

Steve Permalink
February 25, 2013, 21:34

Be aware that tcp traceroute will make some IDSes light up like christmas trees. I offered a web-based TCP traceroute a few years back, and heard from several security folks over it.

Sure P Permalink
June 12, 2013, 11:40

Good post, thanks for sharing this.

July 09, 2013, 04:44

Thanks for the information. I will have to look into them for my own needs and check out your blog.

July 09, 2013, 15:52

all topics and visuals and understands are absolutely distinct & meaningfully. This is not only amusement & topic.
Really it is very useful post & I like to read these types of post & thanks for sharing such type of posts…
http://www.swagsgalore.com/draperies.html

July 11, 2013, 03:14

Really a Great Post..I enjoy a lot..This will give the many informative ideas of the post..Thanks for the nice post..Keep Sharing..

July 14, 2013, 18:25

Thanks for sharing information

John Permalink
July 23, 2013, 06:26

Thanks for the great info. Credit Report Hub They are very helpful.

macy Permalink
October 20, 2013, 01:58

Excellent article. hermes handbags.

pablo Permalink
October 23, 2013, 21:06

This is a good article. However, the effectiveness of the method describe depends on wether or not the network (firewall) devices in the path are allowing returning ICMP messages sent back to you. It doesn't really matter if the tcp packet on port 80 is making it through if you can't receive the "TTL exceeded in transit" ICMP message from a network hop.

Tim Permalink
March 18, 2014, 12:32

This post is misleading if you read the man page

-p port
Protocol specific. For UDP and TCP, sets the base port number used in probes (default is 33434). traceroute hopes that nothing is
listening on UDP ports base to base+nhops-1 at the destination host (so an ICMP PORT_UNREACHABLE message will be returned to termi-
nate the route tracing). If something is listening on a port in the default range, this option can be used to pick an unused port
range.

Keyword, base port number, it does not try to connect on port 80 but just uses it as the base port to start incrementing

March 19, 2014, 15:13

If you still encounter ports that are blocked or filtered (proxy?) or lack of a machine that has traceroute on it to test with, you could use an online version like this on:

http://www.letmecheck.it/tcptraceroute.php

I have to agree with Tim on the source/destionation port discussion, if you use tcptracroute: http://linux.die.net/man/1/tcptraceroute

With extended traceroute, the man page clearly specifies the destination port to be set: http://linux.die.net/man/8/traceroute
This would make sense from a firewall point of view, as most do destination port filtering, not source port filtering.

April 14, 2014, 07:09

So nice presented and maybe inspire that work

Leave a new comment

(why do I need your e-mail?)

(Your twitter name, if you have one. (I'm @pkrumins, btw.))

Type the first letter of your name: (just to make sure you're a human)

Please preview the comment before submitting to make sure it's OK.

Advertisements