5

I'm trying to connect from a company network to a host (via HTTPS), but my attempts fail with timeout. I can resolve the host. I know the host is up. I know there is a firewall filtering by incoming IP number protecting the remote host. Traceroute is disabled on some router in my company network, so I cannot see till where my packets go. I know that my packets are stuck somewhere along the route. It might be (I think) a bad route in our company network; or a misconfigured firewall blocking me on the remote host (while it was supposed to grant me access). (Turned out to be the latter.)

Without traceroute, is there any technical way I can determine whether the misconfiguration preventing a connect is in our company network, or on the remote host? (Assuming the Internet inbetween is reliable.)

Full story and original post on SuperUser.com, which may not have been the most suitable place to ask this question.

Community
  • 1
Lumi
  • 199

4 Answers4

3

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>
csgwro
  • 61
  • 6
3

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.

Community
  • 1
the-wabbit
  • 41,352
2

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.

Paul Ackerman
  • 2,715
1

Use the hping2 tool which can do TCP traceroute

hping2 www.somehost.com -p 443 --traceroute
Benny
  • 181