Active Directory Trust over NAT

Yeah..yeah....its not supported...but with some convoluted changes we got it to work.

First question.....why are we Natting?

We have a Cisco ASA Firewall. The firewall has multiple network interfaces. We are using addresses in the 172.16.x.x range as well as in the 10.1.x.x range. One of our clients wanted to setup a VPN tunnel between their location and a segregated server environment that I setup through VMware VSphere 4.0 at my location. I assigned this segregated network to be 172.16.1.x/24. So in theory, I would create a VPN tunnel between my firewall and their firewall and when their server (10.1.1.10) wanted to communicate with my server (172.16.1.10), the packet would route through the tunnel and vice versa and everything would be good.

However, Murphy appears to be my best friend. Those damn laws. I was able to get the tunnel established but the two tunnels could not communicate. Why? Well....because my firewall that I was establishing the VPN on had another network interface that used the 10.1.1.x/24 network as well. What was happening is that his server (10.1.1.10) would send a packet to my server (172.16.1.10) but when my server replied, it would reply to 10.1.1.10, which my firewall would try to route internally as opposed to routing back to the client....because we had the same address scheme.

The customer is using a Checkpoint firewall. Cisco ASA firewalls will not allow destination NAT translation. Checkpoint will. So what I needed him to do was to hide his servers behind an address that was not used on my firewall. We chose 10.100.1.x/24. So let's say their server was 10.1.1.10 on their network....but I had them mask this address so that to us it looked like 10.100.1.10. This was all done with NAT rules on the Checkpoint and it was done because I used the same address scheme. So we got it working and everything was great.

And then that damn Murphy showed up again.

Active Directory Trust over NAT?

So now the customer said they wanted to create a one-way trust between our Windows 2008 R2 domain and their Windows 2003 domain. Our domain would trust their domain. OK. So when I tried to set this up the my server couldn't get to their server. Why? Well...for one......using their DNS server for their domain, their servers were returning the real address of 10.1.1.10 instead of 10.100.1.10. Our servers couldn't get to the real address and thus failed. There was an error:

The secure channel (SC) query on domain controller (domaincontroller) of domain (domain) to domain (domain) failed. The RPC Server was unavailable.

After doing some research....I saw numerous posts stating that an Active Directory Trust over a NAT is not supported. Not supported is one thing...but will it work? Long story short...we got it working.

I modified the host file (C:\windows\system32\drivers\etc\hosts) on my domain controller (could've done this through DNS but this caused another issue later so I did it this way). I had them do the same. Hosts file had this:

10.100.1.10 theirdc.subdomaina.domaina.local

Then I added a line in the lmhosts file (C:\windows\system32\drivers\etc\lmhosts) like this:

10.100.1.10 theirdc #PRE #DOM:subdomaina.domaina.local

I had them do the same. BTW - I tried to use their NETBIOS name for the domain after the #DOM: but that didn't seem to work. I made other changes...so it might work using the NETBIOS name but it worked with the fully qualified domain so I was good with it.

By doing this, I was able to validate the Forest trust, however when I tried to get their accounts from their DC, nothing would be returned and I got the error: The server is not operational.

To resolve this issue, I added a Conditional Forwarders line to my DNS server on my DC for their domain using their DC IP address of the NAT'd ip address (10.100.1.10). The client did the same and once this was done, we were able to access their domain accounts and add them to our servers to give them access.

Hopefully my friend Murphy will stay away for a little while! :)