Any IT Pros in here?

Status
Not open for further replies.
Joined
Jan 18, 2009
Messages
1,081
Location
oklahoma
Having an issue establishing a domain trust...one side is NAT'd IP address. I think this is a DNS issue; need experts.

thx & let me know
 
WWILLSON can help or the member OVERK1LL, he is a network engineer and a really good guy. (not that Willson isn't)
grin2.gif
 
Two domains in different forests...need to setup a 2-way trust so that users in domain-A can authenticate off the AD in domain-B.

I have connectivity and the other engineer says that all necessary ports are open on his firewall, but unfortunately we both have a 192.168.0.x range in use. So he setup NAT so that I would see him as a different IP range to avoid conflicts.

I have tried Forwarder entry to his DC, I tried FLZ (both stub & primary), and now I am down to a simple hosts file entry. I can now tracert him fine and see the traffic go into the Cisco VPN concentrator and on itsway accross a TLAN to his gateway. IT makes it there...So I am connected. But in the windows domains & trusts admin console it always tells me that a DC for his domain cannot be located or something.

I have found others with same issue and it has been said that NAT just doesn't work well with trusts...but unfortunately I can't change my class C range and neither can he.

anyone?
 
1. His DNS server on the server you are trying to authenticate to MUST have the IP address you are seeing over the VPN and trying to connect to, set as an address for that server. I would hope this address has been set as static.

2. Your DNS server should have the same entry.

Essentially, since you are using an alternative IP to attempt to circumvent the issue of you both using the same subnet, you need to tell the DNS servers (which I assume are on the DC's themselves, so I didn't include it as a separate step) that there is an additional IP used for the DC to listen on and consider valid.

Also, I would assume you have his DNS server set as a forwarder (you might have mentioned this, but I didn't bother to look up and make sure) for your DNS server and vice-versa.
 
Last edited by a moderator:
YEah I was thinking he needs to do something with his DNS...I had already tried creating a primary FLZ and manually creating records with one using the FQDN of his DNS/DC and the nat IP address, but I think the issue is his internal DNS? Is that kinda what you mean?

I do not even need to browse him or nothing...just add users from his AD into security groups in my AD so they can use a web-based application.
 
Last edited:
35.gif
See I knew OVERK1LL could help, and I don't have a clue what they are talking about, but here watching the posts anyways!


LOL.gif
 
Originally Posted By: FastSUV
YEah I was thinking he needs to do something with his DNS...I had already tried creating a primary FLZ and manually creating records with one using the FQDN of his DNS/DC and the nat IP address, but I think the issue is his internal DNS? Is that kinda what you mean?

I do not even need to browse him or nothing...just add users from his AD into security groups in my AD so they can use a web-based application.


OK, but did you add his DNS server as a forwarder for yours? And remember, he needs to do the same. His server needs to be able to respond to requests on the NAT'd address. It (DNS server, again, assuming the DNS server is on the same box) needs to know that its host name maps to that IP. This has been my experience anyways. I have numerous VPN's I run, though none with this exact issue, that have servers sharing data over the tunnels and having the DNS setup correctly; so that each DNS server is aware of the other DNS servers, typically solves or prevents these types of issues.
 
Last edited by a moderator:
I really appreciate the replies so far. Although I am an admin, I am a "jack of all trades" and master of NONE and I have limited exp in DNS. I can tell you that I tried adding his NAT IP for his DC/DNS server (same box) as a forwarder on my DC/DNS server. I also tried a forward lookup zone too. It is my understanding if you have one you do not NEED the other. But again, when those did not work, I resorted to a host file entry. If I remember correctly, before I edited my host file on my DC/DNS server, when I tried to resolve his FQDN of that server, it returned the non-NAT internal private IP of his server. Forgive me, it is late & I am tired but I am thinking you are saying he needs to make a reverse lookup for the NAT range on his side? I know in all the discussions so far the other guy & I agree we think it is a DNS issue since the firewall is configured per Microsoft's rec from a KB article on trusts, and we have connectivity and can ping each other fine. But I did say something about he might need to make a DNS entry to allow traffic trying to go to that host to account for the NAT range but I think he said it would cause him some internal resolution issues.

I can tell you that I have the EXACT same scenario with a different domain trust and it works fine because the other domain is not using nat'd IP's...Blaahhh

We will continue to hash it out tomorrow, but most of my exp is in app testing & deployment and I am venturing into newer territory so it is a learning process. The other dude seems to know more than I do about routing, switching, AD, DNS, etc. but to no avail so far on this project.

And it is a little more complex than I (entity A)described in that I am going though a TLAN to Entity B via the VPN concentrator, and then it is setup to hop out of my tunnel with Entity B (they have a like Cisco box for the VPN) and then jump into a second tunnel between Entity B & Entity C (which is who I wish to setup the trust with). As far as I can tell it is working though because I have connectivity so I still think it is DNS.
 
This type of thing motivated me to ditch MS servers in favor of Debian servers with hardware VPNs. Getting inside the DNS in a MS box is brave stuff. Hope you solve it without breaking something else.
 
http://support.microsoft.com/default.aspx?scid=kb;EN-US;263293


http://support.microsoft.com/kb/154596

” Even though you can configure the port used by the client to communicate with the server, the client must be able to reach the server by its actual IP address. You cannot use DCOM through firewalls that do address translation (e.g. where a client connects to virtual address 198.252.145.1, which the firewall maps transparently to the server's actual address of, say, 192.100.81.101). This is because DCOM stores raw IP addresses in the interface marshaling packets and if the client cannot connect to the address specified in the packet, it will not work.”


Looks like it is a no-go situation
 
Last edited:
Unfortunately, the scenario depicted in that setup has the two servers on different subnets and the proposal is routing between them. Which makes sense. You don't have that option because you are dealing with the same subnet, and if you route them, you are going to have IP conflicts unless your clients are DHCP and there are few enough of them that you can allocate one side to half the range, the other side to the other half. And assuming none of the server IP's overlap.....
 
yeah looks like the trust is off...I have propsed a secure website to host the application instead...we shall see what the word is. The problem is that I have many other entities needing this access so trust is not a good solution because multiple places have IP conflicts
50.gif
 
Status
Not open for further replies.
Back
Top