Re: [users@httpd] Much More Betterer, but not quite Perfect...

[Brian Mearns <me...@gmail.com>]

On Sun, Apr 12, 2009 at 11:42 AM, E. Mail <pu...@yahoo.com> wrote:
> Hi Brian,
>
> I checked the /localhost on the server and it worked fine.
>
> I checked the server from the office machine and it worked after I set an
> HTTPD.EXE exception for the Firewall.
>
> I went to my neighbor's house and tried jrubinic.us and it timed out.  Do I
> understand it correctly in that it is a good thing that it timed out cuz
> that means the router, internet connection and firewall are all
> cooperating??
>
> I think it is good only because it did not say the page cannot be displayed
> so it is not before the server?  Since the page timed out there is something
> in the server that needs tweaked?
>
> The only thing that I can think that might be wrong is that when I looked on
> the server I had the http.conf file open in notepad.  Is that file like the
> autoexec.bat in dos in that it runs only at server startup?
>
> THANK YOU for the quick reply.  I did not expect such a good answer so
> fast.  LMAO, if Jerry Lewis had a Labor Day Telethon for Networking and
> Servers I would be the Poster Child...
>
> Any more suggestions??
>
>    Joe
>
>
> --- On Sun, 4/12/09, Brian Mearns <me...@gmail.com> wrote:
>
> From: Brian Mearns <me...@gmail.com>
> Subject: Re: [users@httpd] the usual HELP!!!
> To: users@httpd.apache.org
> Date: Sunday, April 12, 2009, 12:05 AM
>
> On Sat, Apr 11, 2009 at 7:28 PM, E. Mail <pu...@yahoo.com> wrote:
>> hi,
>>
>> this will prob be a trip down memory lane for ya...
>>
>> i downloaded and installed the Apache Webserver 2.2.11 for windows on an
>> xp
>> machine.
>>
>> i am trying to find a set of steps to follow to be able to host websites
>> from my dining room computer.   there are tons of "statements/documents"
>> for
>> how to do something, but there is no logical process to follow!!!!!!!
>>
>>  this is what i did so far:
>>
>> installed apache 2.2 on Windows XP Professional PC; 512mb ram, 80 gb sata
>> hard drive, Asus A7N8X Deluxe motherboard, Belkin F5D7001 Wireless NIC.
>> The
>> NIC works for all internet thru a linksys/cisco WRT54G2 Wireless router.
>> I
>> have not port forwarded anything yet but I do understand basically how
>> port
>> forwarding works.  I had to do it for VNC remote access and got it to
>> work.
>> The router is connected to a Broadband/Cable Modem via Time Warner Cable.
>>
>> I have a registered domain of www.jrubinic.us from godaddy.com.  Went to
>> zoneedit.com for some reason to get DNS Service (again, lotsa
>> "dots"/documentation but nothing connected yet).  I had godaddy.com
>> transfer
>> the nameserver addresses to the ones for zoneedit.com and that worked.
>>
>> I have already screwed up the Listen Directive by trying to put in an IP
>> address along with a port.  The server would not start and I remember
>> reading somewhere that it would do that if I screwed the Listen Directive
>> up.  It did.  I read some more, looked at the error log files and it told
>> me it could not "bind??" to my WAN IP address.  Since I have written
>> software before I know to only change one thing at a time then see what
>> happens.  I commented out the changed config lines and put back the
>> "Listen
>> 80" directive and the Server restarted.
>>
>> After I installed the 2.2 Apache server it said to test the install by
>> going
>> to another pc, open a browser and type in http://localhost/ .   THE BAD
>> THING IS I DON'T UNDERSTAND WHY IT WORKED.   I
>>
>
> Ok, take a deep breath. First, if you're behind a router, your WAN
> IP-address (also called your public IP) is not associated with your
> computer, its associated with your router, so you won't be able to
> bind to it. Second, unless you have multiple IP addresses associated
> with your computer, and only want to accept web connections on some of
> them, then all you need is the port number (80), not the address for
> the Listen directive.
>
> You provided a lot of info, which is good. But before anyone can
> really help you, you need to describe what behavior you're seeing. The
> first thing to test your server set up is to point your browser at
> http://localhost from the *same* computer that's running the server,
> not a different one. Not sure where you read to do that, but localhost
> resolves to the /local/ computer, not another one on your network
> (unless you really screwed around with your hosts.conf, or your DNS
> system).
>
> If you're able to view your server from the same computer, the next
> test is to connect from another system on the same LAN. To do this,
> open a command line and type ipconfig (on the server machine), this
> will show you that computer's local IP address (only accessible from
> behind the same router). Going to another computer behind the same
> router, direct the browser to http:/<server's ip address>, making the
> obvious substitution. If you're able to view the server that way, then
> you know the server is properly serving remote connections.
>
> The last step is to connect from a computer outside your LAN using the
> router's public IP address, or the domain name that you've set up to
> point to that IP address. If that works out, then you're golden. If
> not, it probably means your router is not forwarding the traffic to
> the correct machine, which is either a firewall or a port-forwarding
> issue..
>
> Note that, depending on your router and its settings, you may or may
> not be able to connect from inside your LAN using the public ip
> address or domain name. This is called loopback on the router, it
> basically means whether or not it handles internal requests to the
> public IP the same way it handles external requests. If loopback is
> enabled, then it does handle them the same way, and you should be able
> to do it. If it's not enabled, then your router probably won't do port
> forwarding for internal requests, and you'll have to connect using
> your server's internal IP address, or locally recognized name (once
> again, set up in either your hosts file, or through DNS).
>
> So give that all a try, and let us know how it goes.
>
> -Brian
>
> --
> Feel free to contact me using PGP Encryption:
> Key Id: 0x3AA70848
> Available from: http://keys.gnupg.net

Joe-

First, just some friendly advice: unless the discussion moves
off-topic or becomes personal, you should generally keep a thread on
the mailing list (by sending responses to users@httpd.apache.org, not
directly to the responder). Doing so will increase your chances of
getting more help sooner. Also, while we are a casual group of
contributors, emails written in a somewhat professional tone generally
get the best response. A quick proof-read before sending, limiting the
use of all-caps, and avoiding chat-style abbreviations/slang are all
good ideas. Like I said, we're pretty informal here, but you're more
likely to be taken seriously if it looks like you actually put some
effort into your message.

As for your problem...

It's hard to say why the connection is timing out or what that
indicates. You are right in that the fact that it did not outright
refuse the connection is promising, but it does not necessarily mean
that it's a server issue. In fact, unless you specifically did
something to provide different content or access restrictions for
requests inside the LAN versus outside, then I would guess that it's
*not* a server issue since you were able to access it from inside the
LAN without a timeout. There are other possibilities, but my guess is
that the request is not making to the httpd server. The best way to
find out is to check your server's access logs. If you have a typical
setup, then you probably have a CustomLog directive in your httpd.conf
file, which should point you to the location of this log. In general,
this log will show you at least one line for each request made to the
server, so you can monitor it for changes when you access it remotely
(e.g., from your neighbor's house). If it doesn't change, it most
likely means the request isn't making it to the server. Similarly, you
have an ErrorLog, which is worth checking as well, though it doesn't
sound like the server is encountering an error.

So assuming the request is not making it to the server, there's a
couple of possibilities. The general path for the request is going to
be: neighbor's system, neighbor's router, neighbor's ISP, your ISP,
your router, your system, your server. Your neighbor's system, and
router are both unlikely to be the culprit unless he/she had a
specific reason to block access to your IP address in the past.
Similarly with his ISP, though it's slightly more likely that they
would be filtering packets based on destination address if they've had
complaints about your address in the past (not necessarily because of
you, the IP address has most likely been assigned to a bunch of other
people before you).

That leaves your ISP, your router, and your system before reaching the
server. ISP is a distinct possibility, it's not at all uncommon for
ISP's to block port 80 (the default HTTP port) for their residential
clients so you have to buy an expensive professional account if you
want to run a website. You can check with them directly, or probably
just searching the web will tell you whether that provider in that
area is known for blocking port 80. However, usually when an ISP
blocks a port, you just plain can't connect.

Router's are somewhat less consistent about what they do with ports;
it's possible that it would keep the connection open for an extended
period of time if it doesn't know what to do with it, which would lead
to a timeout. This is particularly common on port 80 as most routers
have a built in web server for router administration, so if it's not
properly configured for remote access to this then it could be causing
a problem. But if you've forwarded port 80, and don't have any
firewall rules set up that would interfere, then it's probably not the
router, either.

Which only leaves your system and the server itself. Do you have
firewall on the system? E.g., Norton security, windows firewall,
zonealarm? Any of these could very well be causing problems.


Another possibility is that your DNS is not set up correctly. Instead
of connecting to your domain name, try typing your router's public IP
directly into the address bar in your neighbor's browser. If that
works, then it means your domain name is mapped to someone else's IP
address which is the one that's timing out.

Okay, so to summarize: first check your logs to see if the access is
getting to the server. If it is, then you're right, there's something
wrong with your server set up. (By the way, you're right, just editing
the conf file does not change the server, you need to restart the
server for the changes to take effect). If it's not, trying connecting
via your IP address instead of domain name. If that doesn't help,
check your server's Firewall and your router's setup for firewall and
port forwarding. If all that looks ok, find out if your ISP interferes
with port 80. After you do all that, get back to us (the list) with
what you found out, and someone can try to help from there.

Good luck,
-Brian

-- 
Feel free to contact me using PGP Encryption:
Key Id: 0x3AA70848
Available from: http://keys.gnupg.net

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
   "   from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org

Re: [users@httpd] Much More Betterer, but not quite Perfect...

[André Warnier <aw...@ice-sa.com>]

J. Greenlees wrote:
> Brian Mearns wrote:
> ~snip~
Let me add another tip. Apologies if it was in the previous posts and I
missed it.

Your server is part of a local LAN, which has addresses like
192.168.2.x.  Say your server is 192.168.2.100 there.

When your server gets a TCP packet containing a HTTP request, the TCP
packet contains the request of course, but also 2 IP addresses :
- the address of the sender
- the address of the receiver (your server, 192.168.2.100)

Say the address of the sender is something like "192.168.2.20" (an
internal LAN address).  When you server processes the request, it is
going to try to send back the response to the original sender.
If the sender's address is 192.168.2.20, it has no problem.  It knows
this is the local LAN of which itself is a part, and it can just drop
the response on the local ethernet wire, and the sender will get it.

However, say the sender is "110.10.20.5" (an Internet address).
Then your server also knows that this is not a local address, so it
cannot just drop this reponse onto the local LAN.
What it needs, is a "gateway".  This gateway is a system on the local
LAN, which is connected both to the local LAN (with an address like
192.168.2.x) AND to the external Internet (with the IP address given by
your ISP).
Your server, if it knows that this system exists and is a gateway, will
then "wrap" the packet for 110.10.20.5, into a packet to the local
gateway system's address (192.168.2.x), and send it on the local wire.
The gateway will receive it, notice it is a packet to be forwarded,
remove the wrapping, and send the packet out (on his external interface)
to the sender.
Who is this gateway ? it is your Internet router of course, which is the 
only one connected both to your internal LAN, and to the Internet.

Then there is the other side.
An Internet computer cannot send a request directly to your
server's internal IP address (192.168.2.100).  Instead, it must send it 
to the external IP address of your router.
(For example, right now, I see that this is 174.100.124.104).

When your router receives this packet, it must know what to do with it, 
because he is not the webserver.
So your router needs to know that if a packet comes in, addressed to
himself, but for port #80, it is not really for himself, but for your
internal server.  So it must change the receiver's IP address to be the
internal address of your server, and put the packet on the internal LAN
for your server to pick up.

This whole thing above requires a setup.
Your webserver must "know" that the router's IP address can act as a 
gateway to all the IP addresses that are not in your local LAN.
And the router must "know" that your internal server "192.168.2.100" is
the one that wants all packets for port 80.

You say that you did the router part already, for VNC.  That's good, 
because what you need to do on your router for HTTP is very much the 
same thing.  The only thing that changes is that instead of port 5900 
(VNC), you must put port 80 (HTTP). (Make this another line, do not 
change the line for VNC).

Then you have the other side, from your server to the router.
Under Windows, that is also easy.  Check your network settings, where 
you have your internal server's own IP address.
There is a place there to put the "stabdard gateway" address.  There, 
you need to enter the internal IP address of your router.

When I try to connect to your server address "http://www.jrubinic.us", I 
did not immediately get a "connection refused".  That means that 
/something/ at that address is listening to port 80.
But I do not get any answer.
Which may mean that your webserver is getting the request, but does not 
know how to send the response back.

Or that something in the middle is blocking it.
In that case, we may yet find another solution, like changing the port 
on your router.




---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
   "   from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org

Re: [users@httpd] Much More Betterer, but not quite Perfect...

["J. Greenlees" <li...@jaqui-greenlees.net>]

Brian Mearns wrote:
~snip~

> 
> As for your problem...


A useful tool that can help diagnose the issues below is shieldsup on
grc.com
a port scan that tells you what ports ( if any ) are open. since it's
coming from outside the isp it also finds blocked ports from them.

> It's hard to say why the connection is timing out or what that
> indicates. You are right in that the fact that it did not outright
> refuse the connection is promising, but it does not necessarily mean
> that it's a server issue. In fact, unless you specifically did
> something to provide different content or access restrictions for
> requests inside the LAN versus outside, then I would guess that it's
> *not* a server issue since you were able to access it from inside the
> LAN without a timeout. There are other possibilities, but my guess is
> that the request is not making to the httpd server. The best way to
> find out is to check your server's access logs. If you have a typical
> setup, then you probably have a CustomLog directive in your httpd.conf
> file, which should point you to the location of this log. In general,
> this log will show you at least one line for each request made to the
> server, so you can monitor it for changes when you access it remotely
> (e.g., from your neighbor's house). If it doesn't change, it most
> likely means the request isn't making it to the server. Similarly, you
> have an ErrorLog, which is worth checking as well, though it doesn't
> sound like the server is encountering an error.
> 
> So assuming the request is not making it to the server, there's a
> couple of possibilities. The general path for the request is going to
> be: neighbor's system, neighbor's router, neighbor's ISP, your ISP,
> your router, your system, your server. Your neighbor's system, and
> router are both unlikely to be the culprit unless he/she had a
> specific reason to block access to your IP address in the past.
> Similarly with his ISP, though it's slightly more likely that they
> would be filtering packets based on destination address if they've had
> complaints about your address in the past (not necessarily because of
> you, the IP address has most likely been assigned to a bunch of other
> people before you).
> 
> That leaves your ISP, your router, and your system before reaching the
> server. ISP is a distinct possibility, it's not at all uncommon for
> ISP's to block port 80 (the default HTTP port) for their residential
> clients so you have to buy an expensive professional account if you
> want to run a website. You can check with them directly, or probably
> just searching the web will tell you whether that provider in that
> area is known for blocking port 80. However, usually when an ISP
> blocks a port, you just plain can't connect.
> 
> Router's are somewhat less consistent about what they do with ports;
> it's possible that it would keep the connection open for an extended
> period of time if it doesn't know what to do with it, which would lead
> to a timeout. This is particularly common on port 80 as most routers
> have a built in web server for router administration, so if it's not
> properly configured for remote access to this then it could be causing
> a problem. But if you've forwarded port 80, and don't have any
> firewall rules set up that would interfere, then it's probably not the
> router, either.
> 
> Which only leaves your system and the server itself. Do you have
> firewall on the system? E.g., Norton security, windows firewall,
> zonealarm? Any of these could very well be causing problems.
> 
> 
> Another possibility is that your DNS is not set up correctly. Instead
> of connecting to your domain name, try typing your router's public IP
> directly into the address bar in your neighbor's browser. If that
> works, then it means your domain name is mapped to someone else's IP
> address which is the one that's timing out.
> 
> Okay, so to summarize: first check your logs to see if the access is
> getting to the server. If it is, then you're right, there's something
> wrong with your server set up. (By the way, you're right, just editing
> the conf file does not change the server, you need to restart the
> server for the changes to take effect). If it's not, trying connecting
> via your IP address instead of domain name. If that doesn't help,
> check your server's Firewall and your router's setup for firewall and
> port forwarding. If all that looks ok, find out if your ISP interferes
> with port 80. After you do all that, get back to us (the list) with
> what you found out, and someone can try to help from there.
> 
> Good luck,
> -Brian
> 


---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
   "   from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org