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:

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?

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.
–
Igor PodolskiyOct 12 '10 at 8:19

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 ?
–
adamoOct 12 '10 at 8:33

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 PodolskiyOct 12 '10 at 8:36

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.
–
Igor PodolskiyOct 12 '10 at 8:49

What happens if the client has a "pass all" policy only?
–
adamoOct 12 '10 at 8:54