i'm trying to debug a strange problem. i'm running a home server (slack 10), just sendmail, imaps, and ssh. had it running in my old house no problem, on a home network using a wireless linksys router. i forwarded the ports i needed to the server's ip address and then i could ssh in, use thunderbird to retrieve emails via imaps, etc etc. i recently moved into a new house, and for the moment i'm using an old microsoft wireless router. i set up the same port forwarding that i had at my old place. i can go online, i've got three computers sharing one IP address, so the NAT part seems ok. i can even access the server in 2 out of 3 ways. if i'm outside my network (ie at work) i can do everything normally. if i'm inside my lan, and specify the LOCAL ip address i can do everything normally (ie ssh mcd@192.168.1.100).

BUT if i'm inside my lan, i cannot access the server at all if i refer to it by it's domain name. ssh mcd@myserver.homelinux.net does not work. it just times out. ditto for imap and smtp.

any ideas? i'm thinking it must be something to do with the router, since i didn't change anything else. are there tests i can run? some way to narrow down the problem?



ps. i don't know if this is relevant, but i used to have DSL, now i have cable.

This is normally caused by not specifying host names in /etc/hosts. The normal format would be;

192.168.1.100 <server_name>

normally myserver.homelinux.net would resolve to my public ip address (thank you dyndns.org), and requests coming in on port 25, for example, are forwarded by the router to the local ip address of my server (ie, 192.168.1.100). i thought /etc/hosts was simply to speed up name resolution on an internal network. i didn't think it had anything to do with external name resolution.

anyway, i'll put entries in when i get home tonight and see if it helps. thanks for the suggestion.

From what you say above your problem involves name resolution on the lan.

/etc/hosts will resolve to any host be it internal or external. For example if you wish to speed up connections to favourite sites then enter them in /etc/hosts file.

i don't think it has to do with DNS issues, because all my computers can resolve all other addresses just fine. i can connect to other mailservers, access webpages, etc etc. and i think i mentioned that i can access my own server from _outside_ my LAN. the only thing i cannot do is send a request through my router, have it NAT translated, and delivered back inside my LAN.

i was informed by another friend of mine that this should be default behavior on all routers (although obviously it's not). computers inside the LAN should use the local address to connect to the server, and computers outside should use the public address. they told me it's bad networking to send traffic from an internal interface to the external interface, have it translated and then routed back inside. innefficient and over-complex. so apparently my new router enforces this design decision, where my old one did not.

/shrug

they got a particular kick out of the fact that my old router (the one that allowed the improper design) was linksys, and my new router (the one that enforces proper design) is microsoft. go figure.

As far as I know the use of /etc/hosts is as follows. You entered a valid host name (whether it be a registered domain name or a local domain name) together with its ip address. If you then make a request to connect to a host listed in the hosts file the system looks up /etc/hosts to see if it is listed and if it is it uses the ip address stated in the file. If it is not listed then it will query the nearest dns server. The router should have no bearing on this as both methods use an ip address.
A good example of this is stopping linked ad servers on websites. If you list an adserver address in the /etc/hosts file and give the local host ip address (127.0.0.1) then your system does not connect to the adserver but to the local server. Since there is nothing there nothing is displayed.