Compartilhar via

Problemas conhecidos e limitações do Firewall do Azure

  • Artigo

Este artigo lista os problemas conhecidos do Firewall do Azure. Ele é atualizado à medida que os problemas são resolvidos.

Para conhecer as limitações do Firewall do Azure, veja limites, cotas e restrições de assinatura e serviço do Azure.

Firewall do Azure Standard

O Firewall do Azure Standard tem os seguintes problemas conhecidos:

Observação

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

Problema Descrição Mitigaçã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 destina-se a empresas e, portanto, é limitado às versões do Firewall Standard e Premium. Nenhum
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 as opções para dar suporte a esse cenário em uma versão futura.
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 esse campo opcional quando marcas de 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. Isso ocorre por design.
SNAT em conexões de entrada Além de DNAT, as conexões via o endereço IP público do firewall (entrada) estão no modo SNAT para um dos IPs privados do firewall. Esse requisito hoje (e também para NVAs ativa/ativa) garante o roteamento simétrico. Para preservar a fonte original para HTTP/S, use os cabeçalhos XFF. Por exemplo, use um serviço como o Azure Front Door ou o Gateway de Aplicativo do Azure na frente do firewall. Você também pode adicionar o WAF como parte Porta da frente do Azure e encadear ao firewall.
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 As mensagens de email de saída enviadas diretamente para domínios externos (como outlook.com e gmail.com) na porta TCP 25 são bloqueadas pela plataforma do Azure. Esse é o comportamento de plataforma padrão 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. Atualmente, ele também pode funcionar em outros tipos de assinatura, mas não é garantido que funcione. 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. Essa é 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. Isso 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. Essa abordagem tem suporte 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. Isso ocorre por design devido ao roteamento assimétrico. O caminho de retorno para conexões de entrada passa pelo firewall local, que não viu 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 usar um só endereço IP nessa situação.
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. Esse comando PORT usa 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. Essa é uma limitação geral do FTP ativo quando usado com um 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. Esta é 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.
A atualização de vários grupos de IP falha com um erro de conflito. Quando você atualiza dois ou mais Grupos de IP anexados ao mesmo firewall, um dos recursos entra em um estado de falha. Esse é um problema conhecido e uma limitação conhecida.

Quando você atualiza um Grupo de IP, ele dispara uma atualização em todos os firewalls aos quais o IPGroup está anexado. Se uma atualização em um segundo Grupo de IP for iniciada enquanto o firewall ainda estiver no estado Atualizando, a atualização do IPGroup falhará.

Para evitar a falha, os Grupos de IP anexados ao mesmo firewall precisam ser atualizados um de cada vez. Permita tempo suficiente entre as atualizações para que o firewall saia do estado Atualizando.
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. Esta 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. Esta é 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. Isso resulta em uma rota assíncrona para o tráfego DNAT que retorna, que vai para o provedor de segurança. Não há 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). Esta é uma limitação atual.
Cabeçalho XFF em HTTP/S Os cabeçalhos XFF são substituídos pelo endereço IP de origem original, como visto pelo firewall. Isso é aplicável para os seguintes casos de uso:
- Solicitações HTTP
- Solicitações HTTPS com terminação TLS		 Uma correção está sendo investigada.
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.
A zona física 2 no Norte da Europa não está disponível para implantações de firewall. Não é possível implantar um novo firewall com a zona física 2. Além disso, se você interromper um firewall existente implantado na zona física 2, ele não poderá ser reiniciado. Para obter mais informações, confira Zonas de disponibilidade físicas e lógicas. Para novos firewalls, implante com as 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?.

Firewall do Azure 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.
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 nos certificados assinados pelo cliente quando os recebe de um servidor Web baseado em intranet. Uma correção está sendo investigada.
Endereço IP de origem errado em Alertas com o IDPS para HTTP (sem a inspeção de TLS). Quando o tráfego HTTP de texto sem formatação está em uso, o IDPS emite um novo alerta e o destino é um endereço IP público, o endereço IP de origem exibido está errado (o endereço IP interno é exibido em vez do 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