I'm trying to determine where connectivity to an external host using a specific TCP port is being blocked. Traceroute for Windows only uses ICMP, and telnet will only tell me that the port is blocked and not where. Does anyone know of a Windows utility similar to traceroute that will achieve this?

  • It is so weird that the question was closed with "It's difficult to tell what is being asked here." while so many people correctly understood what was asked for - a tool with functionality similar to Traceroute for Linux with options traceroute -T -p port_number --- linux.die.net/man/8/traceroute Jun 7 at 10:36

7 Answers 7


You can use nmap 5.0 with --traceroute option. You will also get a portscan for free :).

If you want to test a specific port, you can use -p port option. (You should also use -Pn option so that nmap doesn't try to do a regular ICMP probe first). This is an example:

$ sudo nmap -Pn --traceroute -p 8000 destination.com
8000/tcp open  http-alt

TRACEROUTE (using port 443/tcp)
1   0.30 origin.com (
2   0.26
3   0.42
4   1.00 gateway1.com (
5   2.18 gateway2.com (
6   ...
7   1.96 gateway3.com (
8   ...
9   8.28 destination.com (

If you're interested in a graphical tool, you can use zenmap, which also displays topology maps based on traceroute output.

topology maps

  • 3
    When I run the above command on my nmap it actually does an ICMP traceroute. Also weird, you specify port 8000, but nmap is using port 443 for the actual traceroute. Why?
    – kojiro
    May 29, 2014 at 18:54

Scapy has a tcp trace route function described in this Scapy tutorial. Scapy can be installed on Windows, here are the instructions. I am not positive that his function is available in the Windows version, but it might be.

It will help to know python, or at least some knowledge of OO (Object Oriented) programing, but you might not need it just to follow the tutorial I linked to. Scapy also assumes you have basic understanding of the OSI model I think.

  • note: Scapy traceroute function is available on Windows.
    – Maxwell
    May 11, 2012 at 8:59

I'm not sure if nmap --traceroute will work properly on Windows due to Windows ignoring requests for non-standard TTLs. I just get an oddly-shaped two-hop path to something that's about 10-20 hops away:

c:\Program Files (x86)\Nmap>nmap -Pn --traceroute -p 443

Starting Nmap 6.01 ( http://nmap.org ) at 2012-08-27 18:52 GMT Daylight Time
Nmap scan report for live.sagepay.com (
Host is up (0.21s latency).
443/tcp open  https

TRACEROUTE (using port 443/tcp)
1   31.00 ms
2   62.00 ms

I'll post back if I find something fit for purpose that hasn't already been mentioned.

  • A sniffer should tell you what's happening. My guess is that some intermediate router/gateway tries to be a smart-aleck and handles the packets in an unusual way. Jul 3, 2014 at 13:27

You can find a number of links googleing.

A Linux implementation on traceroute being able to use TCP protocol and having replaced the old implementation on many distros. Simple use the -T flag on those systems.

On Mac -P TCP does the job.

Historically a number of ad hoc tools were developed; among the other references there is a simple python script that can be used also specifing the port one needs to probe: tcptraceroute.py while one of the most popular is tcptraceroute by Michael Toren.

  • 1
    The Wikipedia page has been deleted. Mar 19, 2013 at 7:32
  • The link to tcptraceroute by Michael Toren is dead
    – Tanner
    Nov 3, 2015 at 15:00

There are a couple of Windows alternatives to the UNIX favourite LFT.

Unfortunately neither of those that spring to mind are free. But they are pretty good.

Unfortunately, if you are using WinXP SP2~, then you may have trouble performing any TCP tracerouting. This is due to the removal of raw socket support.


Try NETSCAN http://www.softperfect.com/products/networkscanner It does more that just scan one device, you can get it to check a range of IP address and ports and it is free.


I'm not aware of any traceroute tool for windows which lets you define the port. The ICMP protocol is designed for this sort of route diagnosis; other protocols are not. It's likely that, if the host itself if not refusing the connection, somewhere along the route is a firewall which simply drops the packets without returning any other information to the source, in which case no utility would work for your situation.

You could try firing up Wireshark, and then telnetting on your desired port to the target system. You might (but probably will not) get a TCP_RESET or DEST_UNREACH or something back from whatever firewall is blocking communications, but this is unlikely. Ultimately, you need to talk to the network people who can trace the route and look at rulesets of firewalls along the way.

Good luck.

Not the answer you're looking for? Browse other questions tagged or ask your own question.