Mike Razavi wrote:
> Jim, after 10 hours (since I got this email) I can't figure a fix
> 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
> only have one NIC running. I also read through
> article and did exactly what Microsoft told on this. I am 99% sure
> 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
> This part always worked fine and still working beautifully.
>> When a local client queries the local DNS it gets a Public IP and
>> 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
>> Two solutions come to mind. The first is only good if you have a
>> machines - put the private IP addresses in local clients' HOSTS
>> But this gets ugly if you have more that a couple of machines...
>> The other solution is to move the Authoritative DNS (Public IPs)
>> 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
>> 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
> 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