upcomltd
asked on
How do I find out where an https request gets blocked?
Hi all,
We have a nasty problem from one of our servers:
- HTTPS traffic to a server in a remote datacenter is blocked from a specific server in our datacenter
- same URL works without a problem from all other servers in the same datacenter
- PING, TRACEROUTE and MRT all stop somewhere in the remote datacenter
Our datacenter admins say that the problem is on the remote datacenter, while the remote datacenter says that there are no blocking rules for that IP!
We are stack! I need a way to prove both where the problem is, so I can force them to fix it! Is there a tool out there that can trace the HTTPS (or other to a specific port) and let me know on which server it really stops? Server runs on CentOS 5.4, if that can make any difference. No firewall or other networking blocking software is on that server - at least for the moment!
Thank you in advance
Kostas
We have a nasty problem from one of our servers:
- HTTPS traffic to a server in a remote datacenter is blocked from a specific server in our datacenter
- same URL works without a problem from all other servers in the same datacenter
- PING, TRACEROUTE and MRT all stop somewhere in the remote datacenter
Our datacenter admins say that the problem is on the remote datacenter, while the remote datacenter says that there are no blocking rules for that IP!
We are stack! I need a way to prove both where the problem is, so I can force them to fix it! Is there a tool out there that can trace the HTTPS (or other to a specific port) and let me know on which server it really stops? Server runs on CentOS 5.4, if that can make any difference. No firewall or other networking blocking software is on that server - at least for the moment!
Thank you in advance
Kostas
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thank you all for your comments!
We have done all that. the ping does not respond, because it is not enabled on the server - blocked. Traceroute stops after a while, some router in between blocks the ping process..
The nslookup returns the correct information about the server, so there is no DNS problem. We also tried with the IP directly.
Doing telnet on the 443 we are blocked for a long period of time and then get a timeout.
I'm sure somewhere in the route, one of the servers blocks the traffic - possibly only HTTPS. The question is how do I find out which one! Doing telnet on all 443 on all intermediate servers is not a solution - possibly none of them listens to this port.
I was thinking of a way at a very low level to be able to say that the packet arrived till that server, but then bounced back! Is that possible without contacting the admins of all those servers (impossible in reality)?
Thanks in advance
Kostas
We have done all that. the ping does not respond, because it is not enabled on the server - blocked. Traceroute stops after a while, some router in between blocks the ping process..
The nslookup returns the correct information about the server, so there is no DNS problem. We also tried with the IP directly.
Doing telnet on the 443 we are blocked for a long period of time and then get a timeout.
I'm sure somewhere in the route, one of the servers blocks the traffic - possibly only HTTPS. The question is how do I find out which one! Doing telnet on all 443 on all intermediate servers is not a solution - possibly none of them listens to this port.
I was thinking of a way at a very low level to be able to say that the packet arrived till that server, but then bounced back! Is that possible without contacting the admins of all those servers (impossible in reality)?
Thanks in advance
Kostas
Telnet does not work on ports that don't use a text interface. Port 443 with SSL/TLS has to negotiate a secure connection first and as far as I know, you can't do that with telnet, at least not by itself.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
@jackiechen858
Exactly same route. From the one it responds with Connected to ..., from the other one is blocked :-(
Thanks for your efforts.
Exactly same route. From the one it responds with Connected to ..., from the other one is blocked :-(
Thanks for your efforts.
what update in your problem??
Do all your server has real INTERNET IP or just private IP? If they have private IP, when they go out to internet, the remote server should see them as same INTERNET ip, so it should treat them as same.
If they have real different internet ip, or you have some private network between the remote data center and local datacenter, so the remote server will see your servers with different source IP, then it might be blocked by some bad network rules.
I remember I met a weird problem, some traffic was blocked by our ISP, turned it it only block "certain IP", like a special/weird ip address ( with some .0. or something) , still legal address, but a wrong wrote rule could block even the admin didn't realize it.
If they have real different internet ip, or you have some private network between the remote data center and local datacenter, so the remote server will see your servers with different source IP, then it might be blocked by some bad network rules.
I remember I met a weird problem, some traffic was blocked by our ISP, turned it it only block "certain IP", like a special/weird ip address ( with some .0. or something) , still legal address, but a wrong wrote rule could block even the admin didn't realize it.
ASKER
@jackiechen858
No, all are real IP addresses, accessible from the internet. From that server (with the problem) we can access every other server we connect to.
No, all are real IP addresses, accessible from the internet. From that server (with the problem) we can access every other server we connect to.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
I'm closing this question as there is no real answer to the question raised. Almost everybody provided ways in that direction, but it seems there is no way to identify the blocking party.
http://wiki.centos.org/HowTos/Network/IPTables