Problemas e limitações conhecidos 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, revise esses problemas conhecidos para evitar problemas comuns e planejar soluções adequadas.

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

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 em *East US 2 EUAP*	Básico, Standard e Premium	- Não podes implementar um novo Azure Firewall 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, consulte Como posso configurar zonas de disponibilidade após a implantação?
- Zona física 2 no *Norte da Europa* - Zona física 3 no *Sudeste Asiático*	Standard e Premium	- Não é possível implantar um novo Firewall do Azure na zona 3 no Sudeste Asiático ou na zona 2 no Norte da Europa. - Se você parar um Firewall do Azure existente implantado nessas zonas, ele não poderá ser reiniciado. Para obter mais informações, consulte Zonas de disponibilidade física e lógica.	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, consulte 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	- Não podes instalar um novo Azure Firewall 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, consulte Como posso configurar zonas de disponibilidade após a implantação?
Zona física 2 na *Espanha Central*	Básico, Standard e Premium	- Não podes implementar um novo Azure Firewall 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, consulte Como posso configurar zonas de disponibilidade após a implantação?
*Governo do Estado da Virgínia dos EUA*	Premium	- Não há capacidade para o Azure Firewall Premium SKU no US Gov Virginia, implantações zonais e não zonais são bloqueadas.	Implante a SKU Standard do Firewall do Azure ou implante a SKU Premium em uma região diferente.
Zona física 3 em *US Gov Virginia*	Básico e Standard	- As implantações zonais estão bloqueadas na zona física 3 em US Gov Virginia. - Você deve selecionar manualmente as zonas disponíveis para uma 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 na *West US 2*	Básico, Standard e Premium	- Não podes implementar um novo Azure Firewall 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, consulte Como posso configurar zonas de disponibilidade após a implantação?

Advertência

Se você interromper uma implantação existente do Firewall do Azure em qualquer uma dessas regiões com restrição de capacidade, talvez não seja possível iniciá-la novamente devido a limitações de capacidade contínuas. Planeie adequadamente antes de parar 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	Mitigação
Suporte DNAT para endereços IP privados limitado à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 Standard e Premium Firewall, não na versão Basic.	Nenhuma
O processo de desalocação e alocação do Firewall do Azure não é suportado quando as regras DNAT de IP privado são configuradas	O processo de alocação do Firewall do Azure falha quando as regras DNAT privadas são configuradas	1. Desalocar o Azure Firewall 2. Exclua todas as regras DNAT de IP privado 3. Aloque o Firewall do Azure e aguarde até que o IP privado seja preenchido 4. Reconfigure as regras de DNAT de IP privado com o endereço IP privado adequado
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 SNAT para o seu endereço IP público. Os protocolos não TCP/UDP são suportados entre sub-redes spoke e VNets.	O Azure Firewall utiliza o Balanceador de Carga Standard que não suporta atualmente SNAT para protocolos IP. Estamos explorando opções para oferecer suporte a protocolos não-TCP/UDP para tráfego vinculado à Internet em uma versão futura.
Quando um Firewall do Azure é desalocado e, em seguida, 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 de forma dinâmica a partir da sub-rede do Firewall do Azure. Quando um novo endereço IP privado é atribuído que é diferente do anterior, isso causa problemas de roteamento.	Você precisa reconfigurar as UDRs (User Defined Routes) 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 altera as configurações de DNS numa política de firewall principal, as políticas subordinadas, quando estão vinculadas a ela, podem não conseguir resolver nomes de domínio nas suas regras.	Configure as configurações de DNS diretamente em cada política filho em vez de confiar na política pai. Estamos trabalhando em uma correção para permitir a herança de configurações de DNS.
Falta suporte do PowerShell e CLI para ICMP	O Azure PowerShell e a CLI não dão suporte ao ICMP como um protocolo válido em regras de rede.	Ainda é possível usar o ICMP como um protocolo através do portal e da API REST. Estamos trabalhando para adicionar ICMP no PowerShell e na CLI em breve.
As etiquetas FQDN requerem um protocolo: porta a definir	As regras de aplicação com tags FQDN requerem definição de porta e protocolo.	Pode utilizar https como a porta: valor de protocolo. Estamos trabalhando para tornar o campo port: protocol opcional quando as tags FQDN são usadas.
Não há suporte para mover um firewall para um grupo de recursos ou assinatura diferente	Não há suporte para mover um firewall para um grupo de recursos ou assinatura diferente.	O suporte a esta funcionalidade está no nosso roteiro. Para mover uma firewall para um grupo de recursos ou uma subscrição diferente, tem de eliminar a instância atual e recriá-la no novo grupo de recursos ou subscrição.
Alertas de inteligência de ameaças podem ser ocultados	As regras da rede com destino 80/443 para filtragem de saída mascaram alertas de inteligência sobre ameaças quando configuradas para o modo apenas de alerta.	Crie filtragem de saída para 80/443 usando regras de aplicativo. Ou altere o modo de inteligência de ameaças para Alertar e Negar.
Com hubs virtuais seguros, as zonas de disponibilidade só podem ser configuradas durante a implantação.	Não é possível configurar Zonas de Disponibilidade após a implantação de um firewall com hubs virtuais protegidos.	Por design.
SNAT nas conexões de entrada	As regras DNAT de entrada sempre alteram o endereço IP de origem para o tráfego de retorno.	Para controlar o IP do cliente original para o tráfego da Web, configure seus clientes ou servidores proxy para incluir o IP original nos 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 à filtragem de FQDN do SQL somente no modo proxy (porta 1433)	Para o Banco de Dados SQL do Azure, o Azure Synapse Analytics e a Instância Gerenciada SQL do Azure: A filtragem de FQDN do SQL é suportada apenas no modo proxy (porta 1433). Para IaaS SQL do Azure: Se você estiver usando portas não padrão, poderá especificar essas portas nas regras do aplicativo.	Para SQL no modo de redirecionamento (o padrão se estiver conectando de dentro do Azure), você pode, em vez disso, filtrar o acesso usando a marca de serviço 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 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 introduz nenhuma restrição mais específica.	Use serviços de retransmissão SMTP autenticados, que normalmente se conectam através da porta TCP 587, mas também suportam outras portas. Para obter mais informações, consulte Solucionar problemas de conectividade SMTP de saída no Azure. Outra opção é implantar o Firewall do Azure em uma assinatura padrão do Enterprise Agreement (EA). O Firewall do Azure em uma assinatura EA pode se comunicar com endereços IP públicos usando a porta TCP 25 de saída. Pode funcionar noutros tipos de subscrição, mas não é garantido. Para endereços IP privados, como redes virtuais, VPNs e Rota Expressa do Azure, o Firewall do Azure dá suporte a uma conexão de saída na porta TCP 25.
Esgotamento das portas SNAT	Atualmente, o Azure Firewall suporta 2.496 portas por endereço IP público por instância de um conjunto de dimensionamento de máquina virtual de back-end. Por padrão, há duas instâncias do Conjunto de Escalas de Máquina Virtual. Assim, existem 4.992 portas por fluxo (IP de destino, porta de destino e protocolo (TCP ou UDP). O firewall pode ser dimensionado até um máximo de 20 instâncias.	A exaustão da porta SNAT é uma limitação da plataforma. Você pode contornar os limites configurando implantações do Firewall do Azure com um mínimo de cinco endereços IP públicos para implantações suscetíveis à exaustão do SNAT. Adicionar mais endereços IP públicos aumenta as portas SNAT disponíveis em cinco vezes. Aloque a partir de um prefixo de endereço IP para simplificar as permissões a jusante. Para obter uma solução mais permanente, você pode implantar um gateway NAT para superar os limites de porta SNAT. A implantação do gateway NAT é suportada para implantações de rede virtual. Para obter mais informações, consulte Dimensionar portas SNAT com o ANT da Rede Virtual do Azure.
O DNAT não é compatível quando o Túnel Forçado está ativado	Os firewalls implantados com o Túnel Forçado habilitado não suportam o acesso de entrada da Internet devido ao roteamento assimétrico.	A falta de suporte DNAT com tunelamento forçado é por projeto 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.	FTP passivo estabelece diferentes conexões para controle e canais 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 dados e os canais de controle usam endereços IP de origem diferentes, dependendo da configuração do servidor FTP.	Uma configuração SNAT explícita é planejada. Enquanto isso, você pode configurar seu servidor FTP para aceitar dados e controlar canais de diferentes endereços IP de origem (consulte um exemplo para o IIS). Como alternativa, considere o uso de um único endereço IP ao enfrentar problemas de conectividade FTP.
FTP passivo de entrada pode não funcionar dependendo da configuração do seu servidor FTP	FTP passivo estabelece diferentes conexões para controle e canais de dados. As ligações de entrada no Firewall do Azure são submetidas a SNAT para um dos endereços IP privados do firewall, de forma a garantir o encaminhamento simétrico. O FTP pode falhar quando os dados e os canais de controle 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á a ser investigada. Enquanto isso, você pode configurar seu servidor FTP para aceitar dados e controlar canais de diferentes endereços IP de origem.
FTP ativo não funciona quando o cliente FTP deve alcançar um servidor FTP através da Internet.	FTP ativo utiliza um comando PORT do cliente FTP que direciona o 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 utilizador que atravessa o Firewall do Azure passa por NAT para comunicações baseadas na Internet, fazendo com que o comando PORT seja considerado inválido pelo servidor FTP.	A falha do FTP ativo é uma limitação geral do FTP ativo quando usado com NAT do lado do cliente.
A métrica NetworkRuleHit carece de uma dimensão de protocolo	A métrica ApplicationRuleHit permite o protocolo baseado em filtragem, mas esse recurso 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 1-65535 em regras de rede e aplicativo, no entanto, as regras NAT só dão suporte a portas no intervalo 1-63999.	A restrição nas portas da 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 atualizações paralelas não são suportadas.	Uma correção está sendo investigada.
O Firewall do Azure usa cabeçalhos SNI TLS para filtrar o tráfego HTTPS e MSSQL	Se o software do navegador ou servidor não oferecer suporte à extensão SNI (Indicador de Nome do Servidor), você não poderá se conectar por meio do Firewall do Azure.	Se o software do navegador ou servidor não suportar SNI, você poderá controlar a conexão usando uma regra de rede em vez de uma regra de aplicativo. Veja Indicação do Nome de Servidor para o software que suporte o SNI.
Não é possível adicionar marcas de política de firewall usando o portal ou os modelos do Azure Resource Manager (ARM)	A Política de Firewall do Azure tem uma limitação no suporte de atualizações que impede que se adicione uma etiqueta usando o portal do Azure ou Modelos ARM. O seguinte erro é gerado: Não foi possível salvar as tags do recurso.	Uma correção está sendo investigada. Ou, você pode usar o cmdlet `Set-AzFirewallPolicy` do Azure PowerShell para atualizar tags.
IPv6 não suportado atualmente	Se você adicionar um endereço IPv6 a uma regra, o firewall falhará.	Use apenas endereços IPv4. O suporte a IPv6 está sob investigação.
Não há suporte para remoção de RuleCollectionGroups usando modelos ARM.	A remoção de um RuleCollectionGroup usando modelos ARM não é suportada e resulta em falha.	Remover RuleCollectionGroups usando modelos ARM não é uma operação suportada.
Regra DNAT para permitir qualquer (*) será tráfego SNAT.	Se uma regra DNAT permitir qualquer (*) como o endereço IP de origem, então uma regra de rede implícita corresponde ao tráfego VNet-VNet e irá sempre SNAT o tráfego.	O comportamento SNAT automático para regras DNAT com qualquer fonte é 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 seguro com um provedor de segurança, isso resulta em uma rota assíncrona para o tráfego DNAT retornado, que vai para o provedor de segurança.	Não suportado.
Erro encontrado ao criar mais de 2.000 coleções de regras.	O número máximo de coleções de regras NAT/Application ou Network é 2000 (limite do Resource Manager).	O limite de coleta de 2.000 regras é uma limitação atual.
Não é possível implantar o Firewall com zonas de disponibilidade com um endereço IP público recém-criado	Ao implantar um Firewall com Zonas de Disponibilidade, você não pode usar um endereço IP público recém-criado.	Primeiro, crie um novo endereço IP público redundante de zona e, em seguida, 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 ao 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 regras 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 a 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 oferece suporte ao tráfego de retorno de VMs internas para o seu próprio endereço IP público para destinos de regra DNAT.	Uma solução para esta limitação está atualmente em desenvolvimento.

Problemas conhecidos do Firewall do Azure Premium

Nota

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

O Firewall Premium do Azure tem os seguintes problemas conhecidos:

Problema	Descrição	Mitigação
Suporte ESNI para resolução FQDN em HTTPS	O SNI criptografado não é suportado no handshake HTTPS.	Hoje apenas o Firefox suporta ESNI através de configuração personalizada. A solução sugerida é desativar o recurso ESNI.
A Autenticação de Certificação de Cliente não é suportada	Os certificados de cliente são usados para criar uma confiança de identidade mútua entre o cliente e o servidor. Os certificados de cliente são usados durante uma negociação TLS. O firewall do Azure renegocia uma conexão com o servidor e não tem acesso à chave privada dos certificados de cliente.	Nenhuma
QUIC/HTTP3	QUIC é a nova versão principal do HTTP. É um protocolo baseado em UDP acima de 80 (PLAN) e 443 (SSL). A inspeção FQDN/URL/TLS não é suportada.	Configurar a passagem do tráfego UDP pelas portas 80/443 como regras de rede.
Certificados assinados por clientes não confiáveis	O firewall não confia nos 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 errado para alertas HTTP sem inspeção TLS	Quando o IDPS gera alertas para tráfego HTTP de texto simples 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 certificados	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	TLS 1.3 é parcialmente suportado. 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.	As atualizações estão sendo investigadas.
Expiração do certificado de CA intermediário TLSi	Em alguns casos exclusivos, o certificado de autoridade de certificação intermediário pode expirar dois meses antes da data de expiração original.	Renove o certificado de autoridade de certificação intermediário dois meses antes da data de expiração original. Uma correção está sendo investigada.

Próximos passos

Feedback

Esta página foi útil?

Last updated on 2025-11-27