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 184.108.40.206... 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?
Well, I don't get ping replies from that host:
:: ping ws.betaqxl.com Ping wird ausgeführt für ws.betaqxl.com [220.127.116.11] mit 32 Bytes Daten: Zeitüberschreitung der Anforderung. ... Ping-Statistik für 18.104.22.168: 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 [22.214.171.124] ü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?
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
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.