[ previous ] [ next ] [ threads ]
 
 From:  "Mike Razavi" <mike at havepc dot com>
 To:  "James W. McKeand" <james at mckeand dot biz>, <m0n0wall at lists dot m0n0 dot ch>
 Subject:  RE: [m0n0wall] can't access to a domain name which is hosted in my LAN
 Date:  Sun, 16 Jan 2005 17:15:34 -0800
Thanks Jim.

According to below faq the only way I can use the m0n0wall DNS forwarder
is to set my workstation's DNS to m0n0wall's ip address! Am I correct?

13.3. Why isn't it possible to access NATed services by the public IP
address from LAN?
Problem. It is not possible to access NATed services using the public
(WAN) IP address from within LAN (or an optional network). Example:
you've got a server in your LAN behind m0n0wall and added a NAT/filter
rule to allow external access to its HTTP port. While you can access it
just fine from the Internet, you cannot access http://your-external-ip/
from within your LAN.

Reason. This is due to a limitation in ipfilter/ipnat (which are used in
m0n0wall). Read the ipfilter FAQ for details. m0n0wall does not (and
probably will not) include a "bounce" utility.

Solution. If you use m0n0wall's built-in DNS forwarder for your LAN
clients, you can add one or more overrides so that they will get the
internal (LAN) IP address of your server instead of the external one,
while external clients still get the real/public IP address.




-----Original Message-----
From: James W. McKeand [mailto:james at mckeand dot biz] 
Sent: Sunday, January 16, 2005 2:33 PM
To: Mike Razavi; m0n0wall at lists dot m0n0 dot ch
Subject: RE: [m0n0wall] can't access to a domain name which is hosted in
my LAN

Mike Razavi wrote:
> Jim, after 10 hours (since I got this email) I can't figure a fix
for
> my problem. (or maybe it's not a problem!).

It may not be a "problem" but a design limitation. The LAN/NAT issue
causes problems with more than just m0n0wall. I cannot think of a NAT
implementation that does not have a problem described in this:
http://www.m0n0.ch/wall/docbook/faq-lannat.html. It may be possible to
ping the public IP (as you state later...) but higher level protocols
will not work...
 
> At this time per our earlier email I disabled one of the two NICs
and
> only have one NIC running. I also read through
> http://www.microsoft.com/serviceproviders/whitepapers/split_dns.asp
> article and did exactly what Microsoft told on this. I am 99% sure
all
> my forwarders and DNS configurations are correct.
> 
> Please see few comments below:
> 
>> When an Internet client tries to go to www.DomainA.com
>> <http://www.domaina.com/> , the name resolves to a Public IP (no
>> problem).
>
> This part always worked fine and still working beautifully.
>  
>> When a local client queries the local DNS it gets a Public IP and
you
>> cannot get there from here...
> 
> Actually no. When a local client queries the local DNS it gets my
> server's local IP address which is fine (mylocaldomain.local). But
> when a local client tries to go to www.DomainA.com
> <http://www.domaina.com/> , the name resolves to a Public IP address
> instead of server's local IP address! For some reason from the local
> network I can't pull-up the website for www.DomainA.com
> <http://www.domaina.com/>  but note that I can ping it and I get
> reply it's Public IP. 

I guess I did not state the local user scenario correctly... We are
saying the same thing using different words, let me try it again...

When a local client queries the local DNS for the public domain name
(www.domaina.com) the response is a public IP and m0n0wall will
prevent you from accessing the page, this is the classic LAN/NAT
issue...

> 
>> Two solutions come to mind. The first is only good if you have a
few
>> machines - put the private IP addresses in local clients' HOSTS
files.
>> But this gets ugly if you have more that a couple of machines...
>> 
>> The other solution is to move the Authoritative DNS (Public IPs)
for
>> public domains to a separate DNS. And use the SBS's DNS for local
>> resolution. You will still have zones for the domains you host on
the
>> SBS, but they will be non-authoritative and have Private IPs. Your
>> local clients will resolve www.DomainA.com to a private IP. And
>> Internet clients will resolve www.DomainA.com to a public IP.
> 
> Maybe this is the part that I didn't understand! Are you talking
about
> two different boxes here?

Yes, I am saying different boxes. The SBS DNS receives a query for
www.domaina.com it will respond with the IP associated with that host
record - private or public. If the authoritative DNS was on a
different box then you can use public IPs in the authoritative DNS for
queries from Internet users. The SBS DNS would respond with private
IPs for your local client's queries. Your local client machines will
never query the authoritative DNSs.

I tend to leave authoritative DNS to the registrar of the domain
(Register.com, Network Solutions, etc.) They may charge for the
service, but they have the infrastructure to maintain the machine
running the DNS. They usually provide an easy web interface to make
changes (add host records, change MX record, etc). Register.com does
not list a separate charge for "DNS Hosting" - so I guess I'm already
paying for it ;-) Network Solutions will charge for "DNS Hosting" - I
don't know how much.

I did not read the split-brain thing from Microsoft. I didn't know if
it would help or not, another poster suggested it, so I looked it up
real quick and posted a link to the Microsoft whitepaper. After a
quick scan of the document, I do not think it makes sense for what you
are tiring to accomplish.

_________________________________
James W. McKeand


---------------------------------------------------------------------
To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch