El firewall de Windows y las aplicaciones empresariales — registre las reglas de entrada con el instalador

«En el equipo de desarrollo funciona, pero al instalarlo en el PC del cliente otro equipo no logra conectarse». Hay ocasiones en las que este tipo de consulta hace sospechar del firewall de Windows. Ahora bien, que no se pueda comunicar y que el firewall esté bloqueando no son la misma cosa. A veces la aplicación no está escuchando; a veces el destino o el puerto son distintos; a veces la regla de permiso no coincide con las condiciones de la red.

En el equipo de desarrollo a menudo quedan reglas de permiso creadas en el pasado. Comprobar el funcionamiento en ese estado no reproduce el comportamiento de un destino de implantación nuevo. En lugar de presuponer que alguien permitirá el aviso del primer inicio, el procedimiento de implantación del producto tiene que incluir qué comunicación se permite, quién la permite y en qué etapa. Microsoft también recomienda colocar las reglas necesarias antes del primer inicio de la aplicación.¹

Este artículo toma como ejemplo principal una aplicación empresarial que acepta conexiones TCP desde otro equipo, y ordena el diseño de las reglas, su incorporación al instalador y el orden de comprobación cuando no se puede comunicar en el cliente. Asume la operación en Windows 11 y Windows Server, y las explicaciones técnicas se basan en la documentación pública de Microsoft comprobada el 8 de septiembre de 2026. Los nombres de producto, las rutas, los puertos y los rangos de IP de los comandos son ejemplos. Sustitúyalos para que coincidan con su entorno.

1. La conclusión primero

Hay tres puntos que conviene retener de entrada.

• Si hace falta una regla de entrada lo decide la dirección de la comunicación, no el nombre de la aplicación. Distinga si solo inicia conexiones o si espera comunicaciones nuevas desde otro equipo.²
• Coloque las reglas necesarias antes del primer inicio. En equipos donde se permite la gestión local, el instalador es una opción; en equipos gestionados de forma centralizada, la distribución mediante GPO, Intune u un mecanismo similar.¹
• Cuando hay un fallo, compruebe en este orden: espera, conexión TCP, perfil, reglas y registro. Lo importante es no afirmar que hay permiso solo porque existe una regla, ni que no llegó nada solo porque no hay una entrada de registro.³⁴⁵⁶

La conclusión de este artículo, «regístrela con el instalador», no significa anular la directiva de gestión de la organización. Significa dejar las configuraciones que la comunicación necesita en un paso de implantación con responsabilidad clara, no en la primera operación del usuario.

En el diagrama, una línea continua marca una relación que siempre se cumple y una línea discontinua una relación condicional (las condiciones están en la explicación de cada relación en la página de detalle). La lista completa de relaciones (35 en total, con evidencia y grado de certeza) y las definiciones de los conceptos principales están reunidas en la página de detalle del mapa de conocimiento (en japonés). Datos: JSON-LD / Turtle

2. El comportamiento predeterminado con precisión — la entrada se bloquea y la salida se permite por defecto

El firewall de Windows es un firewall basado en host que controla la comunicación del propio equipo. De forma predeterminada bloquea la entrada que no es respuesta a una solicitud ni coincide con una regla de permiso, y permite la salida salvo que aplique algo como una regla de bloqueo. Estos son los valores predeterminados de Windows, y no garantizan que el administrador del cliente no los haya cambiado.²

Por ejemplo, si un cliente de pedidos se conecta al TCP 50051 del servidor de pedidos, quien acepta la conexión nueva es el lado del servidor. El cliente no abre un puerto de entrada con el mismo número para recibir las respuestas de esa conexión.²

Las canalizaciones con nombre remotas utilizan SMB. El SMB hospedado de forma directa habitual usa TCP 445, así que una regla de permiso para el exe de su propia aplicación no necesariamente lo resuelve. Distinga las canalizaciones con nombre locales del uso a través de la red. La autenticación y los permisos de acceso de SMB también hacen falta por separado.⁷⁸

El diagrama siguiente, partiendo del bloqueo de entrada predeterminado, sirve para localizar la parte que acepta conexiones desde otro equipo. «Regla de entrada obligatoria» significa que hace falta una configuración que permita la entrada; si las reglas de gestión existentes ya lo cubren, la aplicación no necesita añadir una regla duplicada. La comunicación que se queda en el mismo PC y la comunicación UDP se tratan aparte de este diagrama de conexiones TCP.

flowchart TB
    APP["Enumerar las comunicaciones de la propia app"] --> Q{"¿Abre un puerto<br/>y espera conexiones?"}
    Q -- "No espera<br/>(solo se conecta como cliente)" --> C1["Regla de entrada innecesaria en principio<br/>el retorno de la conexión pasa como «respuesta»"]
    Q -- "Espera conexiones<br/>(tipo servidor o recepción de callback)" --> S1["Regla de entrada obligatoria<br/>→ regístrela con el instalador (cap. 5)"]
    C1 -.-> EX["Excepción: en entornos de alta seguridad<br/>con salida bloqueada por defecto, solicite una regla de salida"]

En entornos donde el valor predeterminado de la salida se ha cambiado a bloqueo, o donde una regla prohíbe de forma explícita la salida de la aplicación, el lado que se conecta también necesita un permiso. No se puede decir a secas «es un cliente, así que el firewall no interviene».¹ Si quiere ordenar el propio modo de comunicación, consulte también cómo elegir la comunicación entre procesos.

2.1. Perfiles y «ubicación de red»

Las reglas llevan la condición de en qué perfiles de red están habilitadas. La forma típica de aplicarlas es la siguiente.²

La red a la que está conectado se puede comprobar con el siguiente comando. En un equipo con varios adaptadores o una VPN, coteje no solo el nombre, sino también la interfaz que usa la comunicación.²

Get-NetConnectionProfile |
    Select-Object InterfaceAlias, InterfaceIndex, NetworkCategory

Una regla limitada a dominio/privado no se aplica si la comunicación en cuestión pertenece al perfil público. Lo importante, no obstante, es no cambiar la red a privada ni ampliar la regla a todos los perfiles solo para que pase. Decida con el administrador hasta dónde se confía en la red del cliente y en qué perfiles se admite el uso.

2.2. Precedencia de las reglas

En las reglas habituales de permiso y bloqueo, un permiso explícito tiene prioridad sobre el bloqueo de entrada predeterminado, pero una regla de bloqueo explícita que coincide con la misma comunicación tiene prioridad sobre una regla de permiso en conflicto. No es un mecanismo en el que gane la que se añadió después.¹

Por eso, cuando «añadimos una regla de permiso y no cambia nada», mire si coinciden las condiciones del permiso y, además, las reglas de bloqueo que se aplican a la misma aplicación o al mismo puerto. Que exista una regla que detiene una comunicación ajena no detiene toda la comunicación de ese equipo. Las reglas especiales de omisión que usan autenticación IPsec son un diseño distinto de las reglas de permiso habituales de este artículo.

3. Qué es realmente el diálogo de «advertencia importante» — por qué no hay que confiárselo

Cuando una aplicación sin regla coincidente empieza a escuchar, según la configuración y el estado de ejecución aparece una notificación del tipo «Windows Defender Firewall ha bloqueado algunas características de esta aplicación». En un equipo de administración donde las notificaciones están deshabilitadas no se muestra, así que que no salga el aviso no es prueba de que la comunicación esté permitida.¹

El comportamiento que Microsoft describe cuando se muestra la notificación es el siguiente.¹

Si queda una regla creada por este mecanismo, al reiniciar la aplicación no se puede repetir la misma confirmación. En particular, si se creó una regla de bloqueo, añadir una regla de permiso puede no bastar. Tras comprobar de dónde sale cada regla y si hace falta, el administrador las ordena con un alcance limitado. La aplicación no debe eliminar una regla de bloqueo que la organización distribuyó de forma intencionada.

El diagrama siguiente muestra el flujo de creación de reglas a partir de la notificación. Las condiciones en las que la notificación aparece de verdad, y el texto de la pantalla, varían con el sistema operativo y la configuración de gestión.

flowchart TB
    L["La app empieza a escuchar un puerto"] --> Q1{"¿Hay una regla que<br/>coincida con esa app?"}
    Q1 -- "Sí" --> R1["Se sigue la regla<br/>(el diálogo no aparece)"]
    Q1 -- "No" --> Q2{"¿La notificación de entrada<br/>está habilitada?"}
    Q2 -- "Deshabilitada" --> R2["Se bloquea en silencio<br/>(no se crea ninguna regla)"]
    Q2 -- "Habilitada" --> DLG["Diálogo de «advertencia importante»"]
    DLG -- "El administrador elige «Permitir acceso»" --> OK["Se crea una regla de permiso"]
    DLG -- "El administrador elige «Cancelar»" --> NG1["Se crea una regla de bloqueo"]
    DLG -- "Usuario sin privilegios de administrador<br/>(cualquier operación)" --> NG2["Se crea una regla de bloqueo"]
    NG1 --> NEVER["Hasta que se elimine la regla<br/>el diálogo no vuelve a aparecer"]
    NG2 --> NEVER

Aunque se permita una vez en la implantación, las condiciones siguen ahí: otra función empieza a escuchar, cambia el perfil de red, una actualización cambia la ruta del exe. Inventariar primero la comunicación necesaria y preparar las reglas antes del primer inicio da una implantación más reproducible.¹

Para los equipos que usan no administradores, Microsoft recomienda colocar las reglas de antemano y deshabilitar las notificaciones de entrada. Las notificaciones se pueden controlar con Set-NetFirewallProfile -NotifyOnListen False o mediante directiva de grupo, pero eso es una decisión de quien gestiona la política de notificaciones de todo el equipo. No es motivo para que el instalador de una aplicación empresarial cambie, sin permiso, una configuración de notificación que también afecta a otras aplicaciones. Desactivar las notificaciones no permite la comunicación que hace falta.¹⁹

4. Diseño de las reglas de entrada — por programa, por puerto, por servicio

Empiece por escribir la especificación de comunicación separada en entrada/salida, TCP/UDP, puerto de espera, sujeto de ejecución, origen de la conexión y red que se usa. A partir de ahí combine las condiciones de la regla.¹⁰

Lo que se pasa a -Program es el exe que realmente se encarga de la comunicación, no un acceso directo ni un lanzador. Si quien escucha es otro servicio o un proceso anfitrión, el diseño tiene que coincidir con ese sujeto de ejecución. Aunque se usen puertos dinámicos, no abra de inmediato todos los puertos sin condiciones; considere hasta dónde se puede acotar por programa, servicio, origen, etc.¹⁰³

Además, limite las redes en uso con -Profile y el origen con -RemoteAddress. Por ejemplo, si los clientes de pedidos están en 172.16.10.0/24, especifique ese rango. LocalSubnet es una especificación usable en redes pequeñas, pero no significa que «todas las sedes de la empresa» o «el otro lado de la VPN» queden incluidos de forma automática. Compruebe la ruta real y la dirección de origen tal como la ve el lado que recibe.¹¹⁰

Una función que solo usa TCP no necesita que se permita UDP por si acaso. Y si una función limitada a la empresa se va a habilitar también en público, esté en condiciones de explicar por separado la necesidad y la restricción del origen. El punto de partida del diseño de reglas es dejar pasar solo la comunicación necesaria, del programa necesario, desde los interlocutores necesarios.

5. Registro práctico con el instalador — netsh y New-NetFirewallRule

5.1. Premisa: hacen falta privilegios de administrador

Registrar, cambiar o eliminar reglas de firewall de todo el equipo se ejecuta con privilegios de administrador elevados. Incluso un usuario del grupo Administrators no necesariamente se libra de la elevación de UAC.¹¹

Si coloca el registro en la fase elevada del instalador, la aplicación en sí no tiene que ejecutarse siempre como administrador. A la inversa, un instalador por usuario que termina por completo como usuario estándar no tiene permiso para cambiar las reglas de todo el equipo. En ese caso, convierta en requisito de implantación una instalación aparte por parte de un administrador, o la distribución de la regla desde la organización. Separe las situaciones en las que hacen falta privilegios de administrador de los privilegios que la aplicación necesita para la ejecución cotidiana.

Lo que sigue asume que su propio exe escucha en un puerto fijo y que el equipo permite que el instalador gestione reglas locales. No incluye ningún tratamiento que levante restricciones impuestas por la directiva de gestión.

5.2. Registro con netsh advfirewall

Con netsh se pueden especificar juntos el programa, el puerto TCP, el perfil y el origen, como sigue. Este es un ejemplo de primer registro en un equipo que aún no tiene la misma regla. Se asume la ejecución como archivo por lotes desde un símbolo del sistema iniciado como administrador.¹¹

@echo off
netsh advfirewall firewall add rule ^
  name="MyCompany OrderServer TCP 50051 In" ^
  dir=in action=allow enable=yes ^
  program="C:\Program Files\MyCompany\OrderServer\OrderServer.exe" ^
  protocol=TCP localport=50051 ^
  profile=domain,private remoteip=172.16.10.0/24
if errorlevel 1 exit /b 1

Repetir el mismo add rule no actualiza nada, y puede dejar cada vez más reglas con el mismo nombre. El método de eliminar y volver a crear tiene el problema de que, si el registro falla después de la eliminación, la regla desaparece. En un producto que repara y actualiza una y otra vez, se recomienda un diseño que fije un identificador y actualice la regla existente, como en el apartado siguiente.

El comando de retirada es otro. Ejecute la eliminación siguiente solo en la desinstalación; no la añada al final del lote de registro anterior. Afecta a las reglas que coinciden con el nombre, así que use un nombre que no choque con otros productos.¹¹

netsh advfirewall firewall delete rule name="MyCompany OrderServer TCP 50051 In"

Deje el código de salida y la salida de error en el registro del instalador, y distinga «falló el registro», «ya estaba eliminada» y «no hay permiso». También importa no mostrar al usuario que la preparación de la comunicación ha terminado cuando el registro ha fallado.

5.3. Registro con PowerShell (New-NetFirewallRule)

El módulo NetSecurity de PowerShell permite separar -Name, que identifica la regla, de -DisplayName, que se muestra en pantalla. Para el identificador del script use un -Name fijo, que no se ve afectado por el idioma de la interfaz ni por cambios de redacción.¹⁰

A continuación, un ejemplo para instalación, reparación y actualización que no multiplica reglas cuando se vuelve a ejecutar el mismo procesamiento. Usa Set-NetFirewallRule si la regla ya existe y New-NetFirewallRule si no. El parámetro para actualizar el nombre para mostrar es -NewDisplayName.¹²

# Para instalación, reparación y actualización. Ejecutar como administrador.
$ErrorActionPreference = "Stop"
$ruleName = "MyCompany-OrderServer-In"
$displayName = "MyCompany OrderServer (TCP 50051 entrada)"
$program = "C:\Program Files\MyCompany\OrderServer\OrderServer.exe"

if (-not (Test-Path -LiteralPath $program -PathType Leaf)) {
    throw "No existe el ejecutable: $program"
}

# Configuración de la regla local que posee este producto.
# Sustituya el origen y los perfiles por los valores acordados con el administrador del destino.
$settings = @{
    PolicyStore   = "PersistentStore"
    Direction     = "Inbound"
    Action        = "Allow"
    Enabled       = "True"
    Program       = $program
    Protocol      = "TCP"
    LocalPort     = 50051
    Profile       = @("Domain", "Private")
    RemoteAddress = "172.16.10.0/24"
}

# Distinguir «no hay regla» de un fallo de la propia consulta.
$existing = @(Get-NetFirewallRule -PolicyStore PersistentStore -ErrorAction Stop |
    Where-Object { $_.Name -eq $ruleName })

if ($existing.Count -eq 0) {
    New-NetFirewallRule -Name $ruleName -DisplayName $displayName @settings |
        Out-Null
} else {
    Set-NetFirewallRule -Name $ruleName -NewDisplayName $displayName @settings
}

Lo que este ejemplo cambia es solo la regla del PersistentStore cuyo nombre gestiona su empresa. No use el mismo identificador para otro fin. Y en un producto que más adelante añadió condiciones como el puerto de origen o un servicio, diseñe también de forma explícita la migración de esas condiciones. Set-NetFirewallRule no es un procesamiento que devuelva a su estado inicial todas las condiciones que no se especificaron.¹²

La eliminación se separa en el siguiente procesamiento exclusivo de la desinstalación. Si la regla de destino no existe no elimina nada, pero no oculta el fallo de la consulta o de la propia eliminación.⁵⁹

# Para desinstalación. No lo ejecute a continuación del registro.
$ErrorActionPreference = "Stop"
Get-NetFirewallRule -PolicyStore PersistentStore -ErrorAction Stop |
    Where-Object { $_.Name -eq "MyCompany-OrderServer-In" } |
    Remove-NetFirewallRule -ErrorAction Stop

Estos son ejemplos del procesamiento de registro, no una implementación de la transacción completa del instalador. Al incorporarlos al producto, confirme que un fallo del cambio de configuración se comunica al instalador, que un fallo de actualización puede volver a la versión y la configuración anteriores, y que la desinstalación elimina solo las reglas propias.

5.4. Cuando la actualización cambia la ruta del exe

Una regla por programa usa como condición la ruta registrada. Por ejemplo, aunque exista una regla para el exe de la carpeta v1.0, si tras la actualización escucha el exe de la carpeta v1.1, esa regla antigua ya no coincide con el exe nuevo.¹¹⁰

El diagrama siguiente cubre el caso en que se dependía solo de esa regla de la ruta antigua. No representa de forma uniforme los casos en que existe otra regla de permiso efectiva, ni las situaciones de ejecución en las que no aparece la notificación.

flowchart TB
    V1["Se instala v1.0<br/>la regla apunta al exe de la carpeta v1.0"] --> UP["La actualización lo coloca en la carpeta v1.1<br/>cambia la ruta del exe que se ejecuta"]
    UP --> MISS["La regla de la ruta antigua pierde el objetivo<br/>(la regla sigue ahí pero no surte efecto)"]
    MISS --> Q{"¿La notificación de entrada<br/>está habilitada?"}
    Q -- "Habilitada" --> DLG["El diálogo se vuelve a mostrar<br/>regla de bloqueo si un usuario general opera"]
    Q -- "Deshabilitada" --> SILENT["Ni siquiera sale el diálogo<br/>se bloquea en silencio"]
    MISS -.->|"Contramedida"| FIX["Fijar la ruta a lo largo de las actualizaciones<br/>o eliminar la regla antigua y volver a registrarla en la actualización"]

La contramedida es o bien fijar la ruta completa del exe a lo largo de las actualizaciones, o bien cambiar la regla a la ruta nueva en el paso de actualización. Con el método del apartado 5.3 se puede actualizar la regla del mismo -Name con la ruta nueva. Si elige eliminar la regla antigua y registrarla de nuevo, implemente también la restauración en caso de fallo, de modo que no quede solo un permiso amplio antiguo.

En MSI hay mecanismos que tratan las reglas de forma declarativa, como la extensión de firewall de WiX. Antes de lanzar comandos desde una acción personalizada propia, compruebe las condiciones que admite la herramienta que usa y cómo trata la actualización y la retirada.¹³ El criterio de cada forma de distribución se trata en cómo elegir el método de distribución de aplicaciones de Windows, y la detección del antivirus en falsos positivos de Microsoft Defender.

6. Resolución de problemas — flujo para acotar «no se puede comunicar»

Cuando llega una consulta, reúna primero origen y destino, el nombre o la dirección IP usados, TCP/UDP y el puerto, la hora del fallo y el error de la aplicación. Lo que sigue es el ejemplo de un servidor de pedidos que usa TCP. No mezcle los puntos que se investigan en el servidor con los que se prueban desde el origen real de la conexión.

El TcpTestSucceeded=True del diagrama significa que la conexión TCP al destino que se ensayó tuvo éxito. No garantiza que hayan tenido éxito la autenticación, el TLS ni el intercambio de datos de la aplicación, ni que esté permitida la salida de la aplicación empresarial, que es otro ejecutable.⁴

flowchart TB
    S["«No se puede comunicar desde el cliente»"] --> N["Lado del servidor: netstat -ano"]
    N -- "No está escuchando" --> APP["Problema anterior al firewall<br/>investigar el lado de la app o el servicio"]
    N -- "Está LISTENING" --> T["Lado del cliente: Test-NetConnection"]
    T -- "TcpTestSucceeded=True" --> OTHER["La alcanzabilidad es normal<br/>investigar la capa de la app (autenticación, protocolo)"]
    T -- "False" --> P["Lado del servidor: Get-NetConnectionProfile<br/>comprobar el perfil en vigor"]
    P -- "No coincide con el alcance de la regla" --> FIXP["Revisar la especificación de perfil de la regla"]
    P -- "Coincide" --> R["Get-NetFirewallRule -PolicyStore ActiveStore<br/>comprobar si hay reglas de permiso y reglas de bloqueo mezcladas"]
    R --> LOGCHK["Medir los descartes (DROP) en pfirewall.log"]

1. En la espera, mire no solo el puerto, sino también la dirección y el proceso. Aunque esté LISTENING, si solo está enlazado a 127.0.0.1 o ::1 no es una espera a la que otro equipo pueda conectarse tal cual. Compruebe si espera en la dirección LAN de destino y si otro proceso no usa el mismo puerto. Coteje el PID de netstat -ano con el Administrador de tareas u otra herramienta y, con los privilegios necesarios, netstat -abno también muestra el ejecutable. Compruebe IPv4 e IPv6 por separado.³

2. El ensayo de conexión TCP se hace desde el origen real de la conexión. En el ejemplo siguiente, compruebe RemoteAddress, SourceAddress, InterfaceAlias y TcpTestSucceeded.⁴

# Ejecutar en el cliente. Sustituya el nombre y el puerto por los del entorno real.
Test-NetConnection -ComputerName sv01 -Port 50051 -InformationLevel Detailed

Un False no establece que la causa sea el firewall de Windows. La resolución de nombres, el destino, la ruta, una VPN, los equipos de red y el control de comunicación de otro producto también son candidatos. A la inversa, si es True, confirme primero que el destino es el servidor que pretendía y, a partir de ahí, mire la configuración de destino de la aplicación empresarial, la autenticación y el protocolo. Un ensayo con dirección IP sirve para comparar la alcanzabilidad TCP, pero no necesariamente se comporta igual que la autenticación o la validación de certificados que usan el nombre. El -Port de este cmdlet es un ensayo TCP y no se usa para decidir el éxito o el fallo de UDP.⁴

3. El perfil y 4. las reglas se comprueban en la configuración que realmente se aplica. El destino predeterminado de Get-NetFirewallRule es el almacén persistente local. Para ver la directiva actual, incluida la que viene de GPO, especifique -PolicyStore ActiveStore. Compruebe no solo que la regla existe, sino también la configuración del lado del perfil.⁵¹⁴

# En el servidor, ejecutar como administrador.
Get-NetConnectionProfile |
    Select-Object InterfaceAlias, InterfaceIndex, NetworkCategory

Get-NetFirewallProfile -PolicyStore ActiveStore |
    Select-Object Name, Enabled, DefaultInboundAction, DefaultOutboundAction,
        AllowInboundRules, AllowLocalFirewallRules

$rules = @(Get-NetFirewallRule -PolicyStore ActiveStore -TracePolicyStore |
    Where-Object { $_.Enabled -eq "True" -and $_.Direction -eq "Inbound" })

$rules | Select-Object Name, DisplayName, Action, Profile,
    PolicyStoreSourceType, PolicyStoreSource

En una configuración donde AllowInboundRules está deshabilitado, añadir una regla de permiso no basta para permitir la entrada. Si las reglas locales se aplican o no se juzga junto con la directiva de gestión del capítulo 7. En valores no configurados como NotConfigured, no concluya permiso o denegación solo a partir de esa cadena; confirme la configuración efectiva con el administrador.¹⁵

El programa, el puerto y la dirección están en los objetos de filtro asociados a la regla. En el ejemplo siguiente se muestran las condiciones de la regla propia. Para $rules use lo que recuperó el comando anterior.^5161718

$targetRules = @($rules | Where-Object { $_.Name -eq "MyCompany-OrderServer-In" })
$targetRules | Get-NetFirewallApplicationFilter | Select-Object Program
$targetRules | Get-NetFirewallPortFilter | Select-Object Protocol, LocalPort, RemotePort
$targetRules | Get-NetFirewallAddressFilter | Select-Object LocalAddress, RemoteAddress

# Incluya también en la investigación las reglas de bloqueo con un nombre distinto al de la regla propia.
$rules | Where-Object { $_.Action -eq "Block" } |
    Select-Object Name, DisplayName, Profile, PolicyStoreSourceType, PolicyStoreSource

En las reglas de bloqueo, compruebe los filtros de las reglas candidatas de la misma manera. Si hay especificación de servicio, investigue también esa condición con Get-NetFirewallServiceFilter u otro cmdlet. Una búsqueda de coincidencia exacta como LocalPort -eq 50051 se deja fuera las reglas que especifican Any o un rango de puertos. No concluya «no salió en la búsqueda, así que no hay regla en conflicto».¹⁷⁵

5. El registro se reproduce después de habilitar la grabación. El registro del firewall, de forma predeterminada, no registra ni los permisos ni los descartes. El destino predeterminado es %windir%\system32\logfiles\firewall\pfirewall.log y el tamaño máximo predeterminado es 4.096 KB. Empiece por comprobar la configuración del perfil de destino y el destino real.⁶

# En el servidor. De momento solo leer, sin cambiar la configuración.
Get-NetFirewallProfile -PolicyStore ActiveStore |
    Select-Object Name, LogBlocked, LogAllowed, LogFileName, LogMaxSizeKilobytes

Si el registro de descartes está deshabilitado, con la aprobación del administrador habilítelo solo en el perfil de destino, por ejemplo con Set-NetFirewallProfile -Profile Private -LogBlocked True. Aquí Private es un ejemplo. Registre la configuración anterior y, tras la investigación, restáurela. Si la configuración está gestionada de forma centralizada, que la cambie el lado de gestión; no hace falta empezar registrando en masa la comunicación permitida ni cambiando todos los perfiles.⁹⁶

Si hay un DROP que coincide con la hora de reproducción, la IP de origen, la IP de destino, el protocolo y el puerto, puede confirmar que esa comunicación se descartó. Ahora bien, la ausencia de esa línea, por sí sola, no establece que «el paquete no llegó». Confirme antes si se aplica la configuración de registro, si no está mirando otro destino, si el archivo se actualiza y si no hay un problema de permiso de escritura. Combine con una captura de paquetes u otro medio si hace falta. Cuando no se crea el archivo de registro, siga el procedimiento de Microsoft también para la carpeta y los permisos de mpssvc.⁶

Si hay que investigar más, los eventos de auditoría 5152 y 5157 de Windows Filtering Platform son candidatos. La auditoría por paquete genera una gran cantidad de eventos, así que Microsoft orienta al 5157 por conexión para supervisar las conexiones bloqueadas. Confirme con el administrador la directiva de auditoría y el volumen de registros, y acote el alcance y el período a lo necesario.¹⁹

No convierta la desactivación del firewall en el primer medio de comprobación ni en una medida permanente. En particular, detener el servicio MpsSvc no está admitido por Microsoft. Incluso cuando un administrador hace un ensayo de comparación en un entorno de prueba aislado, deje el servicio en ejecución, limite el cambio al perfil de destino y haga obligatoria la restauración de la configuración original. Lo que la producción necesita es una corrección de la configuración acorde a la causa, no quitar la defensa por completo.²

7. Precauciones bajo gestión de la organización — entornos donde las reglas locales no surten efecto, y cómo solicitarlas

En un entorno donde el firewall se gestiona de forma centralizada con GPO o Intune, se puede deshabilitar por perfil la «fusión de reglas locales». En ese caso, aunque el instalador pueda crear la regla en el almacén persistente local, no se aplica como configuración que permita la comunicación. El éxito del registro y el reflejo en la directiva efectiva son cosas distintas.¹

Las «reglas creadas en local» del diagrama son las reglas locales habituales como las que se crean en el PersistentStore del capítulo 5. Se tratan de forma distinta de las reglas configuradas con la directiva de grupo local. Esto no es un asunto de escribir en otro almacén para eludir la restricción; es una distinción para unificar el origen de distribución con el administrador del cliente.¹

flowchart TB
    GPOR["Reglas distribuidas por GPO/Intune"] --> EFF["Conjunto de reglas que realmente surten efecto<br/>(ActiveStore)"]
    LOCAL["Reglas creadas en local<br/>(incluido el registro del instalador)"] --> Q{"Fusión de reglas locales<br/>(AllowLocalPolicyMerge)"}
    Q -- "Habilitada (predeterminado)" --> EFF
    Q -- "Deshabilitada" --> DROP["La regla existe pero no se aplica<br/>→ pasar a la distribución centralizada por GPO/CSP"]

En este entorno, en lugar de recrear una y otra vez reglas locales, pida al departamento de sistemas que distribuya la regla. El instalador debe distinguir si gestiona él mismo la regla o si presupone la distribución desde el lado de gestión, y diseñarse de modo que no cambie por su cuenta la política de gestión.

La solicitud debe reunir, como mínimo, la información siguiente. Abran el TCP 50051 por sí solo no decide de qué equipo, de quién es la comunicación ni hasta dónde llega el permiso.

No termine la prueba de implantación solo con conexiones desde el equipo de desarrollo o desde el propio servidor; hágalo en el lugar de uso real y con los privilegios reales. Si hay varias rutas, como a través de VPN, compruebe cada una. Si la autenticación falla después de que la conexión TCP haya pasado, avance a una investigación distinta del firewall. Para los temas relacionados de autenticación y protección de la comunicación, consulte también firma SMB y enlace de canal LDAP.

8. Resumen

La respuesta al firewall de Windows no termina con «permitirlo en el aviso» o «abrir un puerto». El punto de partida es enumerar las direcciones de comunicación de la aplicación, diseñar juntas el programa, el puerto, el origen y el perfil, y colocar la configuración necesaria antes del primer inicio.¹¹⁰

Si se permite la gestión local, incluya el registro, la actualización y la eliminación en el ámbito de responsabilidad del instalador. Si se gestiona con GPO o Intune, entregue la misma especificación de comunicación al administrador para que la distribuya. Ponga como condición de implantación terminada no que se haya podido crear la regla, sino que se pueda comunicar con el interlocutor previsto y con la aplicación real, y que no se haya permitido un alcance innecesario.

Cuando no se puede comunicar, compruebe en orden la dirección de espera y el sujeto de ejecución, la conexión TCP, el perfil, la directiva efectiva y el registro de descartes. En lugar de saltar a «no conecta, así que es el firewall» o «no hay registro, así que no llegó», separar lo que cada resultado ha dejado claro de lo que aún no se sabe deja claro el siguiente lugar que hay que investigar.

Artículos relacionados

• Cómo elegir la comunicación entre procesos en Windows — canalizaciones con nombre / TCP / gRPC / memoria compartida / COM: tabla de decisión
• Cómo elegir el método de distribución de aplicaciones de Windows - MSI/MSIX/ClickOnce/xcopy/actualizador propio
• Cuándo se necesita el privilegio de administrador en Windows - UAC, áreas protegidas y cómo distinguirlo por diseño
• Cuando su aplicación Windows de desarrollo propio es tratada como virus — cómo abordar los falsos positivos de Microsoft Defender y su impacto en el rendimiento
• Firma SMB y enlace de canal LDAP — cerrar en la práctica «la otra mitad» de las medidas contra NTLM
• Cómo crear y operar un servicio de Windows — de la diferencia con el Programador de tareas a la creación de servicios con BackgroundService

Áreas de consultoría relacionadas

En KomuraSoft LLC, además del desarrollo de aplicaciones empresariales para Windows, nos ocupamos del diseño de instaladores que incluyen reglas de firewall, de la investigación de la causa de los problemas de comunicación en el cliente y de la consultoría técnica para el despliegue bajo gestión de la organización. En la consulta, si hay origen y destino, modo de comunicación, procedimiento de reproducción y errores o registros, se puede concretar el alcance de la investigación.

• Desarrollo de aplicaciones Windows
• Investigación de fallos y análisis de causas
• Consultoría técnica y revisión de diseño
• Contacto

Referencias

Artículos relacionados

Artículos recientes con las mismas etiquetas para profundizar en temas cercanos.

Temas relacionados

Estas páginas sitúan el tema en un contexto más amplio de servicios y decisiones.

Servicios relacionados con este tema

El artículo está directamente relacionado con los siguientes servicios.

Preguntas frecuentes

Preguntas habituales en las consultas sobre el tema del artículo.

¿También necesitan una regla de firewall las aplicaciones que solo se conectan a un servidor como cliente?

En un entorno con la salida permitida de forma predeterminada, una aplicación que solo inicia conexiones y recibe las respuestas de esas conexiones no suele necesitar una regla de entrada propia. Eso cambia si una directiva de la organización restringe la salida o existe una regla de bloqueo explícita. Además, incluso una aplicación llamada cliente necesita permitir la entrada en la parte que espera llamadas de retorno o notificaciones desde otro equipo. Decida según la dirección real de la comunicación, no según el nombre de la aplicación.

¿No basta con pulsar «Permitir acceso» en el diálogo «Advertencia importante de seguridad de Windows»?

Es más seguro no hacer que el procedimiento de implantación en producción dependa solo de esa operación. Según la explicación de Microsoft, se crea una regla de bloqueo cuando el administrador que ve la notificación cancela, o cuando responde un usuario que no es administrador. Añadir después una regla de permiso no deja pasar el tráfico mientras exista una regla de bloqueo en conflicto. Coloque las reglas necesarias antes del primer inicio, desde el instalador o a través del administrador de la organización.

¿Las reglas de entrada deben crearse especificando el puerto o el programa?

Para una aplicación propia que escucha en un puerto fijo, lo básico es combinar la ruta completa del programa con el protocolo y el puerto local, y acotar la IP remota y el perfil al rango realmente necesario. Hay que ajustar según la configuración: puertos dinámicos o ejecución como servicio, por ejemplo. Con una regla por programa, el proceso de actualización debe reflejar el cambio de ruta del ejecutable, y no cree a la ligera un permiso amplio solo por puerto.

La regla que registró el instalador parece no surtir efecto en el PC del cliente. ¿Por qué?

El éxito del registro de la regla, por sí solo, no permite afirmar que la comunicación está permitida. Compruebe la dirección de espera, la ruta del ejecutable, el perfil, la IP de origen y las reglas de bloqueo en conflicto. Además, si GPO o Intune tienen deshabilitada la fusión de reglas locales, la regla que creó el instalador no se aplica. En ese caso no eluda la directiva de gestión: pase a que el departamento de sistemas distribuya la regla.

¿Se puede desactivar el firewall temporalmente para diagnosticar un problema de comunicación?

Investigue primero con la espera, la directiva efectiva y el registro de descartes. No convierta la desactivación de todo el firewall en una medida habitual y, en particular, evite detener el servicio MpsSvc, que Microsoft no admite. Incluso cuando un administrador necesite desactivarlo temporalmente en un entorno de prueba aislado, deje el servicio en ejecución, limite el cambio al perfil de destino, registre la configuración anterior y restáurela de inmediato.

Perfil del autor

Página de presentación del autor del artículo.

Go Komura

Representante de KomuraSoft LLC

Especializado en desarrollo de software para Windows, consultoría técnica e investigación de fallos, sobre todo en proyectos con sistemas existentes y errores difíciles de reproducir.