Preguntas frecuentes sobre Azure Firewall

General

¿Qué es Azure Firewall?

Azure Firewall es un servicio de seguridad de red administrado y basado en la nube que protege los recursos de Azure Virtual Network. Se trata de un firewall como servicio con estado completo que incorpora alta disponibilidad y escalabilidad a la nube sin restricciones. Puede crear, aplicar y registrar directivas de aplicaciones y de conectividad de red a nivel central en suscripciones y redes virtuales.

¿Qué funcionalidades admite Azure Firewall?

Para obtener una lista detallada de las características de Azure Firewall, consulte Características de Azure Firewall.

¿Cuál es el modelo de implementación típico para Azure Firewall?

Azure Firewall se puede implementar en cualquier red virtual. Sin embargo, normalmente se implementa en una red virtual central en un modelo en estrella tipo hub-and-spoke, con otras redes virtuales emparejadas. La ruta predeterminada de las redes virtuales emparejadas se establece para que apunte a esta red virtual de firewall central. Aunque se admite el emparejamiento de red virtual global, no se recomienda debido a posibles problemas de rendimiento y latencia entre regiones. Para obtener un rendimiento óptimo, implemente un firewall por región.

Este modelo permite un control centralizado sobre varias redes virtuales radiales en distintas suscripciones y ofrece ahorros de costos al evitar la necesidad de implementar un firewall en cada red virtual. Se deben evaluar los ahorros de costos con respecto a los costos de emparejamiento asociados en función de los patrones de tráfico.

¿Cómo puedo implementar Azure Firewall?

Azure Firewall se puede implementar mediante Azure Portal, PowerShell, API REST o plantillas. Para obtener instrucciones paso a paso, consulte Tutorial: Implementación y configuración de Azure Firewall mediante Azure Portal.

¿Cuáles son algunos conceptos clave de Azure Firewall?

Azure Firewall usa reglas y colecciones de reglas. Una colección de reglas es un conjunto de reglas con el mismo orden y prioridad. Las colecciones de reglas se ejecutan en orden de prioridad. Las colecciones de reglas DNAT tienen mayor prioridad que las colecciones de reglas de red, que a su vez tienen mayor prioridad que las colecciones de reglas de aplicación. Todas las reglas finalizan.

Hay tres tipos de colecciones de reglas:

• Reglas de aplicación: configure nombres de dominio completos (FQDN) a los que se pueda acceder desde una red virtual.
• Reglas de red: configure reglas con direcciones de origen, protocolos, puertos de destino y direcciones de destino.
• Reglas NAT: Configure reglas DNAT para permitir conexiones entrantes de Internet o intranet (versión preliminar).

Para más información, veaConfiguración de reglas de Azure Firewall.

¿Qué servicios de registro y análisis son compatibles con Azure Firewall?

Azure Firewall se integra con Azure Monitor para ver y analizar registros. Los registros se pueden enviar a Log Analytics, Azure Storage o Event Hubs y analizarlos mediante herramientas como Log Analytics, Excel o Power BI. Para más información, consulte el Tutorial: Supervisión de los registros de Azure Firewall.

¿Cómo difiere Azure Firewall de las aplicaciones virtuales de red en Marketplace?

Azure Firewall es un servicio de seguridad de red administrado basado en la nube que protege los recursos de red virtual. Se trata de un firewall como servicio con estado completo que incorpora alta disponibilidad y escalabilidad a la nube sin restricciones. Está preintegrado con proveedores de seguridad como servicio (SECaaS) de terceros para mejorar la seguridad de las conexiones a Internet de red virtual y sucursal. Para más información, consulte Azure Network Security (Seguridad de red de Azure).

¿Cuál es la diferencia entre WAF de Application Gateway y Azure Firewall?

Application Gateway WAF proporciona protección centralizada de entrada para aplicaciones web frente a vulnerabilidades y vulnerabilidades comunes. Azure Firewall proporciona protección de entrada para protocolos no HTTP/S (como RDP, SSH y FTP), protección de salida a nivel de red para todos los puertos y protocolos, y protección a nivel de aplicación para las salidas HTTP/S.

¿Cuál es la diferencia entre los grupos de seguridad de red (NSG) y Azure Firewall?

Azure Firewall complementa los grupos de seguridad de red para proporcionar una mejor seguridad de red de "defensa en profundidad". Los grupos de seguridad de red ofrecen filtrado de tráfico de capa de red distribuida para limitar el tráfico dentro de las redes virtuales de cada suscripción. Azure Firewall proporciona una red centralizada y totalmente con estado y protección a nivel de aplicación en suscripciones y redes virtuales.

¿Se admiten grupos de seguridad de red (NSG) en AzureFirewallSubnet?

Azure Firewall es un servicio administrado con varias capas de protección, incluida la protección de plataforma con NSG de nivel de NIC (no visible). Los NSG de nivel de subred no son necesarios en AzureFirewallSubnet y están deshabilitados para evitar interrupciones del servicio.

¿Cuál es el valor agregado de Azure Firewall con puntos de conexión privados?

Los puntos de conexión privados son un componente de Private Link, una tecnología que permite interactuar con los servicios paaS de Azure mediante direcciones IP privadas en lugar de las públicas. Azure Firewall se puede usar para evitar el acceso a direcciones IP públicas, por lo que se evita la filtración de datos a los servicios de Azure que no aprovechan Private Link, así como para implementar directivas de confianza cero definiendo quién de su organización necesita acceder a esos servicios paaS de Azure, ya que Private Link por defecto abre el acceso de red para toda la red corporativa.

El diseño adecuado para inspeccionar el tráfico a puntos de conexión privados con Azure Firewall dependerá de la arquitectura de red. Puede encontrar más detalles en el artículo Escenarios de Azure Firewall para inspeccionar el tráfico destinado a un punto de conexión privado.

¿Cuál es el valor agregado de Azure Firewall con puntos de conexión de servicio de red virtual?

Los puntos de conexión de servicio de red virtual son una alternativa a Private Link para controlar el acceso de red a los servicios PaaS de Azure. Incluso si el cliente sigue usando direcciones IP públicas para acceder al servicio PaaS, la subred de origen se hace visible para que el servicio PaaS de destino pueda implementar reglas de filtro y restringir el acceso por subred. Puede encontrar una comparación detallada entre ambos mecanismos en Comparar puntos de conexión privados y puntos de conexión de servicio.

Las reglas de aplicación de Azure Firewall se pueden usar para asegurarse de que no se produce ninguna filtración de datos a servicios no autorizados y de implementar directivas de acceso con una mayor granularidad más allá del nivel de subred. Normalmente, los puntos de conexión de servicio de red virtual deben habilitarse en la subred del cliente que se conectará a un servicio de Azure. Sin embargo, al inspeccionar el tráfico a los puntos de conexión de servicio con Azure Firewall, debe habilitar el punto de conexión de servicio correspondiente en la subred de Azure Firewall y deshabilitarlo en la subred del cliente real (normalmente una red virtual radial). De este modo, puede usar reglas de aplicación en Azure Firewall para controlar a qué servicios de Azure tendrán acceso las cargas de trabajo de Azure.

¿Cuál es el precio de Azure Firewall?

Para más información sobre los precios, consulte Precios de Azure Firewall.

¿Cuáles son los límites de servicio conocidos para Azure Firewall?

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

¿Dónde se almacenan los datos de los clientes en Azure Firewall?

Azure Firewall no mueve ni almacena datos de cliente fuera de la región donde se implementa.

¿Se admite Azure Firewall en centros virtuales protegidos (vWAN) en Qatar?

No, Azure Firewall en centros virtuales protegidos (vWAN) no se admite actualmente en Qatar.

Funcionalidades y características admitidas

¿Admite Azure Firewall el filtrado del tráfico de entrada?

Sí, Azure Firewall admite el filtrado de tráfico entrante y saliente. El filtrado de entrada se usa normalmente para protocolos que no son HTTP, como RDP, SSH y FTP. Para el tráfico HTTP y HTTPS entrante, considere la posibilidad de usar un firewall de aplicaciones web como Azure Web Application Firewall (WAF) o las características de descarga de TLS y inspección profunda de paquetes de Azure Firewall Premium.

¿Admite Azure Firewall Básico la tunelización forzada?

Sí, Azure Firewall Básico admite la tunelización forzada.

¿Por qué aparece un ping TCP o una herramienta similar para conectarse a un FQDN de destino incluso cuando ninguna regla permite el tráfico?

Un ping tcp no se conecta realmente al FQDN de destino. Azure Firewall bloquea las conexiones a cualquier dirección IP de destino o FQDN a menos que una regla lo permita explícitamente.

En el caso de un ping tcp, si no hay ninguna regla que permita el tráfico, el firewall responde a la solicitud de ping TCP del cliente. Esta respuesta no alcanza la dirección IP de destino ni el FQDN y no se registra. Si una regla de red permite explícitamente el acceso a la dirección IP de destino o al FQDN, la solicitud ping llega al servidor de destino y su respuesta se retransmite de nuevo al cliente. Este evento se registra en el registro de reglas de red.

¿Admite Azure Firewall el emparejamiento BGP?

No, Azure Firewall no admite de forma nativa el emparejamiento BGP. Sin embargo, la característica rutas SNAT de Autolearn usa indirectamente BGP a través de Azure Route Server.

Administración y configuración

¿Cómo puedo detener e iniciar Azure Firewall?

Puede usar Azure PowerShell para desasignar y asignar Azure Firewall. El proceso varía en función de la configuración.

Para un firewall sin una NIC de administración:

# Stop the firewall
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$azfw.Deallocate()
Set-AzFirewall -AzureFirewall $azfw

# Start the firewall
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$vnet = Get-AzVirtualNetwork -ResourceGroupName "RG Name" -Name "VNet Name"
$publicip1 = Get-AzPublicIpAddress -Name "Public IP1 Name" -ResourceGroupName "RG Name"
$publicip2 = Get-AzPublicIpAddress -Name "Public IP2 Name" -ResourceGroupName "RG Name"
$azfw.Allocate($vnet, @($publicip1, $publicip2))
Set-AzFirewall -AzureFirewall $azfw

Para un firewall con una NIC de administración:

# Stop the firewall
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$azfw.Deallocate()
Set-AzFirewall -AzureFirewall $azfw

# Start the firewall
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$vnet = Get-AzVirtualNetwork -ResourceGroupName "RG Name" -Name "VNet Name"
$pip = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "azfwpublicip"
$mgmtPip = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "mgmtpip"
$azfw.Allocate($vnet, $pip, $mgmtPip)
Set-AzFirewall -AzureFirewall $azfw

Para un firewall en un centro virtual protegido:

# Stop the firewall
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$azfw.Deallocate()
Set-AzFirewall -AzureFirewall $azfw

# Start the firewall
$virtualhub = Get-AzVirtualHub -ResourceGroupName "vHUB RG Name" -Name "vHUB Name"
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "Firewall RG Name"
$azfw.Allocate($virtualhub.Id)
Set-AzFirewall -AzureFirewall $azfw

Nota

Al detener e iniciar el firewall, la facturación se detiene e inicia en consecuencia. Sin embargo, la dirección IP privada puede cambiar, lo que puede afectar a la conectividad si se configuran las tablas de rutas.

¿Cómo puedo configurar zonas de disponibilidad después de la implementación?

Se recomienda configurar zonas de disponibilidad durante la implementación inicial. Sin embargo, puede volver a configurarlos después de la implementación si:

• El firewall se implementa en una red virtual (no se admite en centros virtuales protegidos).
• La región admite zonas de disponibilidad.
• Todas las direcciones IP públicas adjuntas se configuran con las mismas zonas.

Para volver a configurar zonas de disponibilidad:

1. Desasigne el firewall:

   $azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
   $azfw.Deallocate()
   Set-AzFirewall -AzureFirewall $azfw
   

2. Actualice la configuración de zona y asigne el firewall:

   $azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
   $vnet = Get-AzVirtualNetwork -ResourceGroupName "RG Name" -Name "VNet Name"
   $pip = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "azfwpublicip"
   $mgmtPip = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "mgmtpip"
   $azfw.Allocate($vnet, $pip, $mgmtPip)
   $azfw.Zones = 1, 2, 3
   Set-AzFirewall -AzureFirewall $azfw
   

¿Hay alguna restricción de grupo de recursos de Azure Firewall?

Sí:

• Azure Firewall y la red virtual deben estar en el mismo grupo de recursos.
• La dirección IP pública puede estar en un grupo de recursos diferente.
• Todos los recursos (Firewall de Azure, red virtual, IP pública) deben estar en la misma suscripción.

¿Qué significa el estado de aprovisionamiento **Failed**?

Un estado de aprovisionamiento con errores indica que se produjo un error en una actualización de configuración en una o varias instancias de back-end. Azure Firewall permanece operativo, pero la configuración podría ser incoherente. Vuelva a intentar la actualización hasta que el estado de aprovisionamiento cambie a Correcto.

¿Cómo controla Azure Firewall el mantenimiento planeado y los errores no planeados?

Azure Firewall usa una configuración activa-activa con varios nodos de back-end. Durante el mantenimiento planeado, la purga de conexiones garantiza actualizaciones correctas. En el caso de errores no planeados, un nuevo nodo reemplaza al conmutado por error y la conectividad se restaura normalmente en 10 segundos.

¿Hay un límite de caracteres para un nombre de firewall?

Sí, los nombres de firewall están limitados a 50 caracteres.

¿Por qué Azure Firewall necesita un tamaño de subred de /26?

Una subred /26 garantiza que haya suficientes direcciones IP para el escalado a medida que Azure Firewall aprovisiona instancias de máquina virtual adicionales.

¿Es necesario cambiar el tamaño de la subred del firewall a medida que se escala el servicio?

No, una subred /26 es suficiente para todos los escenarios de escalado.

¿Cómo puedo aumentar el rendimiento del firewall?

Azure Firewall se escala automáticamente en función del uso de CPU, el rendimiento y el recuento de conexiones. La capacidad de rendimiento oscila entre 2,5 y 3 Gbps inicialmente a 30 Gbps (SKU estándar) o 100 Gbps (SKU Premium).

¿Existen límites para el número de direcciones IP admitidas por los grupos de IP?

Sí. Para más información, consulte Límites, cuotas y restricciones de suscripción y servicios de Azure.

¿Puedo trasladar un grupo de direcciones IP a otro grupo de recursos?

No, actualmente no se permite mover un grupo de direcciones IP a otro grupo de recursos.

¿Cuál es el tiempo de espera de inactividad de TCP para Azure Firewall?

Un comportamiento estándar de un firewall de red es asegurarse de que las conexiones TCP se mantengan activas y cerrarlas de inmediato si no hay ninguna actividad. El tiempo de espera de inactividad de TCP de Azure Firewall es de cuatro minutos. Esta configuración no es configurable por el usuario, pero puede ponerse en contacto con el Soporte técnico de Azure para aumentar el tiempo de espera de inactividad para las conexiones entrantes y salientes hasta 15 minutos. No se puede cambiar el tiempo de espera de inactividad para el tráfico horizontal de derecha a izquierda.

Si un período de inactividad es mayor que el valor de tiempo de espera, no hay ninguna garantía de que todavía exista la sesión TCP o HTTP. Una práctica común es usar TCP Keep-alive. Esta práctica mantiene la conexión activa durante un periodo más largo. Para más información, consulte estos ejemplos de .NET.

¿Puedo implementar Azure Firewall sin una dirección IP pública?

Sí, pero debe configurar el firewall en modo de tunelización forzada. Esta configuración crea una interfaz de administración con una dirección IP pública que usa Azure Firewall para sus operaciones. Esta IP pública es para el tráfico de administración. Se usa exclusivamente en la plataforma Azure y no puede usarse para ningún otro propósito. La red de la ruta de acceso a los datos de inquilino se puede configurar sin una dirección IP pública y el tráfico de Internet se puede tunelizar de manera forzada a otro firewall o bloquearse completamente.

¿Hay alguna manera de realizar copias de seguridad automáticas de Azure Firewall y directivas?

Sí. Para obtener más información, consulte Copia de seguridad de Azure Firewall y de la directiva de Azure Firewall con Logic Apps.

Conectividad y enrutamiento

¿Cómo puedo configurar Azure Firewall con mis puntos de conexión de servicio?

Para un acceso seguro a los servicios de PaaS, se recomiendan los puntos de conexión de servicio. Puede elegir habilitar puntos de conexión de servicio en la subred de Azure Firewall y deshabilitarlos en las redes virtuales de radios conectadas. De este modo se beneficia de ambas características: la seguridad de los puntos de conexión y el registro central de todo el tráfico.

¿Puede Azure Firewall en una red virtual de concentrador reenviar y filtrar el tráfico de red entre varias redes virtuales radiales?

Sí, puede usar Azure Firewall en una red virtual de concentrador para enrutar y filtrar el tráfico entre varias redes virtuales de radio. Las subredes de cada una de las redes virtuales de radio deben tener una ruta definida por el usuario (UDR) que apunte a la instancia de Azure Firewall como puerta de enlace predeterminada para que este escenario funcione correctamente.

¿Azure Firewall puede reenviar y filtrar el tráfico de red entre subredes de la misma red virtual o redes virtuales emparejadas?

Sí. Sin embargo, la configuración de las UDR para redirigir el tráfico entre subredes de la misma red virtual requiere más atención. Aunque el uso del intervalo de direcciones de red virtual como prefijo de destino para la UDR es suficiente, también enruta todo el tráfico de una máquina a otra de la misma subred a través de la instancia de Azure Firewall. Para evitar esto, incluya una ruta para la subred en la UDR con un tipo de próximo salto de red virtual. La administración de estas rutas podría ser problemática y estar sujeta a errores. El método recomendado para la segmentación de redes internas es usar grupos de seguridad de red, que no necesitan UDR.

¿Azure Firewall aplica SNAT de salida entre redes privadas?

Azure Firewall no aplica SNAT cuando la dirección IP de destino es un intervalo IP privado por IANA RFC 1918 o IANA RFC 6598 para redes privadas. Si su organización usa un intervalo de direcciones IP públicas para las redes privadas, Azure Firewall aplicará SNAT al tráfico para una de las direcciones IP privadas de firewall en AzureFirewallSubnet. Puede configurar Azure Firewall de modo que no aplique SNAT al intervalo de direcciones IP públicas. Para más información, consulte Aplicación de SNAT por parte de Azure Firewall a intervalos de direcciones IP privadas.

Además, al tráfico que procesan las reglas de aplicación siempre se le aplica SNAT. Si desea ver la dirección IP inicial del origen en los registros de tráfico de FQDN, puede usar reglas de red con el FQDN de destino.

¿Se admite la tunelización o encadenamiento forzados a una aplicación virtual de red?

La tunelización forzada se admite cuando se crea un nuevo Firewall. No se puede configurar un firewall existente para la tunelización forzada. Para más información, consulte Tunelización forzada de Azure Firewall.

Azure Firewall debe tener conectividad directa a Internet. Si AzureFirewallSubnet aprende una ruta predeterminada a la red local mediante BGP, debe reemplazarla por una UDR 0.0.0.0/0 con el valor NextHopType establecido como Internet para mantener la conectividad directa a Internet.

Si la configuración requiere tunelización forzada a una red local y puede determinar los prefijos de las direcciones IP de destino de los destinos de Internet, puede configurar estos intervalos con la red local como el próximo salto mediante una ruta definida por el usuario en AzureFirewallSubnet. O bien, puede usar BGP para definir estas rutas.

¿Cómo funcionan los caracteres comodín en las direcciones URL de destino y en los nombres de dominio completo de destino en las reglas de aplicación?

• Dirección URL: los asteriscos funcionan cuando se sitúan en el extremo derecho o en el extremo izquierdo. Si un asterisco está a la izquierda, no puede formar parte del FQDN.
• FQDN: los asteriscos funcionan cuando se ponen en el extremo izquierdo.
• GENERAL: los asteriscos del lado izquierdo significan literalmente que cualquier cosa a la izquierda coincide, lo que significa que coinciden varios subdominios o variaciones de nombres de dominio potencialmente no deseados; vea los ejemplos siguientes.

Ejemplos:

Tipo	Regla	¿Compatible?	Ejemplos válidos
TargetURL (en inglés)	www.contoso.com	Sí	www.contoso.com www.contoso.com/
TargetURL (en inglés)	*.contoso.com	Sí	any.contoso.com/ sub1.any.contoso.com
TargetURL (en inglés)	*contoso.com	Sí	example.anycontoso.com sub1.example.contoso.com contoso.com Advertencia: este uso de caracteres comodín también permite variaciones potencialmente no deseadas o peligrosas, como th3re4lcontoso.com. Se deben usar con precaución.
TargetURL (en inglés)	www.contoso.com/test	Sí	www.contoso.com/test www.contoso.com/test/ www.contoso.com/test?with_query=1
TargetURL (en inglés)	www.contoso.com/test/*	Sí	www.contoso.com/test/anything Nota: www.contoso.com/testno coincide (última barra diagonal)
TargetURL (en inglés)	www.contoso.*/test/*	No
TargetURL (en inglés)	www.contoso.com/test?example=1	No
TargetURL (en inglés)	www.contoso.*	No
TargetURL (en inglés)	www.*contoso.com	No
TargetURL (en inglés)	www.contoso.com:8080	No
TargetURL (en inglés)	*.contoso.*	No
TargetFQDN	www.contoso.com	Sí	www.contoso.com
TargetFQDN	*.contoso.com	Sí	any.contoso.com Nota: si quiere permitir contoso.com específicamente, debe incluir contoso.com en la regla. De lo contrario, la conexión se descarta de forma predeterminada porque la solicitud no coincide con ninguna regla.
TargetFQDN	*contoso.com	Sí	example.anycontoso.com contoso.com
TargetFQDN	www.contoso.*	No
TargetFQDN	*.contoso.*	No

¿Permite Azure Firewall el acceso a Active Directory de forma predeterminada?

No. Azure Firewall bloquea el acceso a Active Directory de forma predeterminada. Para permitir el acceso, configure la etiqueta de servicio AzureActiveDirectory. Para más información, consulte Etiquetas de servicio de Azure Firewall.

¿Puedo excluir un FQDN o una dirección IP del filtrado basado en inteligencia sobre amenazas de Azure Firewall?

Sí, puede usar Azure PowerShell para ello:

# Add a Threat Intelligence allowlist to an Existing Azure Firewall.

# Create the allowlist with both FQDN and IPAddresses
$fw = Get-AzFirewall -Name "Name_of_Firewall" -ResourceGroupName "Name_of_ResourceGroup"
$fw.ThreatIntelWhitelist = New-AzFirewallThreatIntelWhitelist `
   -FQDN @("fqdn1", "fqdn2", …) -IpAddress @("ip1", "ip2", …)

# Or Update FQDNs and IpAddresses separately
$fw = Get-AzFirewall -Name $firewallname -ResourceGroupName $RG
$fw.ThreatIntelWhitelist.IpAddresses = @($fw.ThreatIntelWhitelist.IpAddresses + $ipaddresses)
$fw.ThreatIntelWhitelist.fqdns = @($fw.ThreatIntelWhitelist.fqdns + $fqdns)


Set-AzFirewall -AzureFirewall $fw

¿Por qué un ping de TCP y herramientas similares se conectan correctamente a un FQDN de destino incluso si ninguna regla de Azure Firewall permite ese tráfico?

Un ping de TCP no se conecta realmente al FQDN de destino. Azure Firewall no permite una conexión a ninguna dirección IP o FQDN de destino a menos que haya una regla explícita que lo permita.

El ping TCP es un caso de uso único en el que, si no hay ninguna regla permitida, el propio firewall responde a la solicitud de ping TCP del cliente aunque el ping TCP no llegue a la dirección IP o FQDN de destino. En este caso, el evento no se registra. Si hay una regla de red que permite el acceso a la dirección IP o FQDN de destino, la solicitud de ping llega al servidor de destino y su respuesta se retransmite de nuevo al cliente. Este evento se registra en el registro de reglas de red.

¿Existen límites para el número de direcciones IP admitidas por los grupos de IP?

Sí. Para más información, consulte Límites, cuotas y restricciones de suscripción y servicios de Microsoft Azure.

¿Puedo trasladar un grupo de direcciones IP a otro grupo de recursos?

No, actualmente no se permite mover un grupo de direcciones IP a otro grupo de recursos.

¿Cuál es el tiempo de espera de inactividad de TCP para Azure Firewall?

Un comportamiento estándar de un firewall de red es asegurarse de que las conexiones TCP se mantengan activas y cerrarlas de inmediato si no hay ninguna actividad. El tiempo de espera de inactividad de TCP de Azure Firewall es de cuatro minutos. Esta configuración no es configurable por el usuario, pero puede ponerse en contacto con el Soporte técnico de Azure para aumentar el tiempo de espera de inactividad para las conexiones entrantes y salientes hasta 15 minutos. No se puede cambiar el tiempo de espera de inactividad para el tráfico horizontal de derecha a izquierda.

Si un período de inactividad es mayor que el valor de tiempo de espera, no hay ninguna garantía de que todavía exista la sesión TCP o HTTP. Una práctica común es usar TCP Keep-alive. Esta práctica mantiene la conexión activa durante un periodo más largo. Para más información, consulte estos ejemplos de .NET.

¿Puedo implementar Azure Firewall sin una dirección IP pública?

Sí, pero debe configurar el firewall en modo de tunelización forzada. Esta configuración crea una interfaz de administración con una dirección IP pública que usa Azure Firewall para sus operaciones. Esta IP pública es para el tráfico de administración. Se usa exclusivamente en la plataforma Azure y no puede usarse para ningún otro propósito. La red de la ruta de acceso a los datos de inquilino se puede configurar sin una dirección IP pública y el tráfico de Internet se puede tunelizar de manera forzada a otro firewall o bloquearse completamente.

¿Dónde se almacenan los datos de los clientes en Azure Firewall?

Azure Firewall no mueve ni almacena los datos de los clientes fuera de la región en los que se implementan.

¿Hay alguna manera de realizar copias de seguridad automáticas de Azure Firewall y directivas?

Sí. Para obtener más información, consulte Copia de seguridad de Azure Firewall y de la directiva de Azure Firewall con Logic Apps.

¿Se admite Azure Firewall en centros virtuales protegidos (vWAN) en Qatar?

No, actualmente, no se admite Azure Firewall en centros virtuales protegidos (vWAN) en Qatar.

¿Cuántas conexiones paralelas puede admitir Azure Firewall?

Azure Firewall usa Azure Virtual Machines debajo de que tienen un número de conexiones de límite máximo. El número total de conexiones activas por máquina virtual es de 250 000.

El límite total por firewall es el límite de conexión de la máquina virtual (250 000) x el número de máquinas virtuales del grupo de back-end del firewall. Azure Firewall comienza con dos máquinas virtuales y se escala horizontalmente en función del uso y el rendimiento de la CPU.

¿Cuál es el comportamiento de reutilización del puerto TCP/UDP de SNAT en Azure Firewall?

Azure Firewall utiliza actualmente puertos de origen TCP/UDP para el tráfico SNAT saliente, sin tiempo de espera inactivo. Cuando se cierra una conexión TCP/UDP, el puerto TCP utilizado se ve inmediatamente como disponible para próximas conexiones.

Como solución alternativa para determinadas arquitecturas, puede implementar y escalar con NAT Gateway con Azure Firewall para proporcionar un conjunto más amplio de puertos SNAT para mayor variabilidad y disponibilidad.

¿Qué son los comportamientos NAT en Azure Firewall?

Los comportamientos de NAT específicos dependen de la configuración del firewall y del tipo de NAT configurado. Por ejemplo, el firewall tiene reglas DNAT para el tráfico entrante y reglas de red y reglas de aplicación para el tráfico saliente a través del firewall.

Para más información, consulte Comportamientos NAT de Azure Firewall.

Tiempos de espera y escalado

¿Cómo funciona la purga de conexiones?

Para cualquier mantenimiento planeado, la lógica de purga de conexiones actualiza los nodos de back-end correctamente. Azure Firewall espera 90 segundos para que se cierren las conexiones existentes. En los primeros 45 segundos, el nodo de back-end no acepta nuevas conexiones y, en el tiempo restante, responde con RST a todos los paquetes entrantes. Si es necesario, los clientes pueden volver a establecer la conectividad automáticamente con otro nodo de back-end.

¿Cómo controla Azure Firewall el apagado de instancias de máquinas virtuales durante la reducción horizontal (o vertical) de los conjuntos de escalado de máquinas virtuales o las actualizaciones de software?

El apagado de una instancia de máquina virtual de Azure Firewall puede producirse cuando se reduce horizontal o verticalmente un conjunto de escalado de máquinas virtuales o durante una actualización de software. En estos casos, se equilibra la carga de las nuevas conexiones entrantes en las instancias de firewall restantes y no se reenvían a la instancia de firewall apagada. Después de 45 segundos, el firewall comienza a rechazar las conexiones establecidas mediante el envío de paquetes RST de TCP. Después de otros 45 segundos, la máquina virtual del firewall se apaga. Para obtener más información, vea Tiempo de espera de inactividad y restablecimiento de TCP de Load Balancer.

¿Cuánto tiempo tarda Azure Firewall en escalar horizontalmente?

Azure Firewall se escala gradualmente cuando el rendimiento medio o el consumo de CPU es del 60 %, o bien el número de uso de conexiones es del 80 %. Por ejemplo, comienza a escalar horizontalmente cuando alcanza el 60 % de su rendimiento máximo. Los números de rendimiento máximo varían en función de la SKU de Azure Firewall y las características habilitadas. Para más información, consulte Rendimiento de Azure Firewall.

El escalado horizontal tarda entre cinco y siete minutos. Al realizar pruebas de rendimiento, asegúrese de probar al menos entre 10 y 15 minutos e inicie nuevas conexiones para aprovechar las ventajas de los nodos de Azure Firewall recién creados.

¿Cómo controla Azure Firewall los tiempos de espera de inactividad?

Cuando una conexión agota el tiempo de espera de inactividad (cuatro minutos sin actividad), Azure Firewall envía un paquete RST de TCP para finalizar correctamente la conexión.

Mantenimiento controlado por el cliente

¿Qué tipo de mantenimiento admite el mantenimiento controlado por el cliente?

Los servicios de Azure se someten a actualizaciones de mantenimiento periódicas para mejorar la funcionalidad, la confiabilidad, el rendimiento y la seguridad. Con un período de mantenimiento configurado, el mantenimiento del sistema operativo invitado y el mantenimiento del servicio se realizan durante esa ventana. Sin embargo, el mantenimiento controlado por el cliente no incluye actualizaciones de host ni actualizaciones de seguridad críticas.

¿Puedo recibir una notificación avanzada del evento de mantenimiento?

Las notificaciones avanzadas para el mantenimiento de Azure Firewall no están disponibles.

¿Puedo configurar una ventana de mantenimiento inferior a cinco horas?

No, se requiere un período de mantenimiento mínimo de cinco horas.

¿Puedo configurar una ventana de mantenimiento distinta de la programación diaria?

No, las ventanas de mantenimiento se configuran actualmente para que se repitan diariamente.

¿Hay casos en los que no pueda controlar determinadas actualizaciones?

El mantenimiento controlado por el cliente admite las actualizaciones del sistema operativo invitado y del servicio, que tiene en cuenta la mayoría de los elementos de mantenimiento de interés para los clientes. Sin embargo, algunas actualizaciones, como las actualizaciones de host, están fuera del ámbito del mantenimiento controlado por el cliente. En raras ocasiones, podríamos invalidar el control de la ventana de mantenimiento para solucionar problemas de seguridad de alta gravedad.

¿Los recursos de configuración de mantenimiento deben estar en la misma región que Azure Firewall?

Sí.

¿Podemos crear más de una configuración de mantenimiento para una sola instancia de Azure Firewall?

No. Actualmente, solo se puede asociar una configuración de mantenimiento a Azure Firewall.

¿Qué SKU de Azure Firewall puedo configurar para usar el mantenimiento controlado por el cliente?

Todas las SKU de Azure Firewall: mantenimiento básico, estándar y premium controlado por el cliente.

¿Cuánto tiempo tarda una directiva de configuración de mantenimiento en ser efectiva después de asignarla a Azure Firewall?

Azure Firewall puede tardar hasta 24 horas en seguir la programación de mantenimiento después de asociar la directiva de mantenimiento.

Programé una ventana de mantenimiento para una fecha futura para uno de mis recursos de Azure Firewall. ¿Se pausarán las actividades de mantenimiento en este recurso hasta entonces?

Las actividades de mantenimiento en Azure Firewall no se pausan durante el período anterior a la ventana de mantenimiento programada. Durante días que no se incluyen en la programación de mantenimiento, las operaciones de mantenimiento normales continúan como de costumbre en el recurso.

¿Cómo puedo obtener más información sobre el mantenimiento controlado por el cliente en Azure Firewall?

Para obtener más información, consulte Configuración del mantenimiento controlado por el cliente.

Azure Firewall es un servicio de seguridad de red administrado y basado en la nube que protege los recursos de Azure Virtual Network. Se trata de un firewall como servicio con estado completo que incorpora alta disponibilidad y escalabilidad a la nube sin restricciones. Puede crear, aplicar y registrar directivas de aplicaciones y de conectividad de red a nivel central en suscripciones y redes virtuales.

Para obtener una lista detallada de las características de Azure Firewall, consulte Características de Azure Firewall.

Azure Firewall se puede implementar en cualquier red virtual. Sin embargo, normalmente se implementa en una red virtual central en un modelo en estrella tipo hub-and-spoke, con otras redes virtuales emparejadas. La ruta predeterminada de las redes virtuales emparejadas se establece para que apunte a esta red virtual de firewall central. Aunque se admite el emparejamiento de red virtual global, no se recomienda debido a posibles problemas de rendimiento y latencia entre regiones. Para obtener un rendimiento óptimo, implemente un firewall por región.

Este modelo permite un control centralizado sobre varias redes virtuales radiales en distintas suscripciones y ofrece ahorros de costos al evitar la necesidad de implementar un firewall en cada red virtual. Se deben evaluar los ahorros de costos con respecto a los costos de emparejamiento asociados en función de los patrones de tráfico.

Azure Firewall se puede implementar mediante Azure Portal, PowerShell, API REST o plantillas. Para obtener instrucciones paso a paso, consulte Tutorial: Implementación y configuración de Azure Firewall mediante Azure Portal.

Azure Firewall usa reglas y colecciones de reglas. Una colección de reglas es un conjunto de reglas con el mismo orden y prioridad. Las colecciones de reglas se ejecutan en orden de prioridad. Las colecciones de reglas DNAT tienen mayor prioridad que las colecciones de reglas de red, que a su vez tienen mayor prioridad que las colecciones de reglas de aplicación. Todas las reglas finalizan.

Hay tres tipos de colecciones de reglas:

• Reglas de aplicación: configure nombres de dominio completos (FQDN) a los que se pueda acceder desde una red virtual.
• Reglas de red: configure reglas con direcciones de origen, protocolos, puertos de destino y direcciones de destino.
• Reglas NAT: Configure reglas DNAT para permitir conexiones entrantes de Internet o intranet (versión preliminar).

Para más información, veaConfiguración de reglas de Azure Firewall.

Azure Firewall se integra con Azure Monitor para ver y analizar registros. Los registros se pueden enviar a Log Analytics, Azure Storage o Event Hubs y analizarlos mediante herramientas como Log Analytics, Excel o Power BI. Para más información, consulte el Tutorial: Supervisión de los registros de Azure Firewall.

Azure Firewall es un servicio de seguridad de red administrado basado en la nube que protege los recursos de red virtual. Se trata de un firewall como servicio con estado completo que incorpora alta disponibilidad y escalabilidad a la nube sin restricciones. Está preintegrado con proveedores de seguridad como servicio (SECaaS) de terceros para mejorar la seguridad de las conexiones a Internet de red virtual y sucursal. Para más información, consulte Azure Network Security (Seguridad de red de Azure).

Application Gateway WAF proporciona protección centralizada de entrada para aplicaciones web frente a vulnerabilidades y vulnerabilidades comunes. Azure Firewall proporciona protección de entrada para protocolos no HTTP/S (como RDP, SSH y FTP), protección de salida a nivel de red para todos los puertos y protocolos, y protección a nivel de aplicación para las salidas HTTP/S.

Azure Firewall complementa los grupos de seguridad de red para proporcionar una mejor seguridad de red de "defensa en profundidad". Los grupos de seguridad de red ofrecen filtrado de tráfico de capa de red distribuida para limitar el tráfico dentro de las redes virtuales de cada suscripción. Azure Firewall proporciona una red centralizada y totalmente con estado y protección a nivel de aplicación en suscripciones y redes virtuales.

Azure Firewall es un servicio administrado con varias capas de protección, incluida la protección de plataforma con NSG de nivel de NIC (no visible). Los NSG de nivel de subred no son necesarios en AzureFirewallSubnet y están deshabilitados para evitar interrupciones del servicio.

Los puntos de conexión privados son un componente de Private Link, una tecnología que permite interactuar con los servicios paaS de Azure mediante direcciones IP privadas en lugar de las públicas. Azure Firewall se puede usar para evitar el acceso a direcciones IP públicas, por lo que se evita la filtración de datos a los servicios de Azure que no aprovechan Private Link, así como para implementar directivas de confianza cero definiendo quién de su organización necesita acceder a esos servicios paaS de Azure, ya que Private Link por defecto abre el acceso de red para toda la red corporativa.

El diseño adecuado para inspeccionar el tráfico a puntos de conexión privados con Azure Firewall dependerá de la arquitectura de red. Puede encontrar más detalles en el artículo Escenarios de Azure Firewall para inspeccionar el tráfico destinado a un punto de conexión privado.

Los puntos de conexión de servicio de red virtual son una alternativa a Private Link para controlar el acceso de red a los servicios PaaS de Azure. Incluso si el cliente sigue usando direcciones IP públicas para acceder al servicio PaaS, la subred de origen se hace visible para que el servicio PaaS de destino pueda implementar reglas de filtro y restringir el acceso por subred. Puede encontrar una comparación detallada entre ambos mecanismos en Comparar puntos de conexión privados y puntos de conexión de servicio.

Las reglas de aplicación de Azure Firewall se pueden usar para asegurarse de que no se produce ninguna filtración de datos a servicios no autorizados y de implementar directivas de acceso con una mayor granularidad más allá del nivel de subred. Normalmente, los puntos de conexión de servicio de red virtual deben habilitarse en la subred del cliente que se conectará a un servicio de Azure. Sin embargo, al inspeccionar el tráfico a los puntos de conexión de servicio con Azure Firewall, debe habilitar el punto de conexión de servicio correspondiente en la subred de Azure Firewall y deshabilitarlo en la subred del cliente real (normalmente una red virtual radial). De este modo, puede usar reglas de aplicación en Azure Firewall para controlar a qué servicios de Azure tendrán acceso las cargas de trabajo de Azure.

Para más información sobre los precios, consulte Precios de Azure Firewall.

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

Azure Firewall no mueve ni almacena datos de cliente fuera de la región donde se implementa.

No, Azure Firewall en centros virtuales protegidos (vWAN) no se admite actualmente en Qatar.

Sí, Azure Firewall admite el filtrado de tráfico entrante y saliente. El filtrado de entrada se usa normalmente para protocolos que no son HTTP, como RDP, SSH y FTP. Para el tráfico HTTP y HTTPS entrante, considere la posibilidad de usar un firewall de aplicaciones web como Azure Web Application Firewall (WAF) o las características de descarga de TLS y inspección profunda de paquetes de Azure Firewall Premium.

Sí, Azure Firewall Básico admite la tunelización forzada.

Un ping tcp no se conecta realmente al FQDN de destino. Azure Firewall bloquea las conexiones a cualquier dirección IP de destino o FQDN a menos que una regla lo permita explícitamente.

En el caso de un ping tcp, si no hay ninguna regla que permita el tráfico, el firewall responde a la solicitud de ping TCP del cliente. Esta respuesta no alcanza la dirección IP de destino ni el FQDN y no se registra. Si una regla de red permite explícitamente el acceso a la dirección IP de destino o al FQDN, la solicitud ping llega al servidor de destino y su respuesta se retransmite de nuevo al cliente. Este evento se registra en el registro de reglas de red.

No, Azure Firewall no admite de forma nativa el emparejamiento BGP. Sin embargo, la característica rutas SNAT de Autolearn usa indirectamente BGP a través de Azure Route Server.

Puede usar Azure PowerShell para desasignar y asignar Azure Firewall. El proceso varía en función de la configuración.

Para un firewall sin una NIC de administración:

# Stop the firewall
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$azfw.Deallocate()
Set-AzFirewall -AzureFirewall $azfw

# Start the firewall
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$vnet = Get-AzVirtualNetwork -ResourceGroupName "RG Name" -Name "VNet Name"
$publicip1 = Get-AzPublicIpAddress -Name "Public IP1 Name" -ResourceGroupName "RG Name"
$publicip2 = Get-AzPublicIpAddress -Name "Public IP2 Name" -ResourceGroupName "RG Name"
$azfw.Allocate($vnet, @($publicip1, $publicip2))
Set-AzFirewall -AzureFirewall $azfw

Para un firewall con una NIC de administración:

# Stop the firewall
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$azfw.Deallocate()
Set-AzFirewall -AzureFirewall $azfw

# Start the firewall
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$vnet = Get-AzVirtualNetwork -ResourceGroupName "RG Name" -Name "VNet Name"
$pip = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "azfwpublicip"
$mgmtPip = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "mgmtpip"
$azfw.Allocate($vnet, $pip, $mgmtPip)
Set-AzFirewall -AzureFirewall $azfw

Para un firewall en un centro virtual protegido:

# Stop the firewall
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$azfw.Deallocate()
Set-AzFirewall -AzureFirewall $azfw

# Start the firewall
$virtualhub = Get-AzVirtualHub -ResourceGroupName "vHUB RG Name" -Name "vHUB Name"
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "Firewall RG Name"
$azfw.Allocate($virtualhub.Id)
Set-AzFirewall -AzureFirewall $azfw

Nota

Al detener e iniciar el firewall, la facturación se detiene e inicia en consecuencia. Sin embargo, la dirección IP privada puede cambiar, lo que puede afectar a la conectividad si se configuran las tablas de rutas.

Se recomienda configurar zonas de disponibilidad durante la implementación inicial. Sin embargo, puede volver a configurarlos después de la implementación si:

• El firewall se implementa en una red virtual (no se admite en centros virtuales protegidos).
• La región admite zonas de disponibilidad.
• Todas las direcciones IP públicas adjuntas se configuran con las mismas zonas.

Para volver a configurar zonas de disponibilidad:

1. Desasigne el firewall:

   $azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
   $azfw.Deallocate()
   Set-AzFirewall -AzureFirewall $azfw
   

2. Actualice la configuración de zona y asigne el firewall:

   $azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
   $vnet = Get-AzVirtualNetwork -ResourceGroupName "RG Name" -Name "VNet Name"
   $pip = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "azfwpublicip"
   $mgmtPip = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "mgmtpip"
   $azfw.Allocate($vnet, $pip, $mgmtPip)
   $azfw.Zones = 1, 2, 3
   Set-AzFirewall -AzureFirewall $azfw
   

Sí:

• Azure Firewall y la red virtual deben estar en el mismo grupo de recursos.
• La dirección IP pública puede estar en un grupo de recursos diferente.
• Todos los recursos (Firewall de Azure, red virtual, IP pública) deben estar en la misma suscripción.

Un estado de aprovisionamiento con errores indica que se produjo un error en una actualización de configuración en una o varias instancias de back-end. Azure Firewall permanece operativo, pero la configuración podría ser incoherente. Vuelva a intentar la actualización hasta que el estado de aprovisionamiento cambie a Correcto.

Azure Firewall usa una configuración activa-activa con varios nodos de back-end. Durante el mantenimiento planeado, la purga de conexiones garantiza actualizaciones correctas. En el caso de errores no planeados, un nuevo nodo reemplaza al conmutado por error y la conectividad se restaura normalmente en 10 segundos.

Sí, los nombres de firewall están limitados a 50 caracteres.

Una subred /26 garantiza que haya suficientes direcciones IP para el escalado a medida que Azure Firewall aprovisiona instancias de máquina virtual adicionales.

No, una subred /26 es suficiente para todos los escenarios de escalado.

Azure Firewall se escala automáticamente en función del uso de CPU, el rendimiento y el recuento de conexiones. La capacidad de rendimiento oscila entre 2,5 y 3 Gbps inicialmente a 30 Gbps (SKU estándar) o 100 Gbps (SKU Premium).

Sí. Para más información, consulte Límites, cuotas y restricciones de suscripción y servicios de Azure.

No, actualmente no se permite mover un grupo de direcciones IP a otro grupo de recursos.

Un comportamiento estándar de un firewall de red es asegurarse de que las conexiones TCP se mantengan activas y cerrarlas de inmediato si no hay ninguna actividad. El tiempo de espera de inactividad de TCP de Azure Firewall es de cuatro minutos. Esta configuración no es configurable por el usuario, pero puede ponerse en contacto con el Soporte técnico de Azure para aumentar el tiempo de espera de inactividad para las conexiones entrantes y salientes hasta 15 minutos. No se puede cambiar el tiempo de espera de inactividad para el tráfico horizontal de derecha a izquierda.

Si un período de inactividad es mayor que el valor de tiempo de espera, no hay ninguna garantía de que todavía exista la sesión TCP o HTTP. Una práctica común es usar TCP Keep-alive. Esta práctica mantiene la conexión activa durante un periodo más largo. Para más información, consulte estos ejemplos de .NET.

Sí, pero debe configurar el firewall en modo de tunelización forzada. Esta configuración crea una interfaz de administración con una dirección IP pública que usa Azure Firewall para sus operaciones. Esta IP pública es para el tráfico de administración. Se usa exclusivamente en la plataforma Azure y no puede usarse para ningún otro propósito. La red de la ruta de acceso a los datos de inquilino se puede configurar sin una dirección IP pública y el tráfico de Internet se puede tunelizar de manera forzada a otro firewall o bloquearse completamente.

Sí. Para obtener más información, consulte Copia de seguridad de Azure Firewall y de la directiva de Azure Firewall con Logic Apps.

Para un acceso seguro a los servicios de PaaS, se recomiendan los puntos de conexión de servicio. Puede elegir habilitar puntos de conexión de servicio en la subred de Azure Firewall y deshabilitarlos en las redes virtuales de radios conectadas. De este modo se beneficia de ambas características: la seguridad de los puntos de conexión y el registro central de todo el tráfico.

Sí, puede usar Azure Firewall en una red virtual de concentrador para enrutar y filtrar el tráfico entre varias redes virtuales de radio. Las subredes de cada una de las redes virtuales de radio deben tener una ruta definida por el usuario (UDR) que apunte a la instancia de Azure Firewall como puerta de enlace predeterminada para que este escenario funcione correctamente.

Sí. Sin embargo, la configuración de las UDR para redirigir el tráfico entre subredes de la misma red virtual requiere más atención. Aunque el uso del intervalo de direcciones de red virtual como prefijo de destino para la UDR es suficiente, también enruta todo el tráfico de una máquina a otra de la misma subred a través de la instancia de Azure Firewall. Para evitar esto, incluya una ruta para la subred en la UDR con un tipo de próximo salto de red virtual. La administración de estas rutas podría ser problemática y estar sujeta a errores. El método recomendado para la segmentación de redes internas es usar grupos de seguridad de red, que no necesitan UDR.

Azure Firewall no aplica SNAT cuando la dirección IP de destino es un intervalo IP privado por IANA RFC 1918 o IANA RFC 6598 para redes privadas. Si su organización usa un intervalo de direcciones IP públicas para las redes privadas, Azure Firewall aplicará SNAT al tráfico para una de las direcciones IP privadas de firewall en AzureFirewallSubnet. Puede configurar Azure Firewall de modo que no aplique SNAT al intervalo de direcciones IP públicas. Para más información, consulte Aplicación de SNAT por parte de Azure Firewall a intervalos de direcciones IP privadas.

Además, al tráfico que procesan las reglas de aplicación siempre se le aplica SNAT. Si desea ver la dirección IP inicial del origen en los registros de tráfico de FQDN, puede usar reglas de red con el FQDN de destino.

La tunelización forzada se admite cuando se crea un nuevo Firewall. No se puede configurar un firewall existente para la tunelización forzada. Para más información, consulte Tunelización forzada de Azure Firewall.

Azure Firewall debe tener conectividad directa a Internet. Si AzureFirewallSubnet aprende una ruta predeterminada a la red local mediante BGP, debe reemplazarla por una UDR 0.0.0.0/0 con el valor NextHopType establecido como Internet para mantener la conectividad directa a Internet.

Si la configuración requiere tunelización forzada a una red local y puede determinar los prefijos de las direcciones IP de destino de los destinos de Internet, puede configurar estos intervalos con la red local como el próximo salto mediante una ruta definida por el usuario en AzureFirewallSubnet. O bien, puede usar BGP para definir estas rutas.

• Dirección URL: los asteriscos funcionan cuando se sitúan en el extremo derecho o en el extremo izquierdo. Si un asterisco está a la izquierda, no puede formar parte del FQDN.
• FQDN: los asteriscos funcionan cuando se ponen en el extremo izquierdo.
• GENERAL: los asteriscos del lado izquierdo significan literalmente que cualquier cosa a la izquierda coincide, lo que significa que coinciden varios subdominios o variaciones de nombres de dominio potencialmente no deseados; vea los ejemplos siguientes.

Ejemplos:

Tipo	Regla	¿Compatible?	Ejemplos válidos
TargetURL (en inglés)	www.contoso.com	Sí	www.contoso.com www.contoso.com/
TargetURL (en inglés)	*.contoso.com	Sí	any.contoso.com/ sub1.any.contoso.com
TargetURL (en inglés)	*contoso.com	Sí	example.anycontoso.com sub1.example.contoso.com contoso.com Advertencia: este uso de caracteres comodín también permite variaciones potencialmente no deseadas o peligrosas, como th3re4lcontoso.com. Se deben usar con precaución.
TargetURL (en inglés)	www.contoso.com/test	Sí	www.contoso.com/test www.contoso.com/test/ www.contoso.com/test?with_query=1
TargetURL (en inglés)	www.contoso.com/test/*	Sí	www.contoso.com/test/anything Nota: www.contoso.com/testno coincide (última barra diagonal)
TargetURL (en inglés)	www.contoso.*/test/*	No
TargetURL (en inglés)	www.contoso.com/test?example=1	No
TargetURL (en inglés)	www.contoso.*	No
TargetURL (en inglés)	www.*contoso.com	No
TargetURL (en inglés)	www.contoso.com:8080	No
TargetURL (en inglés)	*.contoso.*	No
TargetFQDN	www.contoso.com	Sí	www.contoso.com
TargetFQDN	*.contoso.com	Sí	any.contoso.com Nota: si quiere permitir contoso.com específicamente, debe incluir contoso.com en la regla. De lo contrario, la conexión se descarta de forma predeterminada porque la solicitud no coincide con ninguna regla.
TargetFQDN	*contoso.com	Sí	example.anycontoso.com contoso.com
TargetFQDN	www.contoso.*	No
TargetFQDN	*.contoso.*	No

No. Azure Firewall bloquea el acceso a Active Directory de forma predeterminada. Para permitir el acceso, configure la etiqueta de servicio AzureActiveDirectory. Para más información, consulte Etiquetas de servicio de Azure Firewall.

Sí, puede usar Azure PowerShell para ello:

# Add a Threat Intelligence allowlist to an Existing Azure Firewall.

# Create the allowlist with both FQDN and IPAddresses
$fw = Get-AzFirewall -Name "Name_of_Firewall" -ResourceGroupName "Name_of_ResourceGroup"
$fw.ThreatIntelWhitelist = New-AzFirewallThreatIntelWhitelist `
   -FQDN @("fqdn1", "fqdn2", …) -IpAddress @("ip1", "ip2", …)

# Or Update FQDNs and IpAddresses separately
$fw = Get-AzFirewall -Name $firewallname -ResourceGroupName $RG
$fw.ThreatIntelWhitelist.IpAddresses = @($fw.ThreatIntelWhitelist.IpAddresses + $ipaddresses)
$fw.ThreatIntelWhitelist.fqdns = @($fw.ThreatIntelWhitelist.fqdns + $fqdns)


Set-AzFirewall -AzureFirewall $fw

Un ping de TCP no se conecta realmente al FQDN de destino. Azure Firewall no permite una conexión a ninguna dirección IP o FQDN de destino a menos que haya una regla explícita que lo permita.

El ping TCP es un caso de uso único en el que, si no hay ninguna regla permitida, el propio firewall responde a la solicitud de ping TCP del cliente aunque el ping TCP no llegue a la dirección IP o FQDN de destino. En este caso, el evento no se registra. Si hay una regla de red que permite el acceso a la dirección IP o FQDN de destino, la solicitud de ping llega al servidor de destino y su respuesta se retransmite de nuevo al cliente. Este evento se registra en el registro de reglas de red.

Sí. Para más información, consulte Límites, cuotas y restricciones de suscripción y servicios de Microsoft Azure.

No, actualmente no se permite mover un grupo de direcciones IP a otro grupo de recursos.

Un comportamiento estándar de un firewall de red es asegurarse de que las conexiones TCP se mantengan activas y cerrarlas de inmediato si no hay ninguna actividad. El tiempo de espera de inactividad de TCP de Azure Firewall es de cuatro minutos. Esta configuración no es configurable por el usuario, pero puede ponerse en contacto con el Soporte técnico de Azure para aumentar el tiempo de espera de inactividad para las conexiones entrantes y salientes hasta 15 minutos. No se puede cambiar el tiempo de espera de inactividad para el tráfico horizontal de derecha a izquierda.

Si un período de inactividad es mayor que el valor de tiempo de espera, no hay ninguna garantía de que todavía exista la sesión TCP o HTTP. Una práctica común es usar TCP Keep-alive. Esta práctica mantiene la conexión activa durante un periodo más largo. Para más información, consulte estos ejemplos de .NET.

Sí, pero debe configurar el firewall en modo de tunelización forzada. Esta configuración crea una interfaz de administración con una dirección IP pública que usa Azure Firewall para sus operaciones. Esta IP pública es para el tráfico de administración. Se usa exclusivamente en la plataforma Azure y no puede usarse para ningún otro propósito. La red de la ruta de acceso a los datos de inquilino se puede configurar sin una dirección IP pública y el tráfico de Internet se puede tunelizar de manera forzada a otro firewall o bloquearse completamente.

Azure Firewall no mueve ni almacena los datos de los clientes fuera de la región en los que se implementan.

Sí. Para obtener más información, consulte Copia de seguridad de Azure Firewall y de la directiva de Azure Firewall con Logic Apps.

No, actualmente, no se admite Azure Firewall en centros virtuales protegidos (vWAN) en Qatar.

Azure Firewall usa Azure Virtual Machines debajo de que tienen un número de conexiones de límite máximo. El número total de conexiones activas por máquina virtual es de 250 000.

El límite total por firewall es el límite de conexión de la máquina virtual (250 000) x el número de máquinas virtuales del grupo de back-end del firewall. Azure Firewall comienza con dos máquinas virtuales y se escala horizontalmente en función del uso y el rendimiento de la CPU.

Azure Firewall utiliza actualmente puertos de origen TCP/UDP para el tráfico SNAT saliente, sin tiempo de espera inactivo. Cuando se cierra una conexión TCP/UDP, el puerto TCP utilizado se ve inmediatamente como disponible para próximas conexiones.

Como solución alternativa para determinadas arquitecturas, puede implementar y escalar con NAT Gateway con Azure Firewall para proporcionar un conjunto más amplio de puertos SNAT para mayor variabilidad y disponibilidad.

Los comportamientos de NAT específicos dependen de la configuración del firewall y del tipo de NAT configurado. Por ejemplo, el firewall tiene reglas DNAT para el tráfico entrante y reglas de red y reglas de aplicación para el tráfico saliente a través del firewall.

Para más información, consulte Comportamientos NAT de Azure Firewall.

Para cualquier mantenimiento planeado, la lógica de purga de conexiones actualiza los nodos de back-end correctamente. Azure Firewall espera 90 segundos para que se cierren las conexiones existentes. En los primeros 45 segundos, el nodo de back-end no acepta nuevas conexiones y, en el tiempo restante, responde con RST a todos los paquetes entrantes. Si es necesario, los clientes pueden volver a establecer la conectividad automáticamente con otro nodo de back-end.

El apagado de una instancia de máquina virtual de Azure Firewall puede producirse cuando se reduce horizontal o verticalmente un conjunto de escalado de máquinas virtuales o durante una actualización de software. En estos casos, se equilibra la carga de las nuevas conexiones entrantes en las instancias de firewall restantes y no se reenvían a la instancia de firewall apagada. Después de 45 segundos, el firewall comienza a rechazar las conexiones establecidas mediante el envío de paquetes RST de TCP. Después de otros 45 segundos, la máquina virtual del firewall se apaga. Para obtener más información, vea Tiempo de espera de inactividad y restablecimiento de TCP de Load Balancer.

Azure Firewall se escala gradualmente cuando el rendimiento medio o el consumo de CPU es del 60 %, o bien el número de uso de conexiones es del 80 %. Por ejemplo, comienza a escalar horizontalmente cuando alcanza el 60 % de su rendimiento máximo. Los números de rendimiento máximo varían en función de la SKU de Azure Firewall y las características habilitadas. Para más información, consulte Rendimiento de Azure Firewall.

El escalado horizontal tarda entre cinco y siete minutos. Al realizar pruebas de rendimiento, asegúrese de probar al menos entre 10 y 15 minutos e inicie nuevas conexiones para aprovechar las ventajas de los nodos de Azure Firewall recién creados.

Cuando una conexión agota el tiempo de espera de inactividad (cuatro minutos sin actividad), Azure Firewall envía un paquete RST de TCP para finalizar correctamente la conexión.

Los servicios de Azure se someten a actualizaciones de mantenimiento periódicas para mejorar la funcionalidad, la confiabilidad, el rendimiento y la seguridad. Con un período de mantenimiento configurado, el mantenimiento del sistema operativo invitado y el mantenimiento del servicio se realizan durante esa ventana. Sin embargo, el mantenimiento controlado por el cliente no incluye actualizaciones de host ni actualizaciones de seguridad críticas.

Las notificaciones avanzadas para el mantenimiento de Azure Firewall no están disponibles.

No, se requiere un período de mantenimiento mínimo de cinco horas.

No, las ventanas de mantenimiento se configuran actualmente para que se repitan diariamente.

El mantenimiento controlado por el cliente admite las actualizaciones del sistema operativo invitado y del servicio, que tiene en cuenta la mayoría de los elementos de mantenimiento de interés para los clientes. Sin embargo, algunas actualizaciones, como las actualizaciones de host, están fuera del ámbito del mantenimiento controlado por el cliente. En raras ocasiones, podríamos invalidar el control de la ventana de mantenimiento para solucionar problemas de seguridad de alta gravedad.

Sí.

No. Actualmente, solo se puede asociar una configuración de mantenimiento a Azure Firewall.

Todas las SKU de Azure Firewall: mantenimiento básico, estándar y premium controlado por el cliente.

Azure Firewall puede tardar hasta 24 horas en seguir la programación de mantenimiento después de asociar la directiva de mantenimiento.

Las actividades de mantenimiento en Azure Firewall no se pausan durante el período anterior a la ventana de mantenimiento programada. Durante días que no se incluyen en la programación de mantenimiento, las operaciones de mantenimiento normales continúan como de costumbre en el recurso.

Para obtener más información, consulte Configuración del mantenimiento controlado por el cliente.