I recently migrated the network to VLANs, moved several systems, and migrated my BIND DNS server to a newer machine and version. The BIND server forwards queries to two Active Directory servers.
One AD server can ping the domain controller and resolve names through DNS, but connections to TCP port 389 fail. LDAPS connections fail as well. Disabling the Windows Firewall did not change the behavior. Testing in the opposite direction works: the domain controller can connect to the AD server over TCP.
The environment includes a Windows Server 2012 domain controller on a separate network. A static route in OPNsense points toward pfSense running on Proxmox, where the virtual machines and AD server are located. The AD servers also had a DNS forwarder configured for the old DNS server, although changing that configuration did not resolve the issue.
The affected server is running Windows Server 2022 and had worked previously. Recent changes included the firewall, VLAN layout, and BIND server. I am also seeing the event-log message: "A fatal alert was received from the remote endpoint. The TLS protocol defined fatal alert code is 70." Could this be caused by asymmetric routing, DNS configuration, or a TLS compatibility problem?
4 Answers
Since the connection works from the domain controller to the other server but not in the reverse direction, asymmetric routing or a firewall rule on the return path is a strong possibility. Verify that the response traffic from the domain controller returns through the same gateway and that the inter-VLAN rules allow established TCP sessions in both directions. Also check routing tables on the hosts and both firewalls, not just whether the ports are listening.
The TLS alert is worth investigating. Alert code 70 generally indicates a protocol-version problem, so the older Windows Server 2012 domain controller may not agree with the Server 2022 client on the TLS versions or cipher suites used for LDAPS. Check the Schannel events on both machines and verify which TLS versions are enabled. This may explain LDAPS, but it would not by itself explain a failure on plain LDAP port 389, so treat the two tests separately.
DNS needs to be checked beyond a basic name lookup. Active Directory depends on SRV records such as _ldap._tcp and _kerberos._tcp, and stale records or forwarding the AD domain to the wrong DNS server can cause failures even when ordinary host lookups work. Confirm that the client uses the AD DNS service for the domain, that the domain controller can resolve the new BIND server as expected, and that no old forwarder or DNSSEC validation issue is interfering.
Restarting Network Location Awareness on both systems may help after the network profile or VLAN changes, but it is not a substitute for checking the actual path. Review the Directory Service, DNS Server, Schannel, and System event logs on both machines. Disabling Windows Firewall is not a reliable diagnostic because Windows services and dynamic AD/RPC ports depend on firewall behavior and network profiles.
The logs are already showing the TLS fatal alert, so I will compare the Schannel events and enabled protocols on both servers while also checking the routing path.
The Server 2022 machine worked with this domain controller before the network and DNS changes, so I am trying to determine whether a policy or routing change altered the TLS behavior.