Problema

En entornos con varias sedes, a menudo se desea que los equipos de una oficina remota se autentiquen contra el mismo controlador de dominio que la sede central. La arquitectura típica consiste en un túnel IPsec site‑to‑site entre los firewalls de ambas ubicaciones y, sobre ese túnel, los clientes Windows intentan unirse al dominio. El reto no es solo “abrir el túnel”, sino garantizar que los servicios de AD (LDAP, Kerberos, DNS) sean accesibles y que el tráfico de descubrimiento de dominio fluya sin interrupciones. Cuando alguna de esas piezas falla, el proceso de unión se queda en “no se encontró el dominio” o “error de autenticación”.

El problema se vuelve recurrente en laboratorios de simulación (GNS3, EVE‑NG) y en despliegues reales de sucursales pequeñas que no disponen de un controlador de dominio local.

Causa

  1. Rutas y ACLs incompletas
    El túnel IPsec suele estar configurado solo para subredes específicas. Si la red del cliente (por ejemplo VLAN 60) no está incluida en la política de encriptación, los paquetes LDAP (TCP 389) o Kerberos (UDP 88) nunca llegan al controlador.

  2. DNS que no resuelve el dominio a la IP interna
    Los clientes usan los servidores DNS configurados por DHCP. Si el DNS de la sucursal apunta a un resolutor público, la consulta _ldap._tcp.dc._msdcs.tudominio.local devuelve nada o una IP externa, rompiendo el descubrimiento.

  3. Problemas de NetBIOS/SMB broadcast
    En una VPN los broadcasts no atraviesan el túnel, por lo que la detección automática de controladores mediante NetBIOS falla. Sin una configuración de “Domain DNS suffix” o de “DC locator” explícita, el cliente no sabe a dónde dirigir la petición.

  4. Desalineación de relojes
    Kerberos requiere que la diferencia de tiempo entre cliente y KDC sea <5 min. En una sucursal sin sincronización NTP, el ticket nunca es válido.

  5. Políticas de seguridad en el firewall
    Algunas implementaciones de FortiGate bloquean tráfico UDP 88 o UDP 464 por defecto, o aplican inspección profunda que altera paquetes Kerberos.

  6. Segmentación de VLANs sin “router on a stick”
    Si el firewall no está configurado para enrutar entre VLAN 20 (HQ) y VLAN 60 (sucursal) antes de la VPN, los paquetes se pierden en la capa 2.

Solución

Una estrategia robusta combina ajustes en la VPN, en el DNS y en la configuración del cliente. Los pasos siguientes funcionan tanto en laboratorios como en entornos productivos.

1. Verificar y ampliar las políticas de túnel IPsec

  • Añadir las subredes de ambas sedes (HQ y sucursal) a la fase 2 de la VPN.
  • Incluir los puertos necesarios:
    • TCP 389 (LDAP) / TCP 636 (LDAPS)
    • UDP 88 (Kerberos) / UDP 464 (Kerberos Change/Set)
    • TCP/UDP 53 (DNS)
    • TCP 445 (SMB) si se usan scripts de inicio de sesión que acceden a shares.

2. Configurar DNS interno como único resolutor en la sucursal

  • En el servidor DHCP de la sucursal, asignar la IP del controlador de dominio (o de un DNS forwarder interno) como DNS primario.
  • Habilitar “Conditional Forwarder” en el DNS de HQ para que cualquier zona *.sucursal.local se resuelva localmente, evitando bucles.

3. Forzar el suffix DNS del dominio en los clientes

  • En la política DHCP, establecer Domain Name = tudominio.local.
  • Alternativamente, usar GPO o script local para añadir el suffix con netsh interface ip set dns "Ethernet" static <IP_DNS> primary validate=no y netsh interface ip add dns "Ethernet" <IP_DNS> index=2.

4. Sincronizar relojes

  • Configurar NTP en ambos firewalls apuntando a la misma fuente (por ejemplo, time.windows.com).
  • Verificar que los clientes Windows tengan el servicio “Windows Time” activo y que la zona horaria sea correcta.

5. Ajustar políticas de firewall

  • En FortiGate, crear reglas explícitas que permitan tráfico UDP 88/464 y TCP 389/445 entre las subredes.
  • Desactivar inspección de aplicación para los puertos Kerberos si se presentan problemas de “packet too small”.

6. Probar la resolución de controlador antes de unir

  • Desde la PC de sucursal, ejecutar nslookup -type=SRV _ldap._tcp.dc._msdcs.tudominio.local.
  • El resultado debe devolver la IP del DC de HQ. Si no, revisar DNS y rutas.

7. Unir el equipo al dominio

  • Con los ajustes anteriores, usar Sistema → Cambiar nombre del equipo o dominio → Dominio y proporcionar credenciales con permisos de unión.
  • Si la unión falla, revisar el mensaje de error:
    • “No se encontró el dominio” → DNS o rutas.
    • “Credenciales incorrectas” → cuenta o política de delegación.
    • “Error de tiempo” → sincronización NTP.

Cuándo aplicar esta solución

  • Escenarios típicos: sucursales pequeñas, oficinas remotas, laboratorios de entrenamiento, entornos híbridos donde no se despliegan controladores de dominio locales.
  • Síntomas que indican la necesidad: clientes que no pueden localizar el DC, errores de Kerberos al iniciar sesión, fallos de política de grupo en la sucursal.
  • No aplicar: cuando la arquitectura ya incluye controladores de dominio en cada sitio y la replicación de AD está configurada; en ese caso la unión directa a un DC remoto es innecesaria y puede generar latencia.

Código

# Configuración DHCP (ejemplo en Windows Server)
netsh dhcp server 10.0.0.1 scope 10.0.60.0 set optionvalue 006 IPADDRESS 10.0.20.10
netsh dhcp server 10.0.0.1 scope 10.0.60.0 set optionvalue 015 STRING "tudominio.local"

# Añadir DNS suffix en cliente Windows (PowerShell)
Set-DnsClientGlobalSetting -SuffixSearchList @("tudominio.local")

Verificación

  1. Ping al DC 
    ping 10.0.20.10   # IP del controlador en HQ
  2. nslookup del SRV (verifica que el cliente ve el DC) 
    nslookup -type=SRV _ldap._tcp.dc._msdcs.tudominio.local
  3. Comprobar Kerberos 
    klist tgt
    La salida debe mostrar un ticket válido con fecha de expiración futura.
  4. Unir al dominio (prueba sin crear cuenta) 
    netdom join %computername% /Domain:tudominio.local /UserD:adminuser /PasswordD:*
    Si el comando devuelve “The command completed successfully”, la unión está lista.
  5. Reiniciar y validar políticas de grupo
    Ejecutar gpresult /r y confirmar que las GPO de HQ aparecen en la lista.

Notas adicionales

  • En entornos FortiGate, la opción “Enable NAT Traversal” puede ser necesaria si alguno de los extremos está detrás de NAT.
  • Si la sucursal usa varios enlaces WAN, considera SD‑WAN para balancear tráfico AD y evitar congestión del túnel.
  • Para laboratorios, GNS3 permite emular la VPN, pero asegúrate de que los adapters de la VM tengan la misma MTU que la red real (normalmente 1500).
  • Cuando se usan controladores de dominio de solo lectura (RODC) en la sucursal, la unión es idéntica pero se reduce la carga de autenticación en la sede central.
  • Mantén los registros de eventos de System y Directory Service en el DC; los códigos 5719 y 1053 son indicadores claros de problemas de DNS/Kerberos en clientes remotos.