[TriLUG] Problems with webserver at home

[Dave Sorenson]

Another kludge is to add the internal IP of your server to the hosts 
file on each machine on your network so the request never goes out to 
the wild. This must be the internal IP, not your external IP that the 
rest of the world gets.
IE:

192.168.92.1             mywebserver.com

Has worked for me in the past.

Dave S.

Jeremy Portzer wrote:
> Roy Vestal wrote:
>   
>> Folks,
>>  I have a webserver at home running a couple of sites, one of which is 
>> running mambo. When I connect from outside my network (from work, or 
>> coffee shop, etc) works fine. When I connect from within my house, it 
>> takes 3-5 min to bring up a site. It seems the sights that have images 
>> take a little longer (which makes sense) so my mambo site takes almost 5 
>> min.
>>
>>     
>
> Do you mean that bringing up ANY Internet site, e.g. Google, Yahoo, 
> etc., is taking 3 to 5 minutes?
>
> Or only the sites that are on your local web server have the problem?
>
> I'm going to assume it's the latter, and that you're using a typical 
> home cable or DSL router device using port forwarding to connect to your 
> web server.   If so, the IP address of your web site(s) that's in DNS is 
> going to be the external IP address, e.g. the one assigned by your ISP 
> through your cable/DSL modem.  The actual IP address of the server is a 
> local IP address, in one of the private ranges such as 192.168.0.x.
>
> You will probably find that if you access your web server from within 
> the local network using the internal, 192.168.0.x address, it works 
> fine.  But when you access it with the external IP address that's issued 
> by your ISP (e.g. the one you get when you go to www.whatismyip.com), it 
> will be slow.
>
> The problem is likely that your router is so cheap, and so "dumb" that 
> it doesn't realize what its own IP address is when it forwards traffic. 
>   It just distinguishes between internal packets (192.168.0.x) and all 
> other destinations.  When you try to acess your web server via its DNS 
> name, your web server traffic is classified as external, since the IP 
> address isn't in that local private network.  Thus, your router sends 
> these packets through the NAT (network address translation) process, and 
> then transmits the packet on the external (WAN) interface - the 
> connection that goes to the cable/DSL modem.  It is too dumb to realize 
> these packets are destined for itself.
>
> Normal packets sent onto the external interface go "upstream" to your 
> ISP's router, and are then routed to their destinations over the 
> Internet.  But in your case, the ISP's router won't do anything... 
> because the destination IP is that very same interface - your router's 
> WAN interface*.   So the traffic will be received again by the very same 
> interface that it went out.  My experience has been that in these 
> situations, most of these packets will be dropped (why I'm not precisely 
> sure).  But occasionally a few do get through, bounced back to the 
> source - and that's why your site works at all.  It's very slow because 
> TCP - the transmission control protocol - will keep retransmitting until 
> the packet finally gets through.
>
> Two possible solutions:
>
> 1) Use a split-horizon DNS server.  In this situation, your router, or 
> another DNS server on your network, is specially configured to return 
> the local IP address when you do a lookup for your server's FQDN.  This 
> isn't possible with el-cheapo routers (unless you add extra software) 
> however, and requires some additional sophistication and a working 
> knowledge of DNS.  A half-assed option would be to use /etc/hosts 
> entries on your home computers to override these hostnames with the 
> local IP address.  This isn't too convenient for a laptop.  But it's 
> worth a try just to confirm this diagnosis.
>
> 2) Get a better router.  A better quality router will recognize it's 
> "own" IP address, and will not forward packets out the external 
> interface that are destined to come right back.  These packets will 
> instead be handled internally and there will be no problem.  I am pretty 
> sure the Linksys WRT54G handles this properly.  In my experience the 
> el-cheapo Netgear routers do not, but maybe the newer ones are better.
>
> Hope this helps,
> Jeremy
>
> * for simplicity I'm assuming the DSL or cable modem operates in a fully 
> bridged mode without any layer 3 activity at all.  This is not strictly 
> true, the situation is more complex, esp. if PPPoE is in use as for DSL.
>