Compartilhar via

Problemas conhecidos e limitações do Firewall do Azure

Este artigo ajuda você a entender os problemas e limitações conhecidos atuais no Firewall do Azure. Atualizamos essas informações à medida que os problemas são resolvidos, portanto, verifique regularmente o status mais recente.

Antes de implantar o Firewall do Azure ou solucionar problemas de implantações existentes, examine esses problemas conhecidos para evitar problemas comuns e planejar soluções alternativas apropriadas.

Para os limites de serviço do Firewall do Azure, consulte os limites, cotas e restrições de serviço e assinatura do Azure.

Restrições de capacidade atuais

As seguintes zonas estão atualmente enfrentando restrições de capacidade:

Região/Zonas SKU Restrições Recomendação
Zona física 1 e zona 4 no Leste dos EUA 2 EUAP Básico, Standard e Premium - Você não pode implantar um novo Firewall do Azure na zona 1 e na zona 4. Recomendamos que você implante um novo Firewall do Azure nas zonas de disponibilidade restantes ou use uma região diferente. Para configurar um firewall existente, confira Como posso configurar zonas de disponibilidade após a implantação?
- Zona física 2 na zona física do Norte da Europa
- 3noSudeste Asiático		 Standard e Premium - Você não pode implantar um novo Firewall do Azure na zona 3 no Sudeste da Ásia ou na zona 2 no Norte da Europa.

- Se você interromper um Firewall do Azure existente implantado nessas zonas, ele não poderá ser reiniciado.

Para obter mais informações, consulte Zonas de disponibilidade físicas e lógicas.		 Recomendamos que você implante um novo Firewall do Azure nas zonas de disponibilidade restantes ou use uma região diferente. Para configurar um firewall existente, confira Como posso configurar zonas de disponibilidade após a implantação?
Zona física 3 no Centro-Sul dos EUA Básico, Standard e Premium - Você não pode implantar um novo Firewall do Azure na zona 3.

Data estimada disponível: 31 de março de 2026		 Recomendamos que você implante um novo Firewall do Azure nas zonas de disponibilidade restantes ou use uma região diferente. Para configurar um firewall existente, confira Como posso configurar zonas de disponibilidade após a implantação?
Zona física 2 no Centro da Espanha Básico, Standard e Premium - Você não pode implantar um novo Firewall do Azure na zona 2.

Data estimada disponível: 31 de dezembro de 2026		 Recomendamos que você implante um novo Firewall do Azure nas zonas de disponibilidade restantes ou use uma região diferente. Para configurar um firewall existente, confira Como posso configurar zonas de disponibilidade após a implantação?
Governador dos EUA Virgínia Premium - Não há capacidade para o SKU Premium do Firewall do Azure no US Gov Virginia; as implantações zonais e não zonais estão bloqueadas. Implante o SKU Standard do Firewall do Azure ou implante o SKU Premium em uma região diferente.
Zona física 3 no US Gov - Virgínia Básico e Standard - As implantações zonais são bloqueadas na zona física 3 no US Gov - Virgínia.

– Você deve selecionar manualmente as zonas disponíveis para implantação bem-sucedida, criando uma experiência de implantação abaixo do ideal.		 Selecione as zonas 1 e 2 para implantações zonais ou use uma região diferente.
Zona física 2 no Oeste dos EUA 2 Básico, Standard e Premium - Você não pode implantar um novo Firewall do Azure na zona 2. Recomendamos que você implante um novo Firewall do Azure nas zonas de disponibilidade restantes ou use uma região diferente. Para configurar um firewall existente, confira Como posso configurar zonas de disponibilidade após a implantação?

Aviso

Se você parar uma implantação existente do Firewall do Azure em qualquer uma dessas regiões restritas à capacidade, talvez não seja possível iniciá-la novamente devido a limitações de capacidade contínuas. Planeje com antecedência antes de interromper instâncias de firewall nessas regiões.

Problemas conhecidos do Firewall do Azure Standard

O Firewall do Azure Standard tem os seguintes problemas conhecidos:

Problema Descrição Atenuação
Suporte para DNAT para endereços IP privados limitados às versões Standard e Premium O suporte para DNAT no endereço IP privado do Firewall do Azure está disponível apenas nas versões do Firewall Standard e Premium, não na versão Básica. Nenhum
Não há suporte para o processo de desalocação e alocação do Firewall do Azure quando as regras de DNAT de IP privado são configuradas O processo de alocação do Firewall do Azure falha quando as regras de DNAT privadas são configuradas 1. Desalocar o Azure Firewall
2. Excluir todas as regras de DNAT de IP privado
3. Aloque o Firewall do Azure e aguarde até que o IP privado seja preenchido
4. Reconfigurar as regras de DNAT de IP privado com o endereço IP privado apropriado
As regras de filtragem de rede para protocolos não TCP/UDP (por exemplo, ICMP) não funcionam para o tráfego vinculado à Internet As regras de filtragem de rede para protocolos não TCP/UDP não funcionam com o SNAT para seu endereço IP público. Protocolos não TCP/UDP têm suporte entre VNets e sub-redes spoke. O Firewall do Azure usa o Standard Load Balancer que não dá suporte a SNAT para protocolos IP. Estamos explorando opções para dar suporte a protocolos não TCP/UDP para tráfego associado à Internet em uma versão futura.
Quando um Firewall do Azure é desalocado e alocado novamente, ele pode receber um novo endereço IP privado Após o processo de desalocação e alocação do Firewall do Azure, um endereço IP privado é atribuído dinamicamente da sub-rede do Firewall do Azure. Quando um novo endereço IP privado é atribuído que é diferente do anterior, ele causa problemas de roteamento. Você precisa reconfigurar as UDRs (Rotas Definidas pelo Usuário) existentes com o novo endereço IP privado. Uma correção está sendo investigada para manter o endereço IP privado após o processo de alocação.
As políticas de firewall filho não herdam as configurações de DNS das políticas pai. Quando você altera as configurações de DNS em uma política de firewall pai, as políticas filho vinculadas a ela podem não conseguir resolver nomes de domínio em suas regras. Defina as configurações de DNS diretamente em cada política filho em vez de depender da política pai. Estamos trabalhando em uma correção para permitir a herança das configurações de DNS.
Suporte do PowerShell e da CLI ausente para ICMP O Azure PowerShell e a CLI não dão suporte ao ICMP como um protocolo válido nas regras de rede. Ainda é possível usar o ICMP como protocolo por meio do portal e da API REST. Estamos trabalhando para adicionar o ICMP no PowerShell e na CLI em breve.
As marcas de FQDN requerem que um protocolo:porta seja definido As regras de aplicativo com marcas de FQDN exigem a definição de um protocolo:porta. Você pode usar HTTPS como o valor de porta:protocolo. Estamos trabalhando para tornar opcional o campo de porta: protocolo quando tags FQDN são usadas.
Não há suporte para a movimentação de um firewall para um grupo de recursos ou uma assinatura diferente Não há suporte para a movimentação de um firewall para um grupo de recursos ou uma assinatura diferente. O suporte a essa funcionalidade está em nosso roteiro. Para mover um firewall para um grupo de recursos ou uma assinatura diferente, você precisa excluir a instância atual e recriá-la no novo grupo de recursos ou na nova assinatura.
Alertas de inteligência contra ameaças podem ser mascarados As regras de rede com destino 80/443 para filtragem de saída mascaram os alertas de inteligência de ameaças quando configuradas para o modo somente alerta. Crie a filtragem de saída para 80/443 usando regras de aplicativo. Ou, alterar o modo de inteligência contra ameaças para Alertar e negar.
Com hubs virtuais protegidos, as zonas de disponibilidade podem ser configuradas somente durante a implantação. Não é possível configurar as Zonas de Disponibilidade depois que um firewall com hubs virtuais protegidos é implantado. Por design.
SNAT em conexões de entrada As regras DNAT de entrada sempre alteram o endereço IP de origem para o tráfego de retorno. Para acompanhar o IP do cliente original para tráfego da Web, configure seus clientes ou servidores proxy para incluir o IP original em cabeçalhos XFF . O Firewall do Azure preserva esses endereços IP no cabeçalho XFF e adiciona o IP do Firewall ao cabeçalho XFF ao processar regras de tráfego da Web.
Suporte para filtragem de FQDN do SQL apenas no modo de proxy (porta 1433) Para o Banco de Dados SQL do Azure, o Azure Synapse Analytics e a Instância Gerenciada de SQL do Azure:

A filtragem de FQDN do SQL tem suporte apenas no modo de proxy (porta 1433).

Para IaaS do SQL do Azure:

Se você estiver usando portas não padrão, poderá especificar essas portas nas regras do aplicativo.		 Para o SQL no modo de redirecionamento (o padrão ao se conectar de dentro do Azure), você pode filtrar o acesso usando a tag de serviço do SQL como parte das regras de rede do Firewall do Azure.
O tráfego SMTP de saída na porta TCP 25 está bloqueado A plataforma do Azure bloqueia mensagens de email de saída enviadas diretamente para domínios externos (como outlook.com e gmail.com) na porta TCP 25. Bloquear o tráfego SMTP de saída na porta 25 é o comportamento padrão da plataforma no Azure. O Firewall do Azure não apresenta nenhuma restrição mais específica. Use serviços de retransmissão de SMTP autenticado, que normalmente se conectam por meio da porta TCP 587, mas também permitem o uso de outras portas. Para saber mais, confira Solucionar problemas de conectividade de SMTP de saída no Azure.

Outra opção é implementar o Firewall do Azure numa subscrição padrão do Contrato Enterprise (EA). O Firewall do Azure numa subscrição EA pode comunicar com endereços IP públicos através da porta TCP de saída 25. Ele pode funcionar em outros tipos de assinatura, mas não é garantido. Para endereços IP privados como redes virtuais, VPNs e Azure ExpressRoute, o Firewall do Azure suporta uma ligação de saída na porta TCP 25.
Esgotamento de porta SNAT Atualmente, o Firewall do Azure dá suporte a 2.496 portas por endereço IP público por instância de back-end de conjunto de dimensionamento de máquinas virtuais. Por padrão, há duas instâncias do Conjunto de Dimensionamento de Máquinas Virtuais. Portanto, há 4.992 portas por fluxo (IP de destino, porta de destino e protocolo (TCP ou UDP). É possível escalar o firewall verticalmente para um máximo de 20 instâncias. O esgotamento da porta SNAT é uma limitação da plataforma. Para lidar com os limites, configure implantações do Firewall do Azure suscetíveis ao esgotamento de SNAT com um mínimo de cinco endereços IP públicos. Adicionar mais endereços IP públicos aumenta as portas SNAT disponíveis em cinco vezes. Aloque de um prefixo de endereço IP para simplificar as permissões de downstream. Para obter uma solução mais permanente, é possível implantar um gateway NAT a fim de superar os limites de porta SNAT. A implantação do gateway NAT é suportada para implantações de rede virtual.

Para saber mais, veja Dimensionar portas SNAT com o NAT da Rede Virtual do Azure.
O DNAT não é compatível com o Túnel Forçado habilitado Os firewalls implantados com o Túnel Forçado habilitado não são compatíveis com acesso de entrada proveniente da Internet devido ao roteamento assimétrico. A falta de suporte para DNAT com Forced Tunneling é intencional devido ao roteamento assimétrico. O caminho de retorno para conexões de entrada passa pelo firewall local, que não vê a conexão estabelecida.
O FTP passivo de saída pode não funcionar para firewalls com vários endereços IP públicos, dependendo da configuração do servidor FTP. O FTP Passivo estabelece conexões diferentes para canais de controle e de dados. Quando um Firewall com vários endereços IP públicos envia dados de saída, ele seleciona aleatoriamente um de seus endereços IP públicos para o endereço IP de origem. O FTP pode falhar quando os canais de controle e dados usam endereços IP de origem diferentes, dependendo da configuração do servidor FTP. Uma configuração SNAT explícita está em planejamento. Enquanto isso, você pode configurar o servidor FTP para aceitar canais de controle e de dados de diferentes endereços IP de origem (confira um exemplo do IIS). Como alternativa, considere o uso de um único endereço IP ao enfrentar problemas de conectividade FTP.
O FTP passivo de entrada pode não funcionar dependendo da configuração do servidor FTP O FTP Passivo estabelece conexões diferentes para canais de controle e de dados. As conexões de entrada no Firewall do Azure estão no modo SNAT para um dos endereços IP privados do firewall a fim de garantir o roteamento simétrico. O FTP pode falhar quando os canais de controle e dados usam endereços IP de origem diferentes, dependendo da configuração do servidor FTP. A preservação do endereço IP de origem original está sendo investigada. Enquanto isso, você pode configurar o servidor FTP para aceitar canais de controle e de dados de diferentes endereços IP de origem.
O FTP ativo não funciona quando o cliente FTP deve acessar um servidor FTP pela Internet. O FTP ativo usa um comando PORT do cliente FTP que informa ao servidor FTP qual IP e porta usar para o canal de dados. O comando PORT utiliza o IP privado do cliente que não pode ser alterado. O tráfego do lado do cliente que atravessa o Firewall do Azure é NATed para comunicações baseadas na Internet, tornando o comando PORT visto como inválido pelo servidor FTP. A falha de FTP ativa é uma limitação geral do FTP Ativo quando usado com NAT do lado do cliente.
A métrica NetworkRuleHit não tem uma dimensão de protocolo A métrica ApplicationRuleHit permite o protocolo baseado em filtragem, mas essa funcionalidade está ausente na métrica NetworkRuleHit correspondente. Uma correção está sendo investigada.
Não há suporte para regras NAT com portas entre 64000 e 65535 O Firewall do Azure permite qualquer porta no intervalo de 1 a 65535 nas regras de rede e de aplicativo, no entanto, as regras de NAT dão suporte apenas a portas no intervalo de 1 a 63999. A restrição nas portas de regra NAT é uma limitação atual.
As atualizações de configuração podem levar em média cinco minutos Uma atualização de configuração do Firewall do Azure pode levar de três a cinco minutos em média e não há suporte para atualizações paralelas. Uma correção está sendo investigada.
O Firewall do Azure usa cabeçalhos de TLS SNI para filtrar tráfego HTTPS e MSSQL Se o navegador ou o software para servidores não der suporte à extensão SNI (Indicação de Nome do Servidor), você não poderá se conectar por meio do Firewall do Azure. Se o software de navegador ou servidor não derem suporte ao SNI, você poderá controlar a conexão usando uma regra de rede em vez de uma regra de aplicativo. Consulte Indicação de Nome de Servidor para conhecer software que seja compatível com a SNI.
Não é possível adicionar marcas de política de firewall usando o portal ou Azure Resource Manager (ARM) A Política de Firewall do Azure tem uma limitação de suporte de patch que impede a adição de marcação usando o portal do Azure ou os modelos do ARM. O seguinte erro foi gerado: Não foi possível salvar as marcas do recurso. Uma correção está sendo investigada. Como alternativa, você pode usar o cmdlet Set-AzFirewallPolicy do Azure PowerShell para atualizar as marcas.
IPv6 sem suporte no momento Se você adicionar um endereço IPv6 a uma regra, o firewall falhará. Use somente endereços IPv4. O suporte a IPv6 está em investigação.
Não há suporte para a remoção do RuleCollectionGroups usando modelos do ARM. Não há suporte para a remoção de um RuleCollectionGroup usando modelos do ARM e isto resulta em falha. A remoção de RuleCollectionGroups usando modelos do ARM não é uma operação com suporte.
A regra DNAT para permitir qualquer (*) permitirá o tráfego no modo SNAT. Se uma regra DNAT permitir qualquer (*) como o endereço IP de origem, uma regra de rede implícita corresponderá ao tráfego VNet-VNet e sempre fará o SNAT do tráfego. O comportamento SNAT automático para regras DNAT com qualquer origem é uma limitação atual.
Não há suporte para a adição de uma regra DNAT a um hub virtual seguro com um provedor de segurança. Quando você adiciona uma regra DNAT a um hub virtual protegido com um provedor de segurança, ela resulta em uma rota assíncrona para o tráfego DNAT retornado, que vai para o provedor de segurança. Sem suporte.
Erro encontrado ao criar mais de 2.000 coleções de regras. O número máximo de coleções de regra de NAT/Aplicativo ou de Rede é 2.000 (limite do Resource Manager). O limite de coleta de 2.000 regras é uma limitação atual.
Não é possível implantar um firewall com Zonas de Disponibilidade com um endereço IP público recém-criado Ao implantar um firewall com zonas de disponibilidade, não é possível usar um endereço IP público recém-criado. Primeiro, crie um endereço IP público com redundância de zona e atribua esse endereço IP criado anteriormente durante a implantação do firewall.
Não há suporte para a associação de um endereço IP público com o Firewall do Azure em um cenário entre locatários. Se você criar um endereço IP público no locatário A, não poderá associá-lo a um firewall implantado no locatário B. Nenhum.
As VMs por trás do Firewall do Azure não podem se conectar a destinos de regra DNAT usando o IP público do firewall Quando as VMs roteiam o tráfego por meio do Firewall do Azure e tentam se conectar aos recursos configurados com regras DNAT usando o endereço IP público do firewall, a conexão falha. A falha de conexão ocorre porque o Firewall do Azure não dá suporte ao retorno de tráfego de VMs internas para o próprio endereço IP público do firewall para destinos de regras DNAT. Uma solução para essa limitação está em desenvolvimento no momento.

Problemas conhecidos do Firewall do Azure Premium

Observação

Qualquer problema que se aplica ao Standard também se aplica ao Premium.

O Firewall do Azure Premium tem os seguintes problemas conhecidos:

Problema Descrição Atenuação
Suporte de ESNI para a resolução de FQDN em HTTPS Não há suporte para SNI criptografada no handshake HTTPS. Atualmente, somente o Firefox dá suporte a ESNI por meio de configuração personalizada. A solução alternativa sugerida é desabilitar o recurso ESNI.
Não há suporte para a Autenticação de Certificação do Cliente Os certificados de cliente são usados para criar uma confiança de identidade mútua entre o cliente e o servidor. Eles são usados durante uma negociação de TLS. O Firewall do Azure renegocia uma conexão com o servidor e não tem acesso à chave privada dos certificados do cliente. Nenhum
QUIC/HTTP3 QUIC é a nova versão principal do HTTP. É um protocolo baseado em UDP sobre 80 (PLAN) e 443 (SSL). Não há suporte para inspeção de FQDN/URL/TLS. Faça a configuração transmitindo UDP 80/443 como regras de rede.
Certificados assinados de cliente não confiáveis O firewall não confia em certificados assinados pelo cliente quando os recebe de um servidor Web baseado em intranet. Uma correção está sendo investigada.
O IDPS exibe o endereço IP de origem incorreto para alertas HTTP sem inspeção do TLS Quando o IDPS gera alertas para o tráfego HTTP de texto sem formatação para endereços IP públicos, ele exibe o endereço IP interno em vez do endereço IP de origem original. Uma correção está sendo investigada.
Propagação de Certificado Depois que um certificado de autoridade de certificação é aplicado no firewall, pode levar entre 5 a 10 minutos para que o certificado entre em vigor. Uma correção está sendo investigada.
Suporte a TLS 1.3 O TLS 1.3 tem suporte parcial. O túnel TLS do cliente para o firewall é baseado no TLS 1.2 e do firewall para o servidor Web externo é baseado no TLS 1.3. Atualizações estão sendo investigadas.
Expiração do certificado de autoridade de certificação intermediária TLSi Em alguns casos exclusivos, o certificado de autoridade de certificação intermediária pode expirar dois meses antes da data de validade original. Renove o certificado de autoridade de certificação intermediário dois meses antes da data de validade original. Uma correção está sendo investigada.

Próximas etapas

  • Last updated on