Why does my domain controller refuse to talk to a client on a different subnet?

Question

I have an office subnet (say 192.168.10.x) and a guest subnet (192.168.99.x) which both use a pfSense box as their gateway/router. The office subnet is "controlled" by Active Directory using Windows 2003 domain controllers -- the DCs give out DHCP leases, control DNS, etc. My guest subnet is controlled by pfSense.

I want a WinXP client machine that sits on the guest subnet to access Active Directory resources as if they were on the office subnet.

VPN might be a possibility, but because both subnets are controlled by the same pfSense box the routing is getting confused.

VLANs are not really a possibility.

I think I almost have this working, but I am getting stuck. Foolishly, we have file servers and even Exchange on our domain controllers, and the client can't access those resources properly.

Here's what's working:

• The client and most machines on the office subnet can communicate with each other.
• I set up the guest subnet in Active Directory Sites and Services
• The client has access to the DNS on the office subnet (which are also running on the domain controllers)
• The client can RDP into non-domain controllers on the office subnet
• I think the client can even authenticate to log in properly
• I manually added a DNS entry for the client into Active Directory's DNS

BUT the client cannot RDP into a domain controller, access Exchange, or access file shares. When I move the client to the office subnet then it can do these things.

The server event logs don't provide any clues, as far as I can tell.

The client event logs have some clues. Here is an example:

W32Time eventID 18

The time provider NtpClient failed to establish a trust relationship between this
computer and the MYDOMAIN domain in order to securely synchronize time. NtpClient 
will try again in 60 minutes. The error was: The trust relationship between this 
workstation and the primary domain failed. (0x800706FD)

If there is no trust relationship then I should not be able to authenticate, but I am pretty sure I can. (I will double-check to make sure it is not just cached credentials.)

I suspect that there is some setting on the domain controllers that make them not trust my client when it is on the remote subnet. But I am having trouble finding what it might be, or where to find documentation on this.

What am I missing?

Are there other solutions to this problem I should consider?

Solution

If the client is joined to the domain then the only thing preventing it from communicating properly would be that traffic is not being routed correctly from one subnet to the other, that the client has the wrong DNS settings, or that the firewall is blocking the required traffic from one subnet to the other.

Having the other subnet set up in ADS&S doesn't really do you any good if there isn't a DC there or there are no AD integrated services (Exchange, DFS) there.

Comments

[Paul Nijjar]

It's not just cached credentials. Group Policy updates don't work, but I can log in as a brand new user.

[joeqwerty]

I missed that point. I thought you only had one DC and that it was in the main site. If you in fact have DC's in both sites and if ADS&S is set up properly, then the client should be authenticating to the DC in it's own site. The only thing left would be to confirm that the rouer/firewall is routing and passing traffic appropriately.

[Paul Nijjar]

The client can see the proper AD DNS server. The windows firewall on the DC appears to be disabled. I am allowing all traffic on the sites. I ran Wireshark on the DC side. I can see requests (often LDAP requests) going to the DC from my client, but sometimes (not always) it looks like the DC is not responding. I think there is a pattern here, but I am not sure what it is yet. I might be getting bitten by the same bug documented here: serverfault.com/questions/190011/…

[Paul Nijjar]

Once again I got burned by routing. There were a number of issues, but the biggest one was that although my client could connect to the servers, the servers were routing traffic back through a different route. (It's a long story.) My domain controllers were the only ones that had this problem.

[joeqwerty]

Glad to hear you got it sorted out.