[TriLUG] Problems with webserver at home

[Jeremy Portzer]

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.