Problema

En entornos donde se ha re‑diseñado la red (VLANs, nuevos switches, cambios de DNS) es frecuente que los controladores de dominio (Domain Controllers) y los servidores que dependen de ellos (por ejemplo, un servidor de aplicaciones que usa LDAP/LDAPS) pierdan la capacidad de establecer una sesión TCP en los puertos 389 (LDAP) y 636 (LDAPS).

Los síntomas típicos son:

  • Ping y resolución de nombres funcionan sin problemas.
  • nslookup devuelve la IP correcta del DC.
  • Cualquier intento de abrir una conexión LDAP (por ejemplo, ldapsearch, herramientas de AD, o aplicaciones que usan LDAP) falla con timeout o “connection refused”.
  • Desactivar el firewall de Windows en el DC no cambia nada.
  • Desde el DC hacia el servidor AD sí se abre el puerto 389, lo que indica que el camino inverso está operativo.

Este patrón indica que la capa de red está fragmentada: la ruta de ida (cliente → DC) está bloqueada o mal encaminada, mientras que la ruta de vuelta (DC → cliente) sigue funcionando.

Causa

Varias causas aparecen con regularidad en este tipo de despliegues:

  1. Rutas estáticas o ACLs en routers/firewalls que no contemplan el nuevo segmento VLAN
    Cuando se añaden rutas entre VLAN, es fácil olvidar que el tráfico LDAP debe pasar por el mismo gateway en ambos sentidos. Una ruta unidireccional o una regla de ACL que solo permite ICMP y DNS pero no TCP/389/636 producirá exactamente el comportamiento descrito.

  2. Forwarders DNS mal configurados
    Los controladores de dominio actúan como servidores DNS internos. Si un AD Server sigue apuntando a un forwarder que ya no existe o que no puede resolver nombres internos, la resolución funciona (porque el registro está en caché) pero la negociación Kerberos/LDAP falla al intentar localizar el SRV _ldap._tcp.dc._msdcs.<domain>.

  3. Política de firewall de Windows con perfiles de red
    En Windows Server 2012 la regla “Domain” se aplica solo cuando la interfaz está marcada como dominio. Si la NIC está en una VLAN que el controlador no reconoce como dominio, la regla “Public” o “Private” puede bloquear 389/636 aunque el firewall esté “desactivado” en la UI (las reglas persistentes siguen activas).

  4. MTU o fragmentación en túneles entre routers
    Cuando la ruta pasa por un firewall que realiza NAT o inspección profunda, una MTU reducida puede provocar que los paquetes TCP se pierdan antes de completarse el handshake, mientras que ICMP y DNS (paquetes más pequeños) llegan sin problemas.

  5. Configuración de “Network Service” o “System” en el DC que restringe la escucha en interfaces específicas
    En algunos entornos se ha configurado el DC para escuchar LDAP solo en la NIC primaria. Si la nueva VLAN usa una segunda NIC, el servicio no está escuchando en esa dirección.

Solución

Una estrategia reutilizable se basa en validar cada capa de la pila de red y corregir la configuración que cause la ruptura.

1. Verificar rutas y ACLs

  • En cada router/firewall que interconecta VLAN, ejecuta show ip route (o el equivalente) y confirma que exista una ruta bidireccional entre la subred del AD Server y la del DC.
  • Revisa las listas de control de acceso (ACL) y asegúrate de que permitan tráfico TCP destinado a los puertos 389 y 636 en ambas direcciones.
  • Si utilizas un firewall de capa 7, verifica que no haya inspección de LDAP que requiera certificados válidos; desactívala temporalmente para descartar el filtro.

2. Corregir forwarders DNS

  • En el DNS del DC, elimina forwarders que apunten a servidores obsoletos.
  • Añade los servidores DNS internos como forwarders o, mejor aún, configura la zona ._msdcs.<domain> como zona primaria en el DC.
  • Ejecuta nslookup -type=SRV _ldap._tcp.dc._msdcs.tu-dominio.com desde el AD Server y verifica que la respuesta incluya la IP del DC.

3. Ajustar firewall de Windows

  • Abre una consola PowerShell con privilegios de administrador y ejecuta:
Get-NetFirewallRule -DisplayGroup "LDAP Server" | Set-NetFirewallRule -Enabled True
  • Si la NIC está en una VLAN no marcada como “Domain”, cambia el perfil con:
Set-NetConnectionProfile -InterfaceAlias "Ethernet 2" -NetworkCategory Domain
  • Alternativamente, crea una regla explícita que permita 389/636 sin importar el perfil:
New-NetFirewallRule -DisplayName "Allow LDAP/LDAPS" -Direction Inbound -Protocol TCP -LocalPort 389,636 -Action Allow

4. Probar la conectividad TCP

Usa Test-NetConnection (PowerShell) o nc (netcat) desde el AD Server:

Test-NetConnection -ComputerName <IP_DC> -Port 389 -InformationLevel Detailed
Test-NetConnection -ComputerName <IP_DC> -Port 636 -InformationLevel Detailed

Si el resultado muestra “TcpTestSucceeded : True”, la ruta está correcta. Si falla, revisa los logs del firewall y los contadores de paquetes descartados en los routers.

5. Revisar MTU y fragmentación

  • Ejecuta ping -f -l 1472 <IP_DC> desde el AD Server. Si el ping fragmentado falla, reduce la MTU en la interfaz del router o habilita “Don’t Fragment” en los equipos intermedios.
  • En routers con NAT, habilita “TCP MSS Clamping” a 1400 para evitar fragmentación de los paquetes LDAP.

6. Confirmar que el servicio LDAP escucha en todas las NIC

  • En el DC, abre netstat -ano | findstr :389 y verifica que la IP local sea 0.0.0.0 (escucha en todas las interfaces).
  • Si solo aparece una IP específica, revisa la configuración de “Network Binding” en Active Directory Sites and Services → “NTDS Settings” → “IP Addresses”.

Cuándo aplicar esta solución

Esta guía es válida cuando:

  • La resolución DNS funciona pero las conexiones LDAP/LDAPS fallan.
  • El firewall de Windows está desactivado o se sospecha que el problema está fuera del host.
  • Se ha realizado recientemente una migración de red (VLANs, cambios de router, nuevo DNS).

No es necesaria si:

  • El problema ocurre también con ping o con cualquier otro puerto TCP (indica un fallo de capa inferior).
  • El DC y el AD Server están en la misma subred y no hay routers intermedios.

Código

# 1. Verificar ruta bidireccional (router Cisco)
show ip route <subred_AD>
show ip route <subred_DC>

# 2. Comprobar ACLs (router Cisco)
show access-lists | include 389
show access-lists | include 636

# 3. PowerShell: habilitar regla LDAP en Windows Firewall
Get-NetFirewallRule -DisplayGroup "LDAP Server" | Set-NetFirewallRule -Enabled True
New-NetFirewallRule -DisplayName "Allow LDAP/LDAPS" -Direction Inbound -Protocol TCP -LocalPort 389,636 -Action Allow

# 4. Test de conectividad TCP desde el AD Server
Test-NetConnection -ComputerName 10.0.2.5 -Port 389 -InformationLevel Detailed
Test-NetConnection -ComputerName 10.0.2.5 -Port 636 -InformationLevel Detailed

# 5. Ping con no‑fragment (MTU test)
ping -f -l 1472 10.0.2.5

Verificación

  1. Ejecuta los comandos de Test‑NetConnection. Ambos puertos deben devolver TcpTestSucceeded : True.
  2. Desde una herramienta LDAP (por ejemplo, ldapsearch o la consola “Active Directory Users and Computers”) realiza una consulta simple: ldapsearch -x -h <IP_DC> -b "dc=tu-dominio,dc=com" "(objectClass=person)".
  3. Revisa los logs de eventos en el DC (Event Viewer → Directory Service) y busca entradas de “LDAP connection failed” que desaparezcan después de la corrección.
  4. Confirma que los servicios críticos que dependen de LDAP (por ejemplo, Exchange, SCCM) vuelvan a sincronizar sin errores.

Notas adicionales

  • Cuando trabajas con máquinas virtuales en Proxmox o PfSense, verifica que los tags de VLAN estén correctamente asignados a las interfaces virtuales; de lo contrario, el tráfico puede quedar atrapado en el host.
  • En entornos con forwarders DNS externos, evita que el DC delegue la zona _msdcs a un servidor externo; eso rompe la localización automática de los DC.
  • Si después de los ajustes sigue sin funcionar, habilita el registro de auditoría de LDAP en el DC (HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics\15 LDAP Interface Events) y revisa los mensajes de “connection refused”.
  • En versiones de Windows Server anteriores a 2016, la regla de firewall “Domain” se aplica también a la categoría “Private”. Asegúrate de que la NIC tenga el perfil correcto para evitar bloqueos silenciosos.