I recently migrated the network to separate VLANs, moved the BIND DNS service to a new machine and newer version, and changed the firewall/routing setup. The BIND server forwards queries to two Active Directory servers.
One Windows Server 2022 AD server can ping the domain controller and resolve names through DNS, but connections to the domain controller fail when testing TCP 389. Both LDAP and LDAPS fail. Disabling Windows Firewall did not change anything. The reverse direction works: the domain controller can connect to the AD server over TCP.
The domain controller is on a separate network, with a static route in OPNsense leading to pfSense on Proxmox, where the virtual machines and the other AD server reside. The AD servers also still had DNS forwarders pointing to the old DNS server, although changing that did not resolve the issue.
Event logs now show: "A fatal alert was received from the remote endpoint. The TLS protocol defined fatal alert code is 70." This may indicate a TLS protocol or cipher incompatibility, but the connection worked before the firewall, routing, and DNS changes. What should I check to determine whether this is asymmetric routing, DNS, TLS configuration, or another network issue?
5 Answers
You do not need to disable Windows Firewall as a diagnostic step. It can affect behavior for services that rely on dynamically negotiated RPC ports, and the firewall rules should be validated rather than bypassed. Windows Server 2022 should be compatible with a 2012-era domain controller functional level, so that is less likely than routing, stale DNS, certificate, or TLS-policy problems. Creating another domain controller could be a reasonable modernization plan, but it will not fix a blocked route or incompatible TLS settings by itself.
Check the complete AD communication path rather than only ping and TCP 389. Active Directory commonly needs DNS, Kerberos, LDAP/LDAPS, SMB, RPC endpoint mapping on 135, and dynamic RPC ports. Confirm that the firewall permits the required traffic in both directions and that the return route uses the expected interface. A static route or stateful firewall issue can make one direction appear to work while replies take a different path.
The TLS alert is significant: alert 70 generally means a protocol-version problem. For LDAPS, compare the Schannel and TLS settings on both servers, including enabled protocol versions, cipher suites, certificate validity and name matching, and any recent security-policy or patch changes. Also verify that the servers have accurate time. A TCP connection can succeed while the TLS negotiation still fails, so this points beyond basic port reachability.
The failure started after the firewall and DNS migration, even though this previously worked. I’m checking whether a policy or TLS setting changed along with the network changes.
Restarting the Network Location Awareness service may help if Windows classified the network incorrectly after the VLAN and routing changes, but it is not a substitute for checking the actual policies. Review the Directory Services, System, Schannel, and DNS Server event logs on both hosts. Also check whether the LDAPS certificate is installed in the correct certificate store and includes the domain controller’s DNS name.
Make sure every server uses the correct AD DNS service for the domain and that the required SRV records resolve correctly. Remove stale forwarders or references to the old DNS server, then test records such as _ldap._tcp, _kerberos._tcp, and the domain controller hostname from both machines. DNSSEC would not normally cause a TLS alert by itself, but broken or inconsistent DNS can send LDAP clients to the wrong address or prevent AD discovery.
Asymmetric routing is one of my main suspicions because the domain controller and the virtual machines are on different routed networks.