Azure Firewall problemas conocidos y limitaciones

Este artículo le ayuda a comprender los problemas conocidos actuales y las limitaciones de Azure Firewall. Actualizamos esta información a medida que se resuelven los problemas, así que vuelva a comprobar periódicamente el estado más reciente.

Antes de implementar Azure Firewall o solucionar problemas existentes, revise estos problemas conocidos para evitar problemas comunes y planear soluciones alternativas adecuadas.

Para los límites de servicio de Azure Firewall, consulte los límites de suscripción y servicio de Azure, cuotas y restricciones.

Restricciones de capacidad actuales

Las zonas siguientes están experimentando actualmente restricciones de capacidad:

Región o zonas	SKU	Restricciones	Recomendación
Zona física 1 y zona 4 en East US 2 EUAP	Básico, Estándar y Premium	- No se puede implementar una nueva Azure Firewall en la zona 1 y la zona 4.	Se recomienda implementar una nueva Azure Firewall en las zonas de disponibilidad restantes o usar otra región. Para configurar un firewall existente, consulte ¿Cómo puedo configurar zonas de disponibilidad después de la implementación?.
- Zona física 2 en el Norte de Europa - Zona física 3 en Sudeste Asiático	Estándar y Premium	- No se puede implementar una nueva Azure Firewall en la zona 3 en Asia oriental o en la zona 2 del Norte de Europa. - Si detiene un Azure Firewall existente que se implementa en estas zonas, no se puede reiniciar. Para obtener más información, consulte Zonas de disponibilidad físicas y lógicas.	Se recomienda implementar una nueva Azure Firewall en las zonas de disponibilidad restantes o usar otra región. Para configurar un firewall existente, consulte ¿Cómo puedo configurar zonas de disponibilidad después de la implementación?.
Zona física 3 en Centro-sur de EE. UU.	Básico, Estándar y Premium	- No se puede implementar una nueva Azure Firewall en la zona 3. Fecha estimada disponible: 31 de marzo de 2026	Se recomienda implementar una nueva Azure Firewall en las zonas de disponibilidad restantes o usar otra región. Para configurar un firewall existente, consulte ¿Cómo puedo configurar zonas de disponibilidad después de la implementación?.
Zona física 2 en Centro de España	Básico, Estándar y Premium	- No se puede implementar una nueva Azure Firewall en la zona 2. Fecha estimada disponible: 31 de diciembre de 2026	Se recomienda implementar una nueva Azure Firewall en las zonas de disponibilidad restantes o usar otra región. Para configurar un firewall existente, consulte ¿Cómo puedo configurar zonas de disponibilidad después de la implementación?.
Zona física 3 en US Gov Virginia	Básico y Estándar	- Las implementaciones zonales se bloquean en la zona física 3 en US Gov Virginia. - Debe seleccionar manualmente las zonas disponibles para una implementación correcta, creando una experiencia de implementación poco óptima.	Seleccione las zonas 1 y 2 para las implementaciones zonales o use otra región.
Zona física 2 en Oeste de EE. UU. 2	Básico, Estándar y Premium	- No se puede implementar una nueva Azure Firewall en la zona 2.	Se recomienda implementar una nueva Azure Firewall en las zonas de disponibilidad restantes o usar otra región. Para configurar un firewall existente, consulte ¿Cómo puedo configurar zonas de disponibilidad después de la implementación?.
Zona física 1,2,3 en El Centro de Qatar	Básico, Estándar y Premium	- Las nuevas implementaciones de Azure Firewall están bloqueadas. Fecha estimada de disponibilidad: 31 de diciembre de 2026	Se recomienda implementar una nueva Azure Firewall en otra región.

Advertencia

Si detiene una implementación de Azure Firewall existente en cualquiera de estas regiones restringidas a la capacidad, es posible que no pueda iniciarla de nuevo debido a limitaciones de capacidad en curso. Planee en consecuencia antes de detener las instancias de firewall en estas regiones.

Problemas conocidos de Azure Firewall Standard

Azure Firewall Estándar tiene los siguientes problemas conocidos:

Problema	Descripción	Mitigación
Compatibilidad de DNAT con direcciones IP privadas limitadas a las versiones Estándar y Premium	La compatibilidad con DNAT en la dirección IP privada de Azure Firewall solo está disponible en las versiones de Firewall Estándar y Premium, no en la versión Básica.	Ninguno
Azure Firewall no admite el proceso de desasignación y asignación cuando se configuran reglas de DNAT de IP privadas	Se produce un error en el proceso de asignación de Azure Firewall cuando se configuran reglas de DNAT privadas	1. Libere el Azure Firewall 2. Elimine todas las reglas de DNAT de IP privada 3. Asigne el Azure Firewall y espere hasta que se rellene la dirección IP privada 4. Reconfigura las reglas de DNAT de IP privadas con la dirección IP privada adecuada.
Las reglas de filtrado de red para protocolos que no son TCP/UDP (por ejemplo, ICMP) no funcionan con el tráfico enlazado a Internet	Las reglas de filtrado de red para protocolos distintos de TCP/UDP no funcionan con SNAT a tu dirección IP pública. Los protocolos que no son TCP/UDP no se admiten entre subredes de radio y redes virtuales.	Azure Firewall usa el Standard Load Balancer, que actualmente no admite SNAT para protocolos IP. Estamos explorando opciones para admitir protocolos que no son TCP/UDP para el tráfico enlazado a Internet en una versión futura.
Cuando se desasigna un Azure Firewall y, a continuación, se asigna de nuevo, se podría asignar una nueva dirección IP privada.	Después del proceso de desasignación y asignación del Azure Firewall, se asigna dinámicamente una dirección IP privada desde la subred Azure Firewall. Cuando se asigna una nueva dirección IP privada diferente de la anterior, provoca problemas de enrutamiento.	Debe volver a configurar las rutas definidas por el usuario (UDR) existentes con la nueva dirección IP privada. Se está investigando una corrección para conservar la dirección IP privada después del proceso de asignación.
Las directivas de firewall secundarias no heredan la configuración de DNS de las directivas primarias.	Al cambiar la configuración de DNS en una directiva de firewall principal, es posible que las directivas secundarias vinculadas a ella no resuelvan los nombres de dominio en sus reglas.	Configura las configuraciones de DNS directamente en cada directiva secundaria en lugar de confiar en la directiva primaria. Estamos trabajando en una corrección para permitir la herencia de la configuración de DNS.
Falta de compatibilidad entre PowerShell y CLI con ICMP	Azure PowerShell y la CLI no admiten ICMP como protocolo válido en las reglas de red.	Aun así se puede usar ICMP como protocolo a través del portal y la API REST. Estamos trabajando para agregar pronto ICMP a PowerShell y la CLI.
Las etiquetas FQDN requieren que se establezca un protocolo y puerto.	Las reglas de aplicaciones con las etiquetas FQDN requieren la definición de puerto: protocolo.	Puede usar https como valor de puerto: protocolo. Estamos trabajando para que el puerto: campo de protocolo sea opcional cuando se usan etiquetas FQDN.
No se admite la posibilidad de mover un firewall a otro grupo de recursos o suscripción.	No se admite la posibilidad de mover un firewall a otro grupo de recursos o suscripción.	La compatibilidad con esta funcionalidad está en nuestra hoja de ruta. Para mover un firewall a otro grupo de recursos o suscripción, debe eliminar la instancia actual y volver a crearla en al nuevo grupo de recursos o suscripción.
Las alertas de inteligencia sobre amenazas podrían enmascararse	Las reglas de red con el destino 80/443 para el filtrado saliente enmascaran las alertas de inteligencia sobre amenazas cuando se configuran para el modo de solo alerta.	Cree filtrado de salida para 80/443 mediante reglas de aplicaciones. También puede cambiar el modo de inteligencia sobre amenazas a Alertar y denegar.
Con centros virtuales protegidos, las zonas de disponibilidad solo se pueden configurar durante la implementación.	No puede configurar Availability Zones después de implementar un firewall con centros virtuales protegidos.	Por diseño.
SNAT en conexiones entrantes	Las reglas DNAT entrantes siempre cambian la dirección IP de origen para el tráfico devuelto.	Para realizar un seguimiento de la dirección IP del cliente original para el tráfico web, configure los clientes o servidores proxy para incluir la dirección IP original en los encabezados XFF . Azure Firewall conserva estas direcciones IP en el encabezado XFF y agrega la dirección IP del firewall al encabezado XFF al procesar reglas de tráfico web.
El filtrado por nombre de dominio completo de SQL se admite solo en modo de proxy (puerto 1433)	Para Azure SQL Database, Azure Synapse Analytics y Azure SQL Managed Instance: El filtrado por nombre de dominio completo de SQL se admite solo en modo de proxy (puerto 1433). Para Azure SQL IaaS: Si va a usar puertos que no son los estándar, puede especificar esos puertos en las reglas de la aplicación.	Para SQL en modo de redirección (valor predeterminado si se conecta desde dentro de Azure), puede filtrar el acceso mediante la etiqueta de servicio SQL como parte de las reglas de red de Azure Firewall.
El tráfico SMTP de salida del puerto TCP 25 está bloqueado	La plataforma Azure bloquea los mensajes de correo electrónico salientes enviados directamente a dominios externos (como outlook.com y gmail.com) en el puerto TCP 25. Bloquear el tráfico SMTP saliente en el puerto 25 es el comportamiento predeterminado de la plataforma en Azure. Azure Firewall no introduce ninguna restricción más específica.	Use servicios de retransmisión SMTP autenticados, que normalmente se conectan a través del puerto TCP 587, pero también admiten otros puertos. Para obtener más información, consulte Solución de problemas de conectividad SMTP salientes en Azure. Otra opción es implementar Azure Firewall en una suscripción estándar del Contrato Enterprise (EA). Azure Firewall en una suscripción EA puede comunicarse con direcciones IP públicas usando el puerto TCP 25 de salida. Puede funcionar en otros tipos de suscripción, pero no garantizados. En el caso de direcciones IP privadas, como redes virtuales, VPN y Azure ExpressRoute, Azure Firewall admite una conexión saliente en el puerto TCP 25.
Agotamiento de puertos SNAT	Azure Firewall actualmente admite 2496 puertos por dirección IP pública por instancia del conjunto de escalado de máquinas virtuales back-end. De forma predeterminada, hay dos instancias del conjunto de escalado de máquinas virtuales. Por lo tanto, hay 4992 puertos por flujo (IP de destino, puerto de destino y protocolo, TCP o UDP). El firewall se escala verticalmente hasta un máximo de 20 instancias.	El agotamiento de puertos SNAT es una limitación de la plataforma. Puede eludir los límites configurando las implementaciones de Azure Firewall con un mínimo de cinco direcciones IP públicas para implementaciones susceptibles al agotamiento de SNAT. La adición de más direcciones IP públicas aumenta los puertos SNAT disponibles en cinco veces. Asigne desde un prefijo de dirección IP para simplificar los permisos de bajada. Para una solución más permanente, puede implementar una puerta de enlace NAT para superar los límites de puertos SNAT. La implementación de la puerta de enlace NAT es compatible con las implementaciones de red virtual. Para obtener más información, consulte Escalar los puertos SNAT con Azure Virtual Network NAT.
DNAT no es compatible con tunelización forzada cuando está habilitada	Los firewalls implementados con la tunelización forzada habilitada no admiten el acceso entrante desde Internet debido al enrutamiento asimétrico.	La falta de compatibilidad de DNAT con la tunelización forzada es por diseño debido al enrutamiento asimétrico. La ruta de acceso de retorno de las conexiones entrantes pasa por el firewall local, que no ve la conexión establecida.
Es posible que el FTP pasivo saliente no funcione en firewalls con varias direcciones IP públicas, en función de la configuración del servidor FTP.	FTP pasivo establece distintas conexiones para los canales de control y datos. Cuando un firewall con varias direcciones IP públicas envía datos de salida, selecciona de manera aleatoria una de sus direcciones IP públicas como dirección IP de origen. FTP puede generar un error cuando los canales de control y de datos usan direcciones IP de origen diferentes, en función de la configuración del servidor FTP.	Está previsto una configuración de SNAT explícita. Entretanto, puede configurar el servidor FTP para que acepte los canales de control y de datos de distintas direcciones IP de origen (vea un ejemplo de IIS). Como alternativa, considere la posibilidad de usar una única dirección IP al experimentar problemas de conectividad de FTP.
Es posible que el FTP pasivo entrante no funcione en función de la configuración del servidor FTP	FTP pasivo establece distintas conexiones para los canales de control y datos. Las conexiones entrantes en Azure Firewall se convierten mediante SNAT en una de las direcciones IP privadas del firewall para garantizar el enrutamiento simétrico. FTP puede generar un error cuando los canales de control y de datos usan direcciones IP de origen diferentes, en función de la configuración del servidor FTP.	Se está investigando la conservación de la dirección IP de origen original. Entretanto, puede configurar el servidor FTP para que acepte los canales de control y de datos de distintas direcciones IP de origen.
FTP activo no funcionará cuando el cliente FTP deba acceder a un servidor FTP mediante Internet.	FTP activo usa un comando PORT del cliente FTP que indica al servidor FTP qué dirección IP y puerto usar para el canal de datos. El comando PORT utiliza la dirección IP privada del cliente que no se puede cambiar. El tráfico del lado cliente que atraviesa el Azure Firewall es NATed para las comunicaciones basadas en Internet, lo que hace que el comando PORT sea visto como no válido por el servidor FTP.	Un error de FTP activo es una limitación general del FTP activo cuando se usa con una NAT del lado del cliente.
Falta una dimensión de protocolo en la métrica NetworkRuleHit	La métrica ApplicationRuleHit permite el filtrado basado en el protocolo, pero esta funcionalidad falta en la métrica NetworkRuleHit correspondiente.	Se está investigando una solución.
No se admiten las reglas NAT con puertos entre el 64000 y el 65535	Azure Firewall permite cualquier puerto del intervalo de 1 a 65535 en las reglas de red y aplicación, pero las reglas NAT solo admiten puertos en el intervalo de 1 a 63999.	La restricción en los puertos de las reglas NAT es una limitación actual.
Las actualizaciones de la configuración pueden tardar una media de cinco minutos	Una actualización de configuración de Azure Firewall puede tardar de tres a cinco minutos en promedio y no se admiten actualizaciones paralelas.	Se está investigando una solución.
Azure Firewall usa encabezados TLS de SNI para filtrar el tráfico HTTPS y MSSQL	Si el explorador o el software de servidor no admiten la extensión Indicador de nombre de servidor (SNI), no se puede conectar a través de Azure Firewall.	Si el software de explorador o servidor no admite SNI, es posible que pueda controlar la conexión mediante una regla de red, en lugar de una regla de aplicación. Consulte Indicación de nombre de servidor para conocer el software que admite SNI.
No se pueden agregar etiquetas de directiva de firewall mediante el portal ni las plantillas de Azure Resource Manager (ARM)	Azure Firewall Policy tiene una restricción de soporte de parches que impide que se puedan agregar etiquetas mediante el portal de Azure o las plantillas de ARM. Se genera el siguiente error: No se pudieron guardar las etiquetas del recurso.	Se está investigando una solución. O bien, puede usar el cmdlet Azure PowerShell Set-AzFirewallPolicy para actualizar las etiquetas.
Actualmente, no se admite IPv6.	Si agrega una dirección IPv6 a una regla, se produce un error en el firewall.	Use solo direcciones IPv4. La compatibilidad con IPv6 está en proceso de investigación.
No se admite la eliminación de elementos RuleCollectionGroup mediante plantillas de ARM.	Eliminar un grupo de colecciones de reglas mediante plantillas de ARM no es compatible y resulta en un error.	La eliminación de RuleCollectionGroups mediante plantillas de ARM no es una operación compatible.
La regla DNAT para permitir cualquiera (*) permitirá el tráfico SNAT.	Si una regla DNAT permite cualquier (*) como dirección IP de origen, entonces una regla de red implícita coincide con el tráfico VNet-VNet y siempre aplicará SNAT al tráfico.	El comportamiento automático de SNAT para las reglas DNAT con cualquier origen es una limitación actual.
No se admite la adición de una regla DNAT a un centro virtual protegido con un proveedor de seguridad.	Cuando se agrega una regla DNAT a un centro virtual protegido con un proveedor de seguridad, se produce una ruta asincrónica para el tráfico DNAT devuelto, que va al proveedor de seguridad.	No compatible.
Error al crear más de 2,000 colecciones de reglas.	El número máximo de colecciones de reglas NAT/Application o Network es 2000 (límite de Resource Manager).	El límite de recopilación de 2000 reglas es una limitación actual.
No se puede implementar firewall con Availability Zones con una dirección IP pública recién creada	Al implementar un firewall con Availability Zones, no puede usar una dirección IP pública recién creada.	En primer lugar, cree una nueva dirección IP pública con redundancia de zona y, a continuación, asigne esta dirección IP creada previamente durante la implementación del firewall.
No se admite la asociación de una dirección IP pública con Azure Firewall en un escenario entre inquilinos.	Si crea una dirección IP pública en el inquilino A, no puede asociarla a un firewall implementado en el inquilino B.	Ninguno.
Las máquinas virtuales detrás de Azure Firewall no se pueden conectar a destinos de reglas DNAT mediante la dirección IP pública del firewall	Cuando las máquinas virtuales enrutan el tráfico a través de Azure Firewall e intentan conectarse a recursos configurados con reglas DNAT mediante la dirección IP pública del firewall, se produce un error en la conexión. El error de conexión se produce porque Azure Firewall no admite el redireccionamiento de tráfico desde las máquinas virtuales internas hacia su propia dirección IP pública para los destinos de reglas DNAT.	Actualmente hay una solución para esta limitación en desarrollo.
Problemas de conectividad al enrutar el tráfico IPsec nativo del sistema operativo desde máquinas virtuales de Azure a un entorno local a través de Azure Firewall Estándar	En algunas implementaciones híbridas, Azure máquinas virtuales usan túneles IPsec nativos del sistema operativo para conectarse a redes locales. Cuando este tráfico se enruta a través de Azure Firewall Estándar, especialmente cuando un VPN Gateway o emparejamiento de red virtual global está implicado, es posible que los paquetes IPsec no pasen por el firewall, lo que da lugar a problemas de conectividad.	Evite el enrutamiento del tráfico IPsec nativo del sistema operativo desde las máquinas virtuales de Azure a través del Azure Firewall Estándar. Actualmente hay una solución para esta limitación en desarrollo.

problemas conocidos de Azure Firewall Premium

Nota:

Cualquier problema que se aplique a Estándar también se aplica a Premium.

Azure Firewall Premium tiene los siguientes problemas conocidos:

Problema	Descripción	Mitigación
Compatibilidad de ESNI con la resolución FQDN en HTTPS	La indicación de nombre de servidor cifrada no se admite en el protocolo de enlace HTTPS.	Actualmente, solo Firefox admite ESNI a través de la configuración personalizada. La solución alternativa sugerida es deshabilitar la característica ESNI.
No se admite la autenticación mediante certificado de cliente	Los certificados de cliente se usan para crear una confianza de identidad mutua entre el cliente y el servidor. Los certificados de cliente se usan durante una negociación de TLS. Azure firewall renegocia una conexión con el servidor y no tiene acceso a la clave privada de los certificados de cliente.	Ninguno
QUIC/HTTP3	QUIC es la nueva versión principal de HTTP. Es un protocolo basado en UDP a través de los puertos 80 (PLAN) y 443 (SSL). La inspección de FQDN, URL y TLS no está soportada.	Configure el paso de UDP 80/443 como reglas de red.
Certificados firmados por clientes que no son de confianza	El firewall no confía en los certificados firmados por el cliente cuando los recibe de un servidor web basado en intranet.	Se está investigando una solución.
IDPS muestra una dirección IP de origen incorrecta para las alertas HTTP sin inspección de TLS	Cuando IDPS genera alertas para el tráfico HTTP de texto sin formato a direcciones IP públicas, muestra la dirección IP interna en lugar de la dirección IP de origen original.	Se está investigando una solución.
Propagación de certificados	Cuando se aplica un certificado de entidad de certificación en el firewall, puede tardar entre 5 y 10 minutos en surtir efecto.	Se está investigando una solución.
Compatibilidad con TLS 1.3	TLS 1.3 se admite de forma parcial. El túnel TLS del cliente al firewall se basa en TLS 1.2 y desde el firewall al servidor web externo en TLS 1.3.	Las actualizaciones están siendo investigadas.
Expiración del certificado de CA intermedia de TLSi	En algunos casos únicos, el certificado de CA intermedia puede expirar dos meses antes de la fecha de expiración original.	Renueve el certificado de CA intermedia dos meses antes de la fecha de expiración original. Se está investigando una solución.
Problemas de conectividad al enrutar el tráfico IPsec nativo del sistema operativo desde máquinas virtuales de Azure a un entorno local a través de Azure Firewall Premium	En algunas implementaciones híbridas, Azure máquinas virtuales usan túneles IPsec nativos del sistema operativo para conectarse a redes locales. Cuando este tráfico se enruta a través de Azure Firewall Estándar, especialmente cuando un VPN Gateway o emparejamiento de red virtual global está implicado, es posible que los paquetes IPsec no pasen por el firewall, lo que da lugar a problemas de conectividad.	Evite redirigir el tráfico IPsec nativo del sistema operativo desde máquinas virtuales de Azure a través de Azure Firewall Premium. Actualmente hay una solución para esta limitación en desarrollo.

Pasos siguientes

• Límites, cuotas y restricciones de suscripción y servicio de Azure
• Características de Azure Firewall Premium
• Más información sobre la seguridad de red de Azure