Unable to query LDAP server on port 389 on the Win2K domain controller from a different subnet

Question

I have a rather puzzling problem with the LDAP access to Active Directory in a Windows domain. The configuration is as follows:

• There are two main networks: 192.168.0.0/24 and 192.168.100.0/24
• These networks are connected with an OpenVPN link (the transfer network is 192.168.201.0/30)
• A domain controller running Windows 2000 SP3 Server and Exchange 2000 in the 192.168.0.0/24 network
• Appropriate routing
• Both subnets registered with the site in the Sites and Services Snap-In

Almost everything works: users from the machines in both networks can log in, access SMB shares on file servers in the 192.168.0.0/24 network, use Outlook with their Exchange Account and so on. Also, all DNS queries, including the AD specific SRV records (e.g. _ldap._tcp.dc._msdcs.$DOMAINNAME), point to the correct places

There is no firewall on the OpenVPN link.

Now the problem: I cannot query the DC LDAP server (NTDS, port 389) from any computer in the 192.168.100.0/24 network. Interestingly, LDAP queries on the Global Catalog (port 3268 on the same server) work perfectly. I do even get a connection to port 389, but it gets reset immediately by the server.

There are no suspicious entries in the Directory Service Event Log (LDAP interface), even with the maximum possible log level.

Here the example output from LDP tool trying to connect to the DC at 192.168.0.1:

0x0 = ldap_unbind(ld);
ld = ldap_open("192.168.0.1", 389);
Established connection to 192.168.0.1.
Retrieving base DSA information...
Server error: <empty>
Error<94>: ldap_parse_result failed: No result present in message
Getting 0 entries:

Everything I found on the Web says the same two things, basically: "check the DNS" and "check the firewall". Well, I double- and triple-checked both the DNS and IP routing/filtering, and it seems to be fine.

Do you have any further ideas where to look and what to check? I'd appreciate any answer. If you need further diagnostic output, I'd be happy to provide it.

Update

Thanks to adamo's answer, I've been able to narrow the problem further down. The problem is that all traffic to 192.168.0.0/24 network on port 389 somehow gets mangled by the machine OpenVPN is running on. This happens regardless of which target machine I am trying to connect to on port 389/tcp, and even regardless of whether the target machine is actually listening on port 389. Any other port (for example, 390) works fine, and I get either a connection or a "connection refused" message if no process is listening on that port.

Port 389/udp works fine, either.

What can cause a Windows 2000 server to mangle the traffic in this very selective way?

Update 2

To minimize the interactions between the DC/NTDS services and the OpenVPN, I moved the OpenVPN server to another machine (and changed the IP routing accordingly). Now I am able to connect to any machine except the DC on the port 389/tcp. Nevertheless, if I try to connect to the LDAP server on the DC on port 389/tcp from the 192.168.100.0/24 network, the LDAP server closes the connection immediately, so basically I am back to square one.

Any ideas how to persuade the NTDS to talk to another network? Or maybe some workaround?

Solution 1

3 questions:

1. Can you query port 389/tcp from a computer on the same LAN with the LDAP server?
2. Is the OpenVPN server the "firewall" between those lans, or does a third gateway exist? What are the operating systems for these devices?
3. On the LAN where the LDAP server sits can you setup a machine and run a netcat listener on port 389/tcp ? If so, does the connection reset immediately or not?

Solution 2

ms ldap has an issue that results in immediate resets to new connections on tcp 389

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

Comments

[PHGamer]

Keine Ergebnisse in der Meldung vorhanden Im guessing thats German. What does that error translate to?

[Igor Podolskiy]

Sorry, I forgot to replace the German sentence, thanks for pointing that out. I edited the question and fixed it.

[Igor Podolskiy]

1. Yes, all machines on the 192.168.0.0/24 network can query the LDAP server on the DC without problems. 2. The OpenVPN server runs on the same machine as the DC, the OpenVPN client is a pfSense/FreeBSD box. 3. I'll try to do that and post the answer shortly.

[adamo]

Could it be a problem on the OpenVPN client's pf configuration? Like having to place a "keep state" rule for connections that are initiated by the client? Is there something that treats ports < 1024 differently than those > 1024 ?

[Igor Podolskiy]

Indeed! The connection to the machine running the netcat listener also gets closed immediately, but only if netcat listens on port 389. Still very mysterious, but it seems not to be an AD/NTDS problem (the test machine is a Linux box). Thank you very much!

[Igor Podolskiy]

It doesn't seem to be a < 1024 issue, as netcat to port 390 works fine. The pf has a very standard configuration with regard to keep state rules, there are no special hacks/workarounds, it's a quite fresh install.

[adamo]

What happens if the client has a "pass all" policy only?

[Igor Podolskiy]

I configured the pf to pass everything, no effect. What's interesting is that I get the same behavior (apparently connected but connection reset immediately) even if nobody listens on port 389 on my test machine. Somehow I am starting to suspect the filtering and routing on the OpenVPN server.

[adamo]

Any progress yet?

[Igor Podolskiy]

Well, not really. I moved the OpenVPN server to another machine to avoid some interaction between the DC and the OpenVPN. It got a little better in that I now am able to connect to any machine except the DC on the .0.0/24 network on port 389/tcp (so the netcat test you've suggested passes). If i try to connect to the DC LDAP server though, it's the same picture: the connection gets established and then immediately reset by the DC.