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
  • 177
  • 2
  • 8

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
  • 5
  • Windows `tracert` doesn't allow you to use TCP, so I checked from a virtual Linux on my computer. Using `traceroute -T` has the same outcome as using UDP, or as using `tracert` on Windows. See @syneticon-dj's answer for why this is so. Thanks anyway for `-T`, I didn't know about that. – Lumi Dec 07 '11 at 10:46
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
  • 40,319
  • 13
  • 105
  • 169
  • Thanks. I do and did get `ping` replies, but no `tracert` replies. Before the other party granted my IP number access to their server I did *not* get `ping` replies. Now that they've granted my IP number access I do. In hindsight it's always easier. Thanks again! – Lumi Dec 07 '11 at 11:04
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,729
  • 15
  • 23
  • I know the host is up and was up because when repeating the question here on Serverfault (but not yet when asking it on Superuser) I already knew the problem had been the other party's failure to admit traffic from our IP, which they were saying they were doing. Before they admitted traffic from our IP I couldn't get any sort of access to the host. And because of ICMP being blocked by our network guy I wasn't sure of the reason. Thanks for the useful advice. – Lumi Dec 07 '11 at 10:43
1

Use the hping2 tool which can do TCP traceroute

hping2 www.somehost.com -p 443 --traceroute
Benny
  • 181
  • 1
  • 7
  • In the scenario we're talking about here (ICMP blocked), neither TCP nor UDP will work. See @syneticon-dj's answer for why this is so. Thanks anyway. – Lumi Jan 23 '12 at 17:48
  • As I can see you have two problems restricting your traceroute attempt: 1. Server side firewall which filters by IP address 2. Your company's routers not supporting Traceroute. A TCP traceroute will send out TCP Syn packets with reducing TTL values. Any intermediate hop which processes a packet with TTL Zero must notify the sender using ICMP type 11 message as per RFC 1812. Assuming that there are no firewalls between those intermediate hops and your system you "should" receive the intermediate hops IP address and trace the path. Only caveat is when your company's firewalls are blocking ICMP – Benny Jan 24 '12 at 05:28
  • I would assume it is not the case since most company firewall's permit inbound ICMP replies (in order to support troubleshooting). This method will work inspite of both your restrictions since the path is traced even before hitting the end firewall and it does not query using ICMP (which might be blocked), only response is using ICMP. Definitely worth a try! – Benny Jan 24 '12 at 05:32
  • Looking at your original question in Superuser, looks like your access to that site needs to go via non-default route. So you want to make sure whether the problem is in the routing or destination firewall. It is more reliable to go for TCP traceroute because we don't know whether your net admin implemented static routes or policy routing for this scenario. If it is policy routing, ICMP packets will take a different route compared to packets destined for port 443. All the more reasons to go for TCP traceroute. If hping doesn't work use nmap `sudo nmap www.xxx.com -p443 --traceroute` – Benny Jan 24 '12 at 05:49
  • Benny, thanks for your comments. Inbound ICMP is blocked indeed. (Due to inability to configure some Cisco hardware, including by a Cisco consultant. So not on purpose.) Our network admin configured a static route correctly. The failure was on the other side: they said they'd granted our IP number access through their firewall, but they actually hadn't. Without ICMP/traceroute I didn't know how to assess where the problem was. Looks like it's not possible without ICMP. Now access has been granted. The `nmap --traceroute` shows two hops only. How is it better than just `curl`? – Lumi Jan 24 '12 at 09:50
  • 1
    curl output would just say if the page is accessible or not. Nmap traceroute on the other hand would report on response from every hop on the way. Since you can see two hops, there is atleast one node located before the firewall (or whichever network gear that is dropping ICMP) which can send ICMP back to you. Looking at it's IP address you can determine whether it is closer to your network or the destination network (I suspect former). If the access doesn't work nmap output will show only one hop. Curl output would merely say "connection failed" – Benny Jan 24 '12 at 12:43