say I've got a few systems which forward ports to one another all over the place, and somewhere along the line a port forward fails. I want to trace the route of a connection on a specific port to see where the connection hits a wall, to see what system is causing the problem.

any way to do this?

I've tried `tracetoure -T -p <port>` but it doesn't output anything about the ports it hits, stops when it hits the address I supplied even though it is forwarded elsewhere, and there doesn't seem to be a verbose mode.

interstingly, if I specify a different source port via the '-s' option, the trace keeps hopping to * * * * and never get anywhere (at least to 27 hops then I CTRL+C)

I've never used tracetoure, however you can use traceproto with the destination port option and it should provide the information you need.

thanks. however the traces from both tcptraceroute and traceproto (tcp) both just get no response, which is weird. there is definitely a port forwarded to a service on another machine, an http server, and I can load it in a browser.

the machine I'm traceing is also got a local sshd running and working well, and tcp'ing to that port also results in no response with these tools.

er? why?

I"m even doing these from within the same network, so no NAT is happening.

-T = Use TCP instead of UDP packets when probing the route.

-p port = Specifies the UDP destination port base traceroute will use.

I don't think you know:
1. what are you doing
2. why you are doing this
3. what do you exactly need.

So please read carefully "man traceroute" .

no, sir, I think YOU don't understand what I'm trying to do. I need to know what system is accepting (or traveling through) my TCP (hence -T) connection on port 443 (hence -p). it would seem logical that -p would use TCP instead of UDP with the -T option. that is, after all, the point.

I may be wrong, but isn't tcptraceroute what you need ?

The -p of traceroute isn't about testing ports. Tcptraceroute sends
TCP SYN packets to a specific port so it can do what you want.

It's possible one of the redirects in the chain isn't a network level redirect and is a webserver perm redirect or something similar.