On Thu, 2004-05-27 at 21:15, Steven Buehler wrote:
> I have a rather strange connectivity issue going on.
>
> First off, from the cable modem (RoadRunner) i have a VoIP telephone
> adapter connected, using address 192.168.15.1, then a Netgear router at
> 192.168.15.2, which does NAT to a desktop and laptop (192.168.0.2 and .3,
> respectively). .3 is a server running mail and web service.
>
> Here's the strange problem. I can go in from outside and reach ports 25
> and 80 just fine. However, if I attempt from my desktop or laptop to
> telnet to the server ports using the hostname or 24.x.x.x address, the
> connection either times out or is flat-out refused.
>
> Any ideas?
To clarify:
You're trying to reach the server residing on the local subnet but are
refused? Desktop and laptop are at 192.168.0.1 and x.x.x.2. The server
is at x.x.x.3.
First things:
Who manages your DNS? If you're doing this on the .3 server you should
probably configure views so that that external requests get a different
view of your network than internal requests. For example:
view "internal" {
match-clients {localnets; };
recursion yes;
zone "." {
type hint;
file "root.hints";
};
zone "0.0.127.in-addr.arpa" {
type master;
file "pz/127.0.0";
};
zone "0.168.192.in-addr.arpa" {
type master;
notify no;
file "pz/192.168.8";
};
zone "sanctuaryweb.org" {
type master;
notify yes;
file "pz/db.sanctuaryweb.org_internal";
};
};
view "external" {
match-clients {any; };
recursion no;
zone "." {
type hint;
file "root.hints";
};
zone "sanctuaryweb.org" {
type master;
notify yes;
file "pz/sanctuaryweb.org";
};
};
Your corresponding zone files will list 192.168.0.x addresses for the
internal side and the 24.x.x.x addresses for the external side. What
does this do? For one, it makes internal requests to the mail and web
server go directly through the LAN because the name resolution will
return 192.168.0.3. In your case you're most likely going through the
router to get back to your LAN. The router is likely dis-allowing this
sort of traffic (or maybe doesn't know how to handle it). You can
verify if this is the case by telneting to the 192.168.0.3 address.
Next, check that you don't have any IPCHAINS rulesets that are blocking
LAN requests. This is very unlikely unless you've configured them
specifically as such.
-----------------------------------------------------------------------
This list is provided as an unmoderated internet service by Networked
Knowledge Systems (NKS). Views and opinions expressed in messages
posted are those of the author and do not necessarily reflect the
official policy or position of NKS or any of its employees.
This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 19:08:23 EDT