Problema

En entornos distribuidos es frecuente que la sede central aloje los servicios de Active Directory (AD), DNS y DHCP, mientras que las sucursales solo disponen de conectividad de red. El reto consiste en permitir que un equipo Windows en la sucursal se una al dominio gestionado en la sede, usando exclusivamente una Site‑to‑Site VPN. La pregunta típica es: ¿esta arquitectura funciona en producción o solo sirve para laboratorios? Además, cuando la unión falla, los síntomas suelen ser “no se encuentra el controlador de dominio”, “error de DNS” o “tiempo de espera agotado”. El objetivo de este artículo es describir un enfoque genérico que permita diagnosticar y resolver esos problemas, independientemente de la topología exacta o del hardware VPN empleado.

Causa

Los fallos al unir un equipo remoto a AD a través de VPN provienen, en la práctica, de tres grupos de causas:

  1. Rutas y encaminamiento

    • La VPN no está propagando la subred de la sede (por ejemplo, 10.0.20.0/24) hacia la sucursal, o viceversa.
    • Los routers intermedios o firewalls bloquean el tráfico de los puertos necesarios (TCP 389, 636, 3268, 3269, 53, 88, 445).

  2. DNS mal configurado

    • El cliente de sucursal sigue usando su DNS local (por ejemplo, ISP) y no puede resolver los registros SRV de AD.
    • El servidor DNS de la sede no tiene zona de búsqueda inversa para la subred de la sucursal, lo que genera respuestas “refused”.

  3. Políticas de seguridad y NAT

    • La VPN está configurada en modo “policy‑based” y solo permite tráfico de ciertos puertos, dejando fuera los de Kerberos o RPC.
    • La traducción de direcciones (NAT) ocurre en el borde de la sucursal, de modo que el controlador de dominio recibe una IP inesperada y rechaza la autenticación.

En la mayoría de los laboratorios GNS3, la falta de un servidor DHCP real y la configuración estática de IPs hacen que el problema se reduzca a rutas y DNS, pero en entornos reales también aparecen restricciones de firewall y NAT implícitas.

Solución

1. Verificar y ajustar el encaminamiento

  • En cada dispositivo VPN (FortiGate, Cisco ASA, etc.) asegúrate de que exista una política que permita el tráfico entre la subred de la sede y la de la sucursal.
  • En la sucursal, agrega una ruta estática que apunte a la red de la sede a través del túnel VPN. En Windows:
route add 10.0.20.0 mask 255.255.255.0 <IP_del_túnel_local>
  • En la sede, haz lo mismo para la subred de la sucursal.

2. Configurar DNS de forma consistente

  • Configura el cliente de sucursal para que su único servidor DNS sea la IP del controlador de dominio (o un servidor DNS interno que reenvíe a él).
  • En el controlador de dominio, habilita la zona de búsqueda inversa para la subred de la sucursal y crea un registro A estático para el cliente, si es necesario.
  • Prueba la resolución de los registros SRV de AD desde la sucursal:
nslookup -type=SRV _ldap._tcp.dc._msdcs.tu-dominio.com

Debe devolver la IP del controlador de dominio.

3. Asegurar puertos y protocolos

  • Abre en ambos extremos los puertos TCP/UDP requeridos por AD: 53, 88, 135, 389, 445, 464, 636, 3268, 3269, 49152‑65535 (RPC dinámico).
  • Desactiva temporalmente cualquier inspección profunda de paquetes que pueda alterar Kerberos (por ejemplo, “SSL inspection”).
  • Si la VPN usa NAT, configura NAT exemption para el tráfico AD, de modo que la IP original del cliente llegue intacta al controlador.

4. Unir el equipo al dominio

Una vez que la conectividad y DNS están confirmados, procede a unir el equipo. En PowerShell:

Add-Computer -DomainName tu-dominio.com -Credential (Get-Credential) -Restart

Si el proceso falla, revisa el mensaje de error; los más comunes son “The DNS name does not exist” (problema de DNS) o “The trust relationship between this workstation and the primary domain failed” (problema de Kerberos/NAT).

5. Automatizar la verificación en la sucursal

Para entornos con varios equipos, crea un script de arranque que:

  1. Verifique la ruta hacia la sede (Test-Connection).
  2. Compruebe la resolución de los SRV (Resolve-DnsName).
  3. Intente unir el equipo si ambos pasos son positivos.

Esto reduce la intervención manual y asegura que cualquier cambio de topología sea detectado rápidamente.

Cuándo aplicar esta solución

  • Síntomas: el cliente no puede localizar el controlador de dominio, errores de DNS al intentar unir el dominio, o el proceso de unión se queda “pendiente”.
  • Entorno: sucursales con conectividad VPN site‑to‑site, controladores de dominio centralizados y sin control directo de la red de la sucursal.
  • No aplica: cuando la sucursal dispone de su propio controlador de dominio y la replicación se realiza mediante AD Sites & Services, o cuando se usa DirectAccess/Always‑On VPN que ya gestiona automáticamente la resolución y el tráfico AD.

Código

# 1. Añadir ruta estática a la red de la sede
route add 10.0.20.0 mask 255.255.255.0 172.16.1.1 metric 10

# 2. Configurar DNS primario al controlador de dominio
netsh interface ip set dns "Ethernet" static 10.0.20.10 primary

# 3. Verificar registros SRV de AD
nslookup -type=SRV _ldap._tcp.dc._msdcs.tu-dominio.com

# 4. Unir al dominio (PowerShell)
Add-Computer -DomainName tu-dominio.com -Credential (Get-Credential) -Restart

Verificación

  1. Ping al controlador de dominio desde la sucursal (ping 10.0.20.10).
  2. nslookup de los registros SRV; la respuesta debe contener la IP del DC.
  3. Ejecutar nltest /dsgetdc:tu-dominio.com para confirmar que el cliente localiza el DC.
  4. Después del reinicio, comprobar que whoami /fqdn devuelve el nombre del dominio.
  5. En el controlador, revisar el Event Viewer bajo “Directory Service” y “Security” para confirmar que el equipo se ha registrado sin errores.

Notas adicionales

  • En entornos FortiGate, la opción “Enable NAT Traversal” suele ser necesaria cuando ambos extremos están detrás de NAT pública.
  • Si la sucursal tiene varios rangos de IP, crea rutas estáticas para cada uno o habilita dynamic routing (OSPF/BGP) sobre la VPN; simplifica la gestión a largo plazo.
  • Mantén los relojes sincronizados (NTP) entre sede y sucursal; Kerberos falla silenciosamente si la diferencia supera los 5 minutos.
  • Cuando uses GNS3 para pruebas, recuerda que los dispositivos virtuales pueden no replicar la latencia real; siempre valida la configuración en hardware antes de pasar a producción.