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

«Funciona sin problemas en el equipo de desarrollo, pero al instalarlo en el cliente este no logra conectarse con el servidor», «al primer inicio apareció una advertencia y, según parece, alguien en el sitio pulsó Cancelar», «con netstat se ve que el puerto está escuchando, pero desde el equipo de al lado no llega nada» — en el terreno de la implantación de aplicaciones empresariales, este tipo de consulta sobre «no se puede comunicar» es de lo más habitual. Y entre las causas más frecuentes sigue instalado, año tras año, el firewall de Windows (Windows Defender Firewall).

Lo complicado es que en el equipo de desarrollo el problema no se ve. Allí, durante la depuración con Visual Studio uno mismo pulsa «permitir», o directamente trabaja como administrador, así que nunca llega a notar el bloqueo de entrada por defecto y termina enviando la aplicación así. En el sitio del cliente, en cambio, quien la opera es un usuario normal sin privilegios de administrador y la red está gestionada por GPO. No es que «algo que debería funcionar no funcione»: la realidad es que «el equipo de desarrollo funcionaba por casualidad».

Este artículo se dirige a los desarrolladores de aplicaciones empresariales propias que se enfrentan a «no se puede comunicar en el cliente», y al personal de sistemas de pequeñas y medianas empresas que recibe esas consultas. A partir de fuentes primarias vigentes en agosto de 2026, repasamos primero lo mínimo indispensable sobre el comportamiento predeterminado del firewall de Windows y el mecanismo de los perfiles, y luego organizamos el diseño de las reglas de entrada, el registro práctico mediante el instalador, el procedimiento de diagnóstico y las precauciones bajo gestión con GPO/Intune.

1. La conclusión primero

• El comportamiento predeterminado del firewall de Windows es «bloquear la entrada y permitir la salida». El tráfico de entrada que no sea una respuesta a una solicitud se descarta salvo que coincida con una regla.¹
• Las reglas de entrada solo son necesarias para las aplicaciones de tipo servidor que escuchan un puerto. Las aplicaciones cliente que solo se conectan hacia afuera pueden comunicarse con la configuración predeterminada. Empiece siempre por hacer esta distinción.¹
• Hay tres perfiles (dominio, privado y público). El de dominio se aplica automáticamente al detectar un controlador de dominio, y el público es el predeterminado para redes no identificadas. Las reglas se activan o desactivan por perfil.¹
• No confíe la producción a ese cuadro de diálogo de «advertencia importante». Si un administrador pulsa Cancelar se crea una regla de bloqueo, y con un usuario sin privilegios de administrador se crea una regla de bloqueo sin importar qué botón pulse. El diálogo no vuelve a aparecer hasta que se elimina la regla creada.²
• La conclusión es: «registre las reglas de entrada de la aplicación empresarial mediante el instalador». El propio Microsoft recomienda colocar las reglas antes del primer inicio y desactivar la notificación de entrada.²
• Diseñe las reglas con el mínimo privilegio. Tome como eje programa + protocolo + puerto, limite el perfil a dominio/privada y acote la IP remota a la subred necesaria. La ruta del programa no admite comodines.²³
• El diagnóstico sigue el orden Test-NetConnection → Get-NetFirewallRule → pfirewall.log. El registro del firewall no se escribe por defecto; solo aparece tras activar el registro de paquetes descartados.⁴⁵⁶
• Desactivar todo el firewall deteniendo el servicio no es una operación admitida. Bajo gestión de GPO/Intune, la «fusión de reglas locales» puede estar desactivada, en cuyo caso las reglas locales no surten efecto. En ese caso, solicite al departamento de sistemas la distribución centralizada de la regla.¹²

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

Empecemos por fijar la base con precisión. El firewall de Windows es un firewall basado en host activado por defecto en todas las ediciones, y su comportamiento predeterminado se resume en estas dos líneas.¹

• Entrada (inbound): se bloquea todo, salvo que sea una respuesta a una solicitud (solicited) o coincida con una regla
• Salida (outbound): se permite todo, salvo que coincida con una regla

De estas dos líneas se desprende la distinción más importante para una aplicación empresarial: las reglas de entrada solo son necesarias para el «lado que escucha».

• Una aplicación cliente que solo se conecta por sí misma a un servidor web, un servidor de base de datos o un sistema troncal interno → en principio no necesita reglas. Los paquetes de retorno de la conexión pasan por defecto porque son «respuesta a una solicitud».
• Una aplicación o servicio de Windows de tipo servidor que abre un puerto y espera conexiones mediante TCP, gRPC u otro protocolo propio → necesita reglas de entrada obligatoriamente.
• Además, el uso remoto de canalizaciones con nombre (named pipes) es una excepción: una canalización con nombre remota no pasa por el puerto propio de la aplicación sino a través de SMB (TCP 445), por lo que lo que se necesita no es una regla de la aplicación, sino una regla del lado del recurso compartido de archivos (SMB).
• La excepción son los entornos de alta seguridad que cambian explícitamente la salida predeterminada a bloqueada. Esta configuración solo existe en algunas organizaciones, pero en ese caso incluso las aplicaciones cliente necesitan solicitar una regla de salida.²

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"]

El caso de «una aplicación que se suponía cliente pero en realidad también escucha» (recepción de callbacks de resultados, puerto de recepción de notificaciones de otros procesos, etc.) es fácil de pasar por alto. Si no tiene claro con qué método de comunicación escucha su propia aplicación, revise también, como ordenación en la fase de diseño, «Cómo elegir la comunicación entre procesos en Windows».

2.1. Los perfiles y la “ubicación de red”

Las reglas se aplican por perfil de red. Hay tres perfiles.¹

Puede comprobar qué perfil está aplicado en cada momento con Get-NetConnectionProfile, y cambiar entre privado y público con Set-NetConnectionProfile.¹ Un incidente frecuente en el terreno es que la red del cliente, en un entorno de grupo de trabajo (workgroup), se clasifica como «pública» y las reglas de entrada creadas limitándolas a dominio/privada no se aplican. Cuando «la regla existe pero no pasa», sospeche primero de la coincidencia de perfil antes que del contenido de la regla.

2.2. El orden de prioridad de las reglas

Cuando hay varias reglas, la evaluación no sigue una lista ordenada por pesos, sino estos principios coherentes.²

1. Una regla explícita de permiso tiene prioridad sobre el bloqueo predeterminado
2. Una regla explícita de bloqueo tiene prioridad sobre una regla de permiso en conflicto
3. Dentro de lo que no contradiga el punto 2, la regla más específica tiene prioridad

La implicación práctica es que «si en algún lugar hay una sola regla de bloqueo, ninguna cantidad de reglas de permiso que añada después podrá vencerla». Como veremos en el próximo capítulo, es precisamente esa regla de bloqueo la que ese diálogo crea silenciosamente.

3. Qué es realmente el cuadro de diálogo “Advertencia importante” — por qué no se le puede confiar

Cuando una aplicación empieza a escuchar (listen) un puerto por primera vez, si no existe ninguna regla de permiso ni ninguna regla definida por el administrador para esa aplicación, Windows muestra el conocido cuadro de diálogo «Advertencia importante de seguridad de Windows», con el mensaje «Algunas características de esta aplicación están bloqueadas por Firewall de Windows Defender». El comportamiento está claramente especificado.²

• Cuando se muestra a un usuario con privilegios de administrador: al pulsar «Permitir acceso» se crea una regla de permiso. Pero si pulsa «Cancelar», se crea una regla de bloqueo, normalmente dos: una para TCP y otra para UDP.
• Cuando se muestra a un usuario sin privilegios de administrador: se crea una regla de bloqueo sin importar la opción que elija.
• En ambos casos, el diálogo no vuelve a mostrarse hasta que se elimina la regla creada, y la comunicación sigue bloqueada.

flowchart TB
    L["La app empieza a escuchar un puerto"] --> Q1{"¿Existe una regla<br/>que coincida con esa app?"}
    Q1 -- "Sí" --> R1["Se aplica la regla<br/>(no aparece el diálogo)"]
    Q1 -- "No" --> Q2{"¿Está activada<br/>la notificación de entrada?"}
    Q2 -- "Desactivada" --> R2["Bloqueo silencioso<br/>(no se crea ninguna regla)"]
    Q2 -- "Activada" --> DLG["Diálogo «Advertencia importante»"]
    DLG -- "Administrador pulsa «Permitir acceso»" --> OK["Se crea una regla de permiso"]
    DLG -- "Administrador pulsa «Cancelar»" --> NG1["Se crea una regla de bloqueo"]
    DLG -- "Usuario sin privilegios de administrador<br/>(cualquier opció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

En otras palabras, este diálogo parece un «mecanismo para pedir permiso al usuario», pero en el terreno de las aplicaciones empresariales funciona como «un mecanismo que graba a fuego una regla de bloqueo en el instante en que lo toca un usuario general». Si la persona a cargo de la implantación inicia la aplicación por primera vez con una cuenta de administrador y permite el acceso en el diálogo, la regla de permiso creada afecta a todo el equipo, así que los usuarios generales podrán comunicarse desde el día siguiente sin problema. Aun así, quedan riesgos: cuando un usuario general es el primero en tocar un punto de escucha que no se probó durante la verificación de la implantación, cuando el perfil de red aplicado difiere del de la implantación, y cuando una actualización cambia la ruta del exe (capítulos 4 y 5).

El propio Microsoft indica explícitamente las siguientes prácticas recomendadas para los dispositivos que usan personas sin privilegios de administrador.²

1. Colocar las reglas necesarias antes del primer inicio de la aplicación (mediante el instalador o la distribución desde el lado de administración)
2. Desactivar la notificación de entrada (al apagar la notificación, deja de producirse la creación automática de reglas en tiempo de ejecución)

La notificación se puede desactivar con Set-NetFirewallProfile -NotifyOnListen False, o mediante directiva de grupo.⁷ «Cuando aparezca el diálogo, que alguien del sitio pulse permitir» no es un procedimiento operativo: es una reserva de incidente. Registrar las reglas de entrada en el momento de la instalación — esa es la conclusión de este artículo, y coincide con la recomendación de Microsoft.

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

Diseñemos el contenido de las reglas que se van a registrar. Hay tres grandes formas de especificarlas, y hay que decidir si se usan por separado o combinadas.

Sobre esa base, se van sumando límites de alcance. La propia recomendación de diseño de Microsoft es «las reglas de entrada deben ser lo más específicas posible».²

• Limitar el perfil: para una aplicación empresarial que solo se usa dentro de la empresa, limite la regla de entrada a dominio/privada y no la active en público. Esto evita el incidente de que, en el instante en que un portátil se conecta a un Wi-Fi externo, el puerto de escucha quede abierto a todo el mundo.
• Limitar la IP remota: si el origen de la conexión está determinado, acote -RemoteAddress a esa subred. Para redes domésticas o pequeñas se recomienda limitarlo con la palabra clave LocalSubnet.²³
• Dirección y cantidad: si la escucha es solo TCP, basta con una única regla TCP. No cree por inercia reglas para TCP y UDP a la vez, como hace automáticamente el diálogo.

«Solo del interlocutor necesario, hacia el puerto necesario, para el programa necesario» — el diseño de las reglas de entrada se resume en esta única frase de mínimo privilegio.

5. El registro práctico mediante el instalador — netsh y New-NetFirewallRule

5.1. Premisa: se requieren privilegios de administrador

Agregar o eliminar reglas de firewall es un cambio de configuración de todo el equipo, así que debe ejecutarse con privilegios de administrador (un proceso elevado).⁸ Como el instalador normalmente ya se ejecuta con privilegios de administrador, tiene sentido colocar el registro de reglas dentro del proceso de instalación. Esto no es motivo para ejecutar la propia aplicación como administrador. Este criterio de separación se trata en detalle en «Cuándo se necesitan privilegios de administrador en Windows».

5.2. Registro con netsh advfirewall

Un método clásico, pero fácil de invocar desde cualquier instalador, es netsh advfirewall firewall add rule.⁸

rem add rule agrega una regla aunque ya exista una con el mismo nombre, así que
rem para prepararse ante reinstalaciones, reparaciones y actualizaciones, se
rem elimina la regla homónima antes de volver a registrarla
netsh advfirewall firewall delete rule name="MyCompany OrderServer"

rem Regla de entrada permitida: programa + puerto + perfil limitado
netsh advfirewall firewall add rule name="MyCompany OrderServer" dir=in action=allow program="C:\Program Files\MyCompany\OrderServer\OrderServer.exe" protocol=TCP localport=50051 profile=domain enable=yes

rem Al desinstalar: eliminar por nombre
netsh advfirewall firewall delete rule name="MyCompany OrderServer"

add rule no reemplaza una regla existente con el mismo nombre, sino que la añade conservando el nombre, así que si no ejecuta antes delete rule, las reglas se multiplican en cada reejecución, y tras una actualización que cambie la ruta o el alcance, la regla de permiso antigua sigue viva (en la primera ejecución, el delete rule inicial devuelve un mensaje de «no hay ninguna regla coincidente», pero la ejecución del lote continúa, así que este orden no da problemas; si el resultado de éxito o fracaso del instalador se determina por el código de salida, vigile el resultado del add rule final). Con remoteip=157.60.0.1,172.16.0.0/16,LocalSubnet también puede acotar el origen de la conexión.⁸ Como la eliminación borra en bloque todas las reglas que coinciden por nombre, lo más seguro es que el nombre de la regla lleve el prefijo de la propia empresa y sea único.

5.3. Registro con PowerShell (New-NetFirewallRule)

Para un control más fino, está el módulo NetSecurity. -DisplayName es obligatorio, y -Profile admite varios valores separados por comas (sin espacios).³

# Registro (se ejecuta desde el instalador con privilegios elevados). Como
# -Name es un identificador único, reinstalar/reparar/actualizar con el mismo
# nombre falla si la regla ya existe: se elimina la homónima antes de recrearla
Remove-NetFirewallRule -Name "MyCompany-OrderServer-In" -ErrorAction SilentlyContinue
New-NetFirewallRule -Name "MyCompany-OrderServer-In" `
    -DisplayName "MyCompany OrderServer (entrada TCP 50051)" `
    -Direction Inbound -Action Allow `
    -Program "C:\Program Files\MyCompany\OrderServer\OrderServer.exe" `
    -Protocol TCP -LocalPort 50051 `
    -Profile Domain,Private -RemoteAddress LocalSubnet

# Al desinstalar: no genera error si la regla no existe
Remove-NetFirewallRule -Name "MyCompany-OrderServer-In" -ErrorAction SilentlyContinue

Especificar -Name explícitamente aquí tiene una razón. -Name es el identificador único de la regla; si se omite, se asigna un valor aleatorio. Como el nombre visible (-DisplayName) puede variar según la configuración regional, Microsoft indica que el script debe usar -Name como clave para identificar la regla.³ Considere que fijar -Name es imprescindible también para que el desinstalador elimine con certeza solo sus propias reglas.

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

Una regla especificada por programa fija su objetivo mediante la ruta completa. Es decir, si una actualización cambia la carpeta de instalación o el nombre del exe, la regla sigue existiendo pero pierde su objetivo, y la escucha vuelve a quedar bloqueada. En ese momento, el exe de la nueva ruta se trata como «una aplicación sin regla», así que en entornos donde la notificación está activada reaparece el diálogo del capítulo 3, y si un usuario general lo toca, se graba a fuego una regla de bloqueo. En entornos donde la notificación está desactivada, como recomienda el capítulo 3, el fallo ocurre en silencio, sin que aparezca ni siquiera el diálogo. Es un incidente especialmente propenso a ocurrir en esquemas que colocan los archivos en carpetas con número de versión, o en esquemas de auto-actualización donde el destino de instalación se mueve.

flowchart TB
    V1["Se instala v1.0<br/>la regla apunta al exe de la carpeta v1.0"] --> UP["La actualización la coloca en la carpeta v1.1<br/>la ruta del exe ejecutado cambia"]
    UP --> MISS["La regla de la ruta antigua pierde su objetivo<br/>(sigue existiendo pero ya no surte efecto)"]
    MISS --> Q{"¿Está activada<br/>la notificación de entrada?"}
    Q -- "Activada" --> DLG["Reaparece el diálogo<br/>si lo toca un usuario normal, se crea una regla de bloqueo"]
    Q -- "Desactivada" --> SILENT["Bloqueo silencioso<br/>sin que aparezca el diálogo"]
    MISS -.->|"Solución"| FIX["Fijar la ruta a través de las actualizaciones,<br/>o hacer que la actualización elimine y vuelva a registrar la regla antigua"]

La solución es sencilla; consiste en una de estas dos opciones.

• Fijar el destino de instalación de modo que la ruta completa del exe no cambie a través de las actualizaciones
• En actualizaciones donde la ruta sí cambia, hacer que el actualizador elimine la regla antigua y la vuelva a registrar con la nueva ruta (ejecutar también los comandos de 5.2/5.3 en el proceso de actualización)

Si se trata de un MSI, lo habitual es incorporar el registro de la regla como una acción personalizada que se ejecuta después de colocar los archivos (y, para la desinstalación, como la acción personalizada del lado de eliminación). Conjuntos de herramientas como WiX también tienen extensiones para describir reglas de firewall de forma declarativa. Como el punto de implementación varía según la forma de distribución elegida, consulte también «Cómo elegir la forma de distribución de una aplicación de Windows». Además, otro problema clásico al desplegar en el cliente, los falsos positivos del antivirus, se trata en «Cómo responder a los falsos positivos de Microsoft Defender».

6. Solución de problemas — el flujo de diagnóstico de “no se puede comunicar”

Fijemos de antemano, en orden, el procedimiento a seguir al recibir una consulta. El flujo general es el siguiente.

flowchart TB
    S["«No se puede comunicar desde el cliente»"] --> N["Lado servidor: netstat -ano"]
    N -- "No está escuchando" --> APP["Problema previo al firewall<br/>investigar la app o el servicio"]
    N -- "Está en LISTENING" --> T["Lado cliente: Test-NetConnection"]
    T -- "TcpTestSucceeded=True" --> OTHER["Accesibilidad normal<br/>investigar la capa de aplicación (autenticación, protocolo)"]
    T -- "False" --> P["Lado servidor: Get-NetConnectionProfile<br/>confirmar el perfil aplicado"]
    P -- "No coincide con el objetivo de la regla" --> FIXP["Revisar el perfil especificado en la regla"]
    P -- "Coincide" --> R["Get-NetFirewallRule -PolicyStore ActiveStore<br/>confirmar si hay regla de permiso y si se coló alguna de bloqueo"]
    R --> LOGCHK["Comprobar el descarte (DROP) en pfirewall.log"]

Un apunte sobre el paso 4. Como las condiciones de puerto y programa no están en la propia regla sino en el objeto de filtro, para buscar la regla a partir del puerto hay que consultarla a través del filtro.⁵⁷

# Buscar en sentido inverso las reglas relacionadas con el puerto 50051
Get-NetFirewallPortFilter | Where-Object { $_.LocalPort -eq 50051 } | Get-NetFirewallRule

# Rastrear el origen de la regla (local o GPO)
Get-NetFirewallRule -PolicyStore ActiveStore -TracePolicyStore |
    Select-Object Name, DisplayName, PolicyStoreSourceType, PolicyStoreSource

El registro del firewall (pfirewall.log) del paso 5 no registra nada por defecto. La ruta predeterminada es %windir%\system32\logfiles\firewall\pfirewall.log, el tamaño máximo predeterminado es de 4096 KB, y solo empieza a escribirse tras activar «registrar los paquetes descartados» o «registrar las conexiones correctas».⁶ En una sola máquina puede activarlo así.⁶

netsh advfirewall set allprofiles logging droppedconnections enable
netsh advfirewall set allprofiles logging allowedconnections enable

El registro es un archivo de texto donde se anota, línea por línea, si se descartó (DROP) o se permitió (ALLOW), el protocolo, y la IP y el puerto de origen y destino, lo que permite confirmar con certeza si «el SYN del cliente llega y se descarta, o directamente no llega». Tenga en cuenta que, en entornos donde el registro se configura por directiva, puede faltar el permiso de escritura en la carpeta del registro (Control total para el servicio mpssvc) y el archivo no llegar a crearse; en ese caso hay que crear la carpeta y asignar la ACL manualmente.⁶

Para profundizar aún más, si activa la directiva de auditoría «Auditar el descarte de paquetes de la plataforma de filtrado», cada descarte queda registrado como el evento de seguridad 5152. Sin embargo, el volumen de eventos es muy alto, por lo que Microsoft recomienda usar el evento 5157 (conexión de la plataforma de filtrado), que se registra por conexión en lugar de por paquete. Es una herramienta para usar solo durante el diagnóstico, no de forma permanente.⁹

Por último, dejemos claro qué no se debe hacer para diagnosticar. Desactivar todo el firewall deteniendo el servicio (MpsSvc) no es una operación admitida, y provoca problemas del propio sistema operativo, como que el menú Inicio deje de funcionar o que fallen las actualizaciones de las apps de la Store. Si aun así necesita desactivarlo para comprobar algo, desactive el perfil con Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled False dejando el servicio en ejecución, y revierta el cambio inmediatamente después de la comprobación.¹⁷ Y una vez confirmado que la causa es el firewall, la solución no es dejar la desactivación como algo permanente, sino añadir una regla correcta.

7. Precauciones bajo gestión organizativa — entornos donde las reglas locales no surten efecto y cómo tramitar la solicitud

Hay entornos donde, aunque el instalador registre la regla, esta no surte efecto. En organizaciones que gestionan el firewall de forma centralizada mediante GPO o Intune (CSP), se puede desactivar, por perfil, la «fusión de reglas locales» (AllowLocalPolicyMerge). Cuando esta opción está desactivada, las reglas creadas por un administrador local (incluidas las del instalador) no se aplican, y la distribución centralizada desde GPO/CSP se vuelve obligatoria para las reglas de las aplicaciones que necesitan conexiones de entrada.²

flowchart TB
    GPOR["Reglas distribuidas por GPO/Intune"] --> EFF["Conjunto de reglas realmente vigentes<br/>(ActiveStore)"]
    LOCAL["Reglas creadas localmente<br/>(incluye el registro del instalador)"] --> Q{"Fusión de reglas locales<br/>(AllowLocalPolicyMerge)"}
    Q -- "Activada (predeterminado)" --> EFF
    Q -- "Desactivada" --> DROP["La regla existe pero no se aplica<br/>→ pasar a la distribución centralizada vía GPO/CSP"]

Las precauciones realistas desde el lado del desarrollo y de la implantación son las siguientes.

• Diseñe el registro de reglas del instalador para que «no falle» (el registro en sí tiene éxito, así que no se puede detectar por error; incluya en el procedimiento una comprobación de conectividad después de la implantación)
• Con el paso 4 del capítulo 6 (-TracePolicyStore), compruebe si el origen de la regla vigente es local o de GPO⁵
• En cuanto se confirme que es un entorno donde las reglas locales no surten efecto, pase a solicitar al departamento de sistemas la distribución de la regla

En la solicitud, entregue este conjunto completo de información. Como una regla de firewall solo se puede crear cuando están completas la dirección, el programa, el puerto y el alcance, esta tabla se convierte, tal cual, en la «especificación de red de la aplicación empresarial».

También desde el lado de sistemas, una solicitud con esta tabla y una sin ella suponen una carga de trabajo completamente distinta. En sentido inverso, un «ábranme el puerto» que solo da el número de puerto tiende, como vimos en el capítulo 4, a un permiso excesivo. Además, los requisitos de comunicación en torno al recurso compartido de archivos y la autenticación en un entorno de dominio también están cambiando por restricciones ajenas al firewall (como la obligatoriedad de la firma). Consulte también «Firma de SMB y vinculación de canal LDAP».

8. Resumen

• El comportamiento predeterminado del firewall de Windows es bloquear la entrada y permitir la salida. Las reglas de entrada solo son necesarias para las aplicaciones de tipo servidor que escuchan; si solo se conecta como cliente, en principio no hacen falta.
• Las reglas se aplican por perfil (dominio, privada, pública). El primer sospechoso ante «la regla existe pero no pasa» es un desajuste de perfil.
• El diálogo de «advertencia importante» crea una regla de bloqueo al cancelar o al ser operado por un usuario sin privilegios, y después no vuelve a aparecer. No confíe la operación en producción a este diálogo.
• Registrar las reglas de entrada de la aplicación empresarial mediante el instalador — ese es el único principio. Implemente el registro con privilegios de administrador y fije -Name, incluyendo también para la eliminación.
• Diseñe las reglas con el eje programa + protocolo + puerto, y acótelas por perfil e IP remota. Si una actualización cambia la ruta del exe, no olvide volver a registrar la regla.
• Diagnostique mecánicamente en el orden netstat → Test-NetConnection → confirmación de perfil → Get-NetFirewallRule (ActiveStore) → pfirewall.log. Desactivar deteniendo el servicio no es una operación admitida.
• Bajo gestión de GPO/Intune, la fusión de reglas locales puede estar desactivada. En ese caso, reúna el nombre de la regla, la dirección, el programa, el puerto, la IP remota y el perfil, y solicite la distribución al departamento de sistemas.

Artículos relacionados

• Cómo elegir la comunicación entre procesos en Windows — tabla de decisión de canalizaciones con nombre / TCP / gRPC / memoria compartida / COM
• Cómo elegir la forma de distribución de una aplicación de Windows - MSI/MSIX/ClickOnce/xcopy/actualizador propio
• Cuándo se necesitan privilegios de administrador en Windows - UAC, áreas protegidas y cómo distinguirlo en el diseño
• Cuando su aplicación de Windows propia es tratada como virus — cómo responder a los falsos positivos de Microsoft Defender y convivir con el impacto en el rendimiento
• Firma de SMB y vinculación de canal LDAP — cómo cerrar en la práctica la «otra mitad» de las contramedidas contra NTLM
• Cómo crear y operar servicios de Windows — desde cuándo usar el Programador de tareas hasta convertir un BackgroundService en servicio

Áreas de consultoría relacionadas

KomuraSoft LLC se ocupa del diseño de instaladores para aplicaciones empresariales de tipo servidor (incluido el registro y la eliminación de reglas de firewall), la investigación de causas de «no se puede comunicar» en el entorno del cliente, y la organización de los requisitos de red con vistas a un despliegue bajo gestión de GPO. Puede empezar simplemente por el diagnóstico de «funciona en desarrollo pero no en el cliente».

• Desarrollo de aplicaciones de 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 reglas de firewall las aplicaciones que solo actúan como cliente y se conectan a un servidor?

En principio no. Como el firewall de Windows bloquea la entrada y permite la salida por defecto, una aplicación cliente que solo se conecta hacia afuera puede comunicarse sin cambios. Las reglas de entrada solo son necesarias para el lado que abre un puerto y espera conexiones, es decir, las aplicaciones de tipo servidor. Sin embargo, hay dos excepciones: en entornos de alta seguridad la salida también puede estar bloqueada por defecto, en cuyo caso hace falta solicitar una regla de salida; y si una app cliente está diseñada para escuchar ella misma un puerto como receptor de notificaciones de resultado, esa parte sí necesita una regla de entrada.

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

Puede resolver el problema en el momento, pero no se le puede confiar la operación en producción. Este diálogo crea una regla de bloqueo si un usuario con privilegios de administrador pulsa Cancelar. Además, si el usuario no tiene privilegios de administrador, se crea una regla de bloqueo sin importar qué botón pulse. Una vez creada la regla, el diálogo no vuelve a aparecer hasta que se elimine, y la comunicación sigue fallando. En aplicaciones empresariales que operan usuarios generales en el sitio, es muy fácil llegar a la situación de «alguien canceló una vez y desde entonces nunca más se pudo comunicar». El propio Microsoft recomienda colocar las reglas antes del primer inicio de la aplicación.

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

Lo básico es combinarlos, no usar uno solo. Especificar el programa permite acotar el objetivo por la ruta completa del exe, pero si una actualización cambia la ruta, la regla pierde su objetivo (no se admiten comodines). Especificar el puerto deja claro qué se solicita al departamento de sistemas, pero también permite pasar a cualquier otro proceso que escuche en ese mismo puerto. Para una aplicación empresarial en producción, el patrón de mínimo privilegio consiste en combinar «programa + protocolo + puerto», limitar el perfil a dominio/privada y acotar la IP remota a la subred donde está el cliente. Solo se usa la especificación de programa en solitario cuando el puerto es dinámico.

Parece que la regla registrada por el instalador no surte efecto en el equipo del cliente. ¿Por qué?

Es muy probable que el firewall del cliente esté gestionado de forma centralizada mediante GPO o Intune y que la «fusión de reglas locales» (AllowLocalPolicyMerge) esté desactivada. Cuando esta opción está desactivada, las reglas creadas localmente existen en el perfil pero no se aplican, y las reglas solo pueden distribuirse de forma centralizada desde GPO/CSP. Compruebe el conjunto completo de reglas vigentes con Get-NetFirewallRule -PolicyStore ActiveStore y solicite al departamento de sistemas que distribuya la regla. Si en la solicitud incluye el nombre de la regla, la dirección, la ruta del programa, el protocolo y puerto, el rango de IP remota y el perfil, normalmente se aprueba a la primera.

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

Evite por completo desactivarlo deteniendo el servicio (MpsSvc). Es una operación no admitida por Microsoft y puede provocar problemas del propio sistema operativo, como que el menú Inicio deje de funcionar o que fallen las actualizaciones de las apps de la Store. Si de todos modos necesita desactivarlo para diagnosticar, el método correcto es dejar el servicio en ejecución y desactivar el perfil con Set-NetFirewallProfile -Enabled False. Aun así, limite esto a confirmar en pocos minutos si la causa es el firewall, y revierta el cambio en cuanto termine la comprobación. Mantener la desactivación de forma permanente cambia un problema que se resuelve añadiendo una sola regla por dejar todo el equipo desprotegido.

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.