Determining cause of TCP/IP connect issue

Question

I need HTTPS access to the host ws.betaqxl.com, but connect fails:

:: curl -k -v https://ws.betaqxl.com
* About to connect() to ws.betaqxl.com port 443 (#0)
*   Trying 91.204.81.183... Timed out
* couldn't connect to host
* Closing connection #0
curl: (7) couldn't connect to host

Two things to note:

• Access to that host for our IP number has to be granted in their firewall.
• Our packets to that host have to be routed out of our net via a non-default interface (a static as opposed to a dynamic IP number), which is configured to the IP number that the other party is supposed to have granted access to.

There are, I think, two likely reasons why this could fail:

• I'm blocked by their firewall; despite their statements to the contrary, access hasn't been granted yet.
• Our static route for that particular host is bad and routes my requests into nirvana.

So human error either here or there.

What next to determine the cause of the problem? Let's try ping and tracert. Well, I don't get ping replies from that host:

:: ping ws.betaqxl.com
Ping wird ausgeführt für ws.betaqxl.com [91.204.81.183] mit 32 Bytes Daten:
Zeitüberschreitung der Anforderung.
...
Ping-Statistik für 91.204.81.183:
    Pakete: Gesendet = 4, Empfangen = 0, Verloren = 4
    (100% Verlust),

In other words, timeout, 100% package loss. ICMP being blocked by their firewall would certainly explain that.

First question, would a bad route also explain that?

I think (but am far from sure) that a traceroute would allow me to see till which point packets are going. Unfortunately, some component in our company network denies traceroute packages, so:

tracert ws.betaqxl.com

Routenverfolgung zu ws.betaqxl.com [91.204.81.183] über maximal 30 Abschnitte:

  1     *        *        *     Zeitüberschreitung der Anforderung.
  ...

In other words, timeout, no reply.

Second question: Would a traceroute going beyond the DECIX (Frankfurt), which I can get from home but not from the office, prove that the packets are routed correctly out of our company network?

Third question: Are there likely reasons other than the two listed above why this might fail? Stupid oversight of mine not to be excluded ... but the hostname and the whole URL are definitely correct, and the curl and ping and tracert tools are generally reliable.

Fourth and last question: Barring the obvious non-technical steps (asking our IT and their IT to verify the configuration, already done that), what else could I do on a technical level to determine the cause of this failure?

Sorry for asking four questions in one, but I think you can see that for a non-expert in network things, they're all related to the same problem.

Answer 1

The answer to this question is on ServerFault.com. In a nutshell, with ICMP blocked and hence no traceroute packets returning to you, "there is hardly anything you can do" (quoting syneticon-dj's answer), which in practice translates to: there's nothing you can do on a technical level because your diagnostic tools have been blocked.