Cómo identificar la regla exacta del Firewall de Windows que bloquea tu tráfico en Windows Server 2022

Cualquiera que haya trabajado administrando sistemas Windows o resolviendo incidencias de red se ha enfrentado alguna vez a ese escenario frustrante: la conectividad entre dos equipos falla, sospechas firmemente del cortafuegos, pero determinar qué regla concreta está descartando (dropping) los paquetes puede convertirse en una búsqueda del tesoro.

Históricamente, la Plataforma de Filtrado de Windows (WFP, por sus siglas en inglés) registraba eventos de bloqueo indicando un identificador de tiempo de ejecución (Filter Run-Time ID). El problema de este ID es que era volátil: cambiaba tras cada reinicio o recarga del servicio, lo que obligaba a recurrir a herramientas como netsh wfp show state para volcar la base de datos XML de la WFP y mapear manualmente la regla en cuestión.

Afortunadamente, a partir de Windows Server 2022, Microsoft introdujo una mejora muy agradecida en los eventos de auditoría: el campo Filter Origin. Gracias a esta novedad, es posible rastrear el origen exacto del bloqueo de forma directa y en cuestión de segundos.

En este artículo veremos el procedimiento paso a paso para diagnosticar estos bloqueos.

Paso 1: Habilitar la auditoría de la Windows Filtering Platform

Por defecto, Windows no registra cada paquete o conexión bloqueada en el visor de eventos para evitar saturar los registros del sistema. Por ello, el primer paso en nuestro proceso de troubleshooting consiste en activar la auditoría para la categoría correspondiente.

Abre una consola de comandos (CMD o PowerShell) con privilegios de administrador y ejecuta los siguientes comandos:

DOS 

auditpol /set /category:"System" /SubCategory:"Filtering Platform Packet Drop" /success:enable /failure:enable
auditpol /set /category:"System" /SubCategory:"Filtering Platform Connection" /success:enable /failure:enable

Al habilitar estas dos subcategorías, el Visor de Eventos de Windows comenzará a registrar las acciones que realiza el motor de filtrado.

Paso 2: Identificar el evento de bloqueo en el Visor de Eventos

Una vez activada la auditoría y provocada de nuevo la falta de conectividad (por ejemplo, intentando realizar una petición al puerto o IP bloqueada), debemos dirigirnos al Visor de Eventos (Event Viewer), en la sección:

Registros de Windows > Seguridad (Windows Logs > Security) 

Dentro de esta sección se generarán diversos tipos de eventos según la subcategoría:

Eventos de la subcategoría Filtering Platform Connection

• 5031: El servicio del firewall de Windows bloqueó una aplicación para aceptar conexiones entrantes.

• 5154: La WFP ha permitido a una aplicación o servicio escuchar en un puerto para conexiones entrantes.

• 5155: La WFP ha bloqueado a una aplicación o servicio para escuchar en un puerto.

• 5156: La WFP ha permitido una conexión.

• 5157: La WFP ha bloqueado una conexión.

• 5158: La WFP ha permitido el enlace (bind) a un puerto local.

Eventos de la subcategoría Filtering Platform Packet Drop

• 5152: La WFP ha bloqueado un paquete (The Windows Filtering Platform blocked a packet).

• 5153: Un filtro más restrictivo de la WFP ha bloqueado un paquete.

El evento clave que debemos buscar para traquear el descarte explícito de paquetes es el Event ID 5152. 

Paso 3: Analizar los detalles del evento y el campo Filter Origin

Al inspeccionar un evento 5152 en la pestaña General o Detalles, obtendremos información detallada sobre el tráfico descartado:

• Proceso y Aplicación: La ruta del ejecutable implicado en el tráfico.

• Información de Red: Dirección IP de origen, IP de destino, puerto de origen, puerto de destino y protocolo.

Pero el dato realmente valioso en Windows Server 2022 se encuentra en la sección Filter Information:

• Filter Origin: {F0381551-2372-49C6-9668-5226C7946EC4}

• Filter Run-Time ID: 72246

• Layer Name: Connect

A diferencia del Filter Run-Time ID (que, como mencionamos, cambia en cada sesión), el valor Filter Origin contiene el GUID permanente de la regla del Firewall que generó la acción de bloqueo.

Paso 4: Revelar el nombre de la regla mediante PowerShell

Con el valor del GUID obtenido en el campo Filter Origin, la parte más difícil está resuelta. Ahora solo necesitamos pedirle a PowerShell que nos traduzca ese identificador único al nombre legible de la regla.

Abre un terminal de PowerShell y ejecuta el cmdlet Get-NetFirewallRule pasando el GUID en el parámetro -Name:

PowerShell

Get-NetFirewallRule -Name "{F0381551-2372-49C6-9668-5226C7946EC4}"

El resultado te devolverá las propiedades completas de la regla, entre las que destacan:

• DisplayName: El nombre de la regla tal y como aparece en la interfaz gráfica del Firewall de Windows (por ejemplo, TEST rule block 443).

• Enabled: Indica si está activa (True).

• Direction: Dirección del tráfico (Inbound o Outbound).

• Action: La acción aplicada (Block).

De este modo, habrás pasado de un simple fallo de conectividad en red a conocer el nombre exacto de la regla responsable en apenas tres pasos y sin necesidad de descifrar complejos volcados de memoria o archivos XML.

Resumen del flujo de trabajo

1. Habilitar auditoría: Configurar auditpol para registrar Packet Drop y Connection.

2. Capturar el evento: Buscar el Event ID 5152 en el registro de Seguridad.

3. Extraer el GUID: Copiar el valor del campo Filter Origin.

4. Consultar en PowerShell: Ejecutar Get-NetFirewallRule -Name <GUID> para obtener el nombre visible de la regla.

Una vez terminada la investigación, recuerda desactivar o ajustar la auditoría si no la necesitas de forma continua para evitar un crecimiento innecesario del archivo de eventos de seguridad.