troubleshooting - Determining cause of TCP/IP connect issue
2014-04
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.
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.
Possible Duplicate:
Mac OS X traceroute not even reaching router gateway
I am on M1 Cable (residential) broadband in Singapore.
I have an intermittent problem routing to some sites from my MacBook Pro—often Google-related sites (arduino.googlecode.com and ajax.googleapis.com right now, but sometimes even gmail.com.) This prevents StackExchange chat from working, for instance. Funny thing is, my iPad can route to those sites and they're on the same wireless network! I can ping the sites, but not traceroute to them which I find odd.
That I can get through via the iPad implies the problem is with the MBP. In any case, calling M1 support is... not helpful.
I get the same behaviour when I bypass the Airport Express entirely and plug the MBP directly into the cable modem. Can anybody explain a) how this is even possible and b) how to fix it?
mella:~ ratkins$ ping ajax.googleapis.com
PING googleapis.l.google.com (209.85.132.95): 56 data bytes
64 bytes from 209.85.132.95: icmp_seq=0 ttl=50 time=11.488 ms
64 bytes from 209.85.132.95: icmp_seq=1 ttl=53 time=13.012 ms
64 bytes from 209.85.132.95: icmp_seq=2 ttl=53 time=13.048 ms
^C
--- googleapis.l.google.com ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 11.488/12.516/13.048/0.727 ms
mella:~ ratkins$ traceroute ajax.googleapis.com
traceroute to googleapis.l.google.com (209.85.132.95), 64 hops max, 52 byte packets
traceroute: sendto: No route to host
1 traceroute: wrote googleapis.l.google.com 52 chars, ret=-1
*traceroute: sendto: No route to host
traceroute: wrote googleapis.l.google.com 52 chars, ret=-1
^C
mella:~ ratkins$
The traceroute from the iPad goes (and I'm copying this by hand):
10.0.1.1
119.56.34.1
172.20.8.222
172.31.253.11
202.65.245.1
202.65.245.142
209.85.243.156
72.14.233.145
209.85.132.82
From the MBP, I can't traceroute to any of the IPs from 172.20.8.222
onwards.
Firstly, the traceroute: sendto: No route to host
message is your primary clue. Your MacBook Pro's network configuration isn't fully functional. Perhaps the MacBook is configured with some static settings that overide the settings that are obtainable by DHCP from your cable broadband modem or router?
Secondly MacBooks and iPads run different operating systems. It is possible that this has some bearing on the problem. Either in the way these devices pick up wireless settings or in the way tracert/traceroute work (normally they use ICMP protocol but some variants use TCP - it is possible that ICMP is blocked at some router/firewall)
On the Macbook Pro, can you get it to display it's network settings - chiefly default gateway and DNS servers? E.g. ifconfig -a
If you can see the equivalent informatio on the iPad - look for differences.
Turns out this was the answer (tl;dr, nuke Peerguardian from orbit.)