Problema

En muchos entornos corporativos el acceso a los recursos administrativos de Windows (por ejemplo, los admin shares C$, ADMIN$) se realiza sobre SMB (puerto 445). Cuando el tráfico queda sin cifrar, cualquier atacante que intercepte la red puede leer o modificar datos, y los controles de firewall tradicionales no impiden que máquinas no autorizadas establezcan la conexión. La necesidad típica es “encapsular” SMB dentro de IPSec para que solo hosts y usuarios explícitos puedan comunicarse, y que cualquier intento fuera de la política sea descartado antes de que llegue a la capa de aplicación.

El patrón que se repite es:

  1. Se crean reglas de Connection Security en el Firewall de Windows, pero la negociación IPSec nunca se completa.
  2. Los paquetes IKE (ISAKMP) aparecen en Wireshark, sin que se establezca la sesión de SMB.
  3. No hay eventos claros en el visor de eventos y la conexión simplemente falla con “acceso denegado”.

El reto es identificar qué configuraciones impiden que la regla de seguridad se active y cómo estructurar la política para que funcione de forma fiable en cualquier dominio Windows.

Causa

1. Desalineación de puertos y direcciones en la regla de seguridad

Las reglas de Connection Security deben especificar exactamente los puertos de origen y destino que participarán en la negociación IPSec. Si se usa “Any” para el puerto de origen o destino, Windows interpreta que la regla es demasiado amplia y la descarta a la hora de crear una asociación de seguridad.

2. Falta de coincidencia de Endpoint en ambas direcciones

IPSec en Windows es bidireccional: cada host necesita una regla que reconozca al otro como Endpoint. Si la regla del host A tiene Endpoint 1 = A, Endpoint 2 = B y la del host B tiene la inversión incorrecta o usa rangos diferentes, la negociación falla aunque IKE se inicie.

3. Políticas de Authentication incompatibles

Por defecto, Windows usa autenticación basada en Kerberos o certificados. Cuando una regla se crea sin especificar un método, el motor intenta usar Kerberos; si los equipos no están en el mismo dominio o el SPN no coincide, la negociación se aborta silenciosamente.

4. Configuración de IPsec Enforcement en la regla de firewall

Una regla de firewall que depende de “Allow if secure” necesita que la asociación IPSec esté establecida antes de que el tráfico sea aceptado. Si la regla de seguridad no se activa, la regla de firewall descarta el paquete sin registrar error.

5. Interferencia de políticas de grupo (GPO)

En entornos gestionados, una GPO que deshabilita la negociación automática o que fuerza el modo “Require Encryption” en SMB puede colisionar con la regla manual, provocando que los paquetes IKE nunca alcancen la capa de IPSec.

Solución

Paso 1: Definir los endpoints de forma explícita

Utiliza direcciones IP estáticas o nombres DNS resolubles y evita “Any”. En PowerShell:

$epA = "10.0.1.10"
$epB = "10.0.1.20"

Paso 2: Crear reglas de Connection Security idénticas en ambos hosts

Ejemplo con PowerShell (requiere privilegios de administrador):

# Host A
New-NetIPsecRule -DisplayName "SMB IPSec A→B" `
    -Direction Inbound -LocalPort 445 -RemotePort 445 `
    -LocalAddress $epA -RemoteAddress $epB `
    -Protocol TCP -Authentication Kerberos `
    -Encryption AES256 -PolicyStore ActiveStore

# Host B (inverso)
New-NetIPsecRule -DisplayName "SMB IPSec B→A" `
    -Direction Inbound -LocalPort 445 -RemotePort 445 `
    -LocalAddress $epB -RemoteAddress $epA `
    -Protocol TCP -Authentication Kerberos `
    -Encryption AES256 -PolicyStore ActiveStore

Si el dominio no permite Kerberos entre los hosts, reemplaza -Authentication Kerberos por -Authentication Certificate y asegura que ambos equipos tengan un certificado válido emitido por la misma CA.

Paso 3: Configurar la regla de firewall que dependa de la asociación IPSec

En cada host crea una regla de firewall que permita SMB solo cuando la conexión esté protegida:

New-NetFirewallRule -DisplayName "Allow SMB over IPSec" `
    -Direction Inbound -Protocol TCP -LocalPort 445 `
    -Action Allow -Profile Any `
    -EdgeTraversalPolicy Block `
    -RemoteAddress $epB `
    -Enabled True `
    -PolicyStore ActiveStore `
    -Authentication Required `
    -Encryption Required

La clave es el parámetro -Authentication Required y -Encryption Required, que obliga a que la regla de Connection Security esté activa antes de aceptar el tráfico.

Paso 4: Verificar que no haya GPO conflictivas

Revisa la política de grupo bajo Computer Configuration → Policies → Windows Settings → Security Settings → IP Security Policies. Si existe una política que ya define reglas IPSec, desactívala o asegúrate de que no incluya la opción “Require secure connection for SMB”.

Paso 5: Reiniciar los servicios de red

Después de crear o modificar reglas, ejecuta:

netsh advfirewall reset
Restart-Service -Name ipsec

Esto fuerza a Windows a recargar la tabla de asociaciones.

Cuándo aplicar esta solución

  • Entornos con admin shares: cuando el acceso a C$ o ADMIN$ se usa para soporte remoto y se necesita aislamiento de red.
  • Redes segmentadas: cuando los servidores y estaciones de trabajo están en subredes distintas y se desea que solo pares específicos intercambien datos SMB.
  • Políticas de cumplimiento: cuando la normativa exige cifrado de tráfico interno, incluso dentro del perímetro de la LAN.
  • No aplicar: en entornos donde el rendimiento es crítico y la sobrecarga de cifrado de AES256 en SMB 3.0 no es aceptable, o cuando todos los hosts ya usan SMB 3.0 con cifrado nativo (en ese caso IPSec es redundante).

Código

# Reiniciar firewall y servicio IPSec
netsh advfirewall reset
Restart-Service -Name ipsec

Verificación

  1. Comprobar la asociación IPSec

    Get-NetIPsecMainModeSA | Where-Object {$_.RemoteAddress -eq $epB}
Get-NetIPsecQuickModeSA | Where-Object {$_.RemoteAddress -eq $epB}

    Deberían aparecer entradas con Encryption = AES256.

  2. Probar el acceso SMB
    Desde el host B ejecuta:

    dir \\10.0.1.10\c$

    La lista debe mostrarse sin errores. Si falla, revisa el visor de eventos bajo Applications and Services Logs → Microsoft → Windows → IPsec.

  3. Captura de paquetes
    En Wireshark filtra ip.addr == 10.0.1.10 && tcp.port == 445. Deberías ver paquetes ESP (protocol 50) en lugar de tráfico plano TCP.

  4. Evento de firewall
    En el visor de eventos, busca Microsoft-Windows-Windows Firewall With Advanced Security con ID 2004 (regla permitida) y verifica que el campo “Security Association” esté presente.

Notas adicionales

  • SMB 3.0 cifrado: si todos los equipos ejecutan Windows 8/Server 2012 o superior, habilitar el cifrado nativo de SMB (Set-SmbServerConfiguration -EncryptData 1) puede simplificar la arquitectura. IPSec sigue siendo útil cuando se necesita control de origen/destino más granular.
  • Certificados: al usar autenticación basada en certificados, asegúrate de que la cadena de confianza sea completa y que el certificado incluya Client Authentication y Server Authentication.
  • Rendimiento: la sobrecarga de AES256 en una LAN gigabit suele ser <5 ms por transferencia, pero monitoriza el uso de CPU en servidores críticos.
  • Auditoría: habilita el registro de eventos IPsec con nivel “Success and Failure” para obtener trazas claras en caso de futuros problemas.