Re: AD/DNS with NAT
- From: "Phillip Windell" <philwindell@xxxxxxxxxxx>
- Date: Thu, 24 Apr 2008 14:56:36 -0500
Ok, I've got a little more time to look at this and think about it. The
phone was ringing and people were wanting right in the middle of my last
post.
I can tell you up front you I will be suggesting changes to your existing
"working" setup, even if you don't think there is anything wrong with it, if
I don't think it is optimal or suitable to add the extra functionality you
want.
I'll insert comments "along the way",...Continued...
"AnthonyE" <aeychenne@xxxxxxx> wrote in message
news:b1347c7a-9749-4b39-ab14-6923d11dba81@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
------------------------------------------
CONTEXT:
Today, his entire network is based on a private range (10.x.x.x). Two
Datacenters host servers as Domain Controllers AD2003, DNS, Exchange
and other services for the whole company.
Users are separated in one big headquarter and 58 small offices.
Each small office hosts a member server for DHCP, DNS caching, file
sharing etc? The users on these small offices are authenticating
directly to one of the 4 domain controllers located in the
Datacenters. All sites (HQ, Datacenters and small offices) are
interconnected by a MPLS network.
-------------------------------------------
Ok. I need to know the real details of the 10.x.x.x. I cannot troubleshoot
or "plan" things with x's. I need a list, or at least a partial list of the
sites with the Net ID they use and how they are connected (VPN, Private
Leased Line, etc), and the Network relationship to the other sites and HQ
(routed or NATed) so that I can have some kind or "map" to work from.
Then...before you even begin...you current existing system needs to be:
1. There should be a DC at each location (required for AD Sites).
2. Each location needs to be a different subnet (required for AD Sites)
3. Each location needs to be in a "routed" relationship to the other
locations (required for AD Sites)
4.You need to make use of Active Directory Sites Objects in order to regular
the AD Replication over the WAN links. This means there will be at least
one DC within each AD Site Object
-------------------------------------------
But here we go: this company is part of a larger group and is
requested to be part of the WAN network of the Group to connect their
small offices to the Datacenters, in order to save cost, gain speed
and increase security.
-------------------------------------------
Ok. "How" they get connected is the key.
-------------------------------------------
This means changing IP ranges ; the small
offices will be migrated to the new range but the headquarter is too
complicated to migrate so they will keep their private IP range
(10x.x.x.x) and NAT will be used
-------------------------------------------
I see no reason at all to change IP Ranges.
None at all.
-------------------------------------------
For info, we will try to recommend to the client to add Firewalls at
every small offices to use NAT in order to keep the private IP range
on each site but due to the cost of 58 FW?s, this will be probably
-------------------------------------------
Forget Firewalls and forget NAT. Answering "How" they are going to be
connected will clarify how to deal with this.
-------------------------------------------
PROBLEM:
In this new situation, we know that business services like telnet,
Intranet (web) won?t have any issue working through that NAT
environment. But, our concerns are about the DNS / Active Directory
infrastructure now ?hidden? behind the NAT.
-------------------------------------------
You can't use NAT.
-------------------------------------------
All the servers in the Datacenters will have a corresponding and
unique ?external address? on the new WAN cloud, and known by the
firewall for IP translation. But how services like DNS and AD will
react behind the NAT?
-------------------------------------------
They won't work with NAT involved. Even if someone suggests some
"convoluted" way of involving NAT (and there probably is some convoluted way
out there somewhere) I just won't go along with it. In that case they will
just have to take over and I will drop out. I am only interested in doing
things the correct, dependable, solid, flexable, scaleable, and
straight-forward way that will actually work the way it is supposed to when
you are finished.
Anyway,...combined with the 4 points I mentioned above at the beginning as a
foundation,...this is what I have in mind:
1. I am assuming for the moment that the sites are connected by Site-to-Site
VPNs with dedicated VPN Devices or existing Firewalls that are capable of
doing so. But if it is private leased Lines it is still handled the same
way for the most part.
2. For Sites that are in the same Windows Domain you place a DC of that
Domain at each site. The DC will be part of that AD Site Object which is
determined by the Subnet. All DCs within a Forest (even with multiple
domains) are already "aware" of each other's contents via the AD Replication
that is handled by the AD Sites Object.
3. For Sites that are not part of the same Windows Domain you would have to
set up a Zone Transfer between the Site's DC and a DC for the Domain(s) so
that the DNS naming works properly accross sites.
4. Local user's machines all use their own local DNS for their DNS and none
other (that's critical). The local DCs then has their own ISP's DNS listed
in the Forewarder's List in the DNS MMC on thier local DNS.
5. Routing. Sites of only one subnet will not have a LAN Router so the VPN
Device will fulfill that Role. If the VPN Device is also the Firewall then
the Firewall will fulfill that Role. So whatever fulfills that Role has to
be the Default Gateway of all the local LAN's machines,...this device then
needs to be smart enough to know what to do with traffic destined for the
other Sites and also needs to know what to do with Internet traffic. If the
role is handled all by a single Firewall/VPN device that should be almost
automatic. If you dealing with multiple devices then it is not all that
hard but it would difficult for me to explain it without knowing all the
details of what is going on,...I can't do it with a "blindfold" on.
6. Security/Access Controls. Access Control is handled by the central VPN
Device (or Router when using leased Lines). The HQ will be the logical
"center",..like a hub-spoke model, and will control what traffic can pass
between Sites and between the Sites and the HQ itself. Each Site can also
do some of the same things for their own individual location by using their
own VPN Device in the same manner if they want,...but if they do it is up to
them to do it right.
People are wanting me again,...I gotta go..
--
Phillip Windell
www.wandtv.com
The views expressed, are my own and not those of my employer, or Microsoft,
or anyone else associated with me, including my cats.
-----------------------------------------------------
.
- References:
- AD/DNS with NAT
- From: AnthonyE
- AD/DNS with NAT
- Prev by Date: Re: AD/DNS with NAT
- Next by Date: Re: AD/DNS with NAT
- Previous by thread: Re: AD/DNS with NAT
- Next by thread: Re: AD/DNS with NAT
- Index(es):
Relevant Pages
|