[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: JR in need of mentoring...



Thank you!  that answers my question exactly!  I didn't know that PING and
TRACEROUTE were red herrings.  I just didn't know how to prove my firewall
was blocking a port or a service.

Thank you all, again...
-Jason

On Fri, 17 Oct 2008 17:57:38 -0500, Scott Klement <sk@xxxxxxxxxxxxxxxx>
wrote:
> Hi Jason,
> 
>> Yes I can, I was able to ping/traceroute google.com and webservicex.net
>> with no lost packets or failed hops.
> 
> Here's what we know for sure:   HTTPAPI is attempting to establish a TCP
> connection.  It has sent the connection request, and is waiting for a
> response.  When it doesn't receive a response within 60 seconds (or
> whatever you set the timeout to) it gives up and reports 'time out.'
> 
> So what can cause that?   Theoretically, there are many things that can
> cause this "no response" symptom.  In fact, virtually any sort of
> misconfiguration could cause a "no response".   A Broken cable.  A bad
> hub/switch, a bad router, a misconfiguration of the routing table, or
> perhaps the most obvious thing...  the network is too slow to respond
> within 60 seconds to the request.
> 
> But we can rule most of these possibilities out off the bat!
> 
> a) It can't be a broken cable, or PING/TRACEROUTE wouldn't work.
> b) It can't be a bad hub/switch or PING/TRACEROUTE wouldn't work.
> c) It can't be a bad router, because PING/TRACEROUTE wouldn't work.
> d) It can't be a misconfiguration because PING/TRACEROUTE wouldn't work.
> e) It can't be too slow of a network, because you'd see that with
> PING/TRACEROUTE as well.
> 
> So what could it be?   It's almost as if there's some sort of mysterious
> device that's blocking HTTP, but isn't blocking PING/TRACEROUTE.
> Imagine it!  Some sort of device that could be configured to allow
> CERTAIN traffic in an out of a network, but still block UNWANTED traffic
> in and out of the same network.
> 
> Well, guess what?  That's what a firewall does.   When you configure a
> firewall, you tell it what to block and what not to block.
> 
> The fact that PING/TRACEROUTE work does NOT tell you that your firewall
> will let HTTP requests through.  Instead, it tells you that your
> firewall will let PING (ICMP messages) and traceroute (both ICMP
> messages and UDP messages on ports 33434 - 33500) through.
> 
> HTTP is NOT ICMP or UDP.  It's TCP on port 80 (or SSL on 443) though
> sometimes people use non-standard ports.
> 
> The point is... you have NOT tested whether your network allows these
> things through, and PING and TRACEROUTE tell you nothing about that.
> 
> If you honestly believe that HTTPAPI is the problem (which seems a
> little unlikely since it works for many people) then you might try
> typing the following, since that DOES test TCP on port 80:
> 
> TELNET RMTSYS(www.google.com) PORT(80)
> 
> The "PORT(80)" is critical.
> 
> If TCP PORT 80 is getting past your firewall, then the response will be
> "TELNET session ended.  Connection closed."  or you MAY get a blank
> screen...
> 
> If a firewall is blocking it, you'll get:
> No response from remote host system within open time-out.
> 
> -----------------------------------------------------------------------
> This is the FTPAPI mailing list.  To unsubscribe, please go to:
> http://www.scottklement.com/mailman/listinfo/ftpapi
> -----------------------------------------------------------------------

-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------