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` --- https://linux.die.net/man/8/traceroute – pabouk - Ukraine stay strong Jun 07 '22 at 10:36
7 Answers
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
PORT STATE SERVICE
8000/tcp open http-alt
TRACEROUTE (using port 443/tcp)
HOP RTT ADDRESS
1 0.30 origin.com (192.168.100.1)
2 0.26 10.3.0.4
3 0.42 10.1.1.253
4 1.00 gateway1.com (33.33.33.33)
5 2.18 gateway2.com (66.66.66.66)
6 ...
7 1.96 gateway3.com (99.99.99.99)
8 ...
9 8.28 destination.com (111.111.111.111)
If you're interested in a graphical tool, you can use zenmap, which also displays topology maps based on traceroute output.
-
3When 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 '14 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.
- 82,107
- 71
- 302
- 444
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 66.98.200.8
Starting Nmap 6.01 ( http://nmap.org ) at 2012-08-27 18:52 GMT Daylight Time
Nmap scan report for live.sagepay.com (195.170.169.9)
Host is up (0.21s latency).
PORT STATE SERVICE
443/tcp open https
TRACEROUTE (using port 443/tcp)
HOP RTT ADDRESS
1 31.00 ms 192.168.192.2
2 62.00 ms 66.98.200.8
I'll post back if I find something fit for purpose that hasn't already been mentioned.
- 624
- 1
- 7
- 18
-
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. – ivan_pozdeev Jul 03 '14 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.
- 10,871
- 7
- 38
- 52
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.
- 25,189
- 5
- 52
- 70
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.
- 116
- 3
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.
- 5,358
- 1
- 23
- 36