Determining cause of TCP/IP connect issue without traceroute

Solution 1:

If your network admins are blocking ICMP (which is done for the wrong reasons wherever it is done), there is hardly anything you can do. No matter what kind of protocol you use for the probing packets (Windows tracert.exe uses ICMP, Windows , Linux traceroute uses UDP by default and TCP if you ask for it), if ICMP as a protocol is generally filtered (especially if ICMP responses generated by foreign hosts are filtered as well), you can't ever get meaningful results back to your machine for diagnosis - as these always will come back as ICMP packets.

Solution 2:

You said traceroute is disabled on router. I thing it can only filter ICMP packets, so you could use traceroute with TCP.

sudo traceroute -T <host>

Solution 3:

You say that you know the host is up - how did you verify that? If you can access the host on any other port at all, the routing is setup correctly. If your company is blocking icmp internally so that you cannot even verify that the traffic is heading out the internet, have the network guys verify that for you and ask them why they are blocking requests and replies (they should only block specific types when paranoid) on internal routers in the first place. Other than that, you would have to ask the remote party to see if they can see your source IP at all in their logs. That would also indicate the problem is on their end. Though, none of these are things you can really do completely on your own.

Solution 4:

Use the hping2 tool which can do TCP traceroute

hping2 www.somehost.com -p 443 --traceroute