httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: [users@httpd] Much More Betterer, but not quite Perfect...
Date Mon, 13 Apr 2009 14:09:40 GMT
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 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,

Say the address of the sender is something like "" (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, 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 "" (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, 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 (  Instead, it must send it 
to the external IP address of your router.
(For example, right now, I see that this is

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 "" 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 "", 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:> for more info.
To unsubscribe, e-mail:
   "   from the digest:
For additional commands, e-mail:

View raw message