• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 2099
  • Last Modified:

Joining a remote Windows Domain that is connected via NAT'd ip addresses

I've encountered a configuration whereby the remote AD network is connected via a site-to-site IPSEC VPN tunnel.  I have full connectivity bi-directionally and have confirmed that pinging the DNS name resolves the NAT'd ip addresses via the host file.  The local host file contains entries for all the remote hosts included the AD controllers and the lmhost file has been configured with the appropriate WINs entries with the results listing the correct information.
However, since this configuration requires a NAT'd ip scheme, when the workstation queries DNS on the remote side for the SRV record for _ldap._tcp.dc._msdcs.xxxyyy.local it returns the actuall ip address which is not allowed via the VPN configuration.
I've encountered a configuration whereby the remote AD network is connected via a site-to-site IPSEC VPN tunnel.  I have full connectivity bi-directionally and have confirmed that pinging the DNS name resolves the NAT'd ip addresses via the host file.  The local host file contains entries for all the remote hosts included the AD controllers and the lmhost file has been configured with the appropriate WINs entries with the results listing the correct information.
However, since this configuration requires a NAT'd ip scheme, when the workstation queries DNS on the remote side for the SRV record for _ldap._tcp.dc._msdcs.xxxyyy.local it returns the actual ip address which is not allowed via the VPN configuration.

Is there any way to tweak the configuration so that we can join workstations when encountering this type of configuration?


Is there any way to tweak the configuration so that we can join workstations when encountering this type of configuration?

0
smadmin
Asked:
smadmin
  • 5
  • 5
1 Solution
 
NavdeepCommented:
Hi,

So is there any DC which allowed thru VPN?
0
 
NavdeepCommented:
also, can you ping the dc/gc, ldp,kerberos service records? can you resolve them as well
0
 
smadminAuthor Commented:
The PDC emulator is the AD controller allowed through the VPN.  The problem is that in order to connect from the remote network, the workstation connects to the server with a NAT'd ip (172.17.15.101) when the actual DNS resolved ips are 10.1.1.101.  So any resolutions that are queried by the workstation on the DNS service return ips that cannot be accessed via the VPN tunnel.  All connectivity is possible with the NAT'd ips and I'm hoping to find a possible workaround that allows the workstation to join the domain using the NAT'd ips.  
0
Simplify Active Directory Administration

Administration of Active Directory does not have to be hard.  Too often what should be a simple task is made more difficult than it needs to be.The solution?  Hyena from SystemTools Software.  With ease-of-use as well as powerful importing and bulk updating capabilities.

 
NavdeepCommented:
Ok, by default the nat router should be able to do dnslookup and return the address. In your case you would need to allow one particular DC's IP to pass thru router and simultaneously need to add a host entry on local machine.

I believe then this setup will work
0
 
smadminAuthor Commented:
I'm not sure I understand the nat router performing the dnslookup.  The remote workstation is set to use the AD controller for DNS queries.  Since the DNs service is only aware of the local addresses it resolves them instead of the NAT that is required to cross the VPN tunnel.  If you're referring to another method of configuring the DNS resolution I'm open to your suggestion but I don't see that as a working solution.  We don't manage the AD domain on the remote network.  Think of this a s being a remote user and having a network that conflicts (ip) with the local network.  The workstation needs to be a member of the domain but unless it can be configured with a work around the DNS service will always return the          un-NAT'd ip address of the AD controller.  
Older Windows clients could be modified (lmhost and host) to resolve Netbios names.  These modifications have been made and do not provide the appropriate work around for newer AD/workstation configurations.  If the VPN wasn't NAT'd, the DNS resolution would function the same and return the proper ip and all would be good.  The problem is specific to a NAT'd configuration and thus complicates things.
0
 
NavdeepCommented:
is there any domain controller/dns server unnatted ip address allowed throw the router ?
0
 
smadminAuthor Commented:
Due to ip conflicts, there are no unnatted ips available.  I will check and see what is in conflict and possibly configure it un-natted temporarily and join the domain.
I would like to know if that's the only option since this does occur from time to time.
0
 
NavdeepCommented:
For now this the option, to allow one DC to communicate using actual IP and put the that ip entry in localhost files so that clients queries to that dc.
0
 
smadminAuthor Commented:
Found an article on another site that lead to the solution.  
Basically the remote workstation's query to the DNS service was resolving the "internal" ip address just as it should.  The issue with a NAT'd VPN is with the ip address having been changed to an "external" address.  The trcik is to get DNS to resolve both addresses long enough for the workstation to join the domain.  By adding a secong host entry in with the NAT'd ip and making the typical host and lmhost tweaks the workstation joined the domain without error.  
Removing the second host entry does not break the solution.

See link LINK.
0
 
smadminAuthor Commented:
Resolved the issue after finding article listed in the link.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Making Bulk Changes to Active Directory

Watch this video to see how easy it is to make mass changes to Active Directory from an external text file without using complicated scripts.

  • 5
  • 5
Tackle projects and never again get stuck behind a technical roadblock.
Join Now