Problemas e limitações conhecidos do Firewall do Azure
Este artigo lista os problemas conhecidos do Firewall do Azure. É atualizado à medida que os problemas são resolvidos.
Para conhecer as limitações do Firewall do Azure, consulte Limites, cotas e restrições de assinatura e serviço do Azure.
Azure Firewall Standard
O Firewall do Azure Standard tem os seguintes problemas conhecidos:
Nota
Qualquer problema que se aplique ao Standard também se aplica ao Premium.
| Problema | Description | 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 destina-se a empresas, por isso está limitado às versões Standard e Premium Firewall. | Nenhuma |
| 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 VNets e sub-redes spoke. | O Azure Firewall utiliza o Balanceador de Carga Standard que não suporta atualmente SNAT para protocolos IP. Estamos explorando opções para dar suporte a esse cenário em uma versão futura. |
| Suporte do PowerShell e CLI em falta 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 protocolo port: . | Pode utilizar https como a porta: valor de protocolo. Estamos trabalhando para tornar esse campo 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. | Apoiar 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 mascarados | As regras de rede com destino 80/443 para filtragem de saída mascaram alertas de inteligência de 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. | Esta ação é propositada. |
| SNAT em conexões de entrada | Além do DNAT, as conexões através do endereço IP público do firewall (entrada) são SNATed para um dos IPs privados do firewall. Este requisito hoje (também para NVAs Ativos/Ativos) para garantir roteamento simétrico. | Para preservar a fonte original para HTTP/S, considere o uso de cabeçalhos XFF . Por exemplo, use um serviço como o Azure Front Door ou o Azure Application Gateway na frente do firewall. Você também pode adicionar WAF como parte do Azure Front Door e cadeia ao firewall. |
| 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 | 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 Azure. Este é o comportamento de plataforma padrão 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. 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 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 Firewall do Azure oferece suporte a 2.496 portas por endereço IP público por instância do Conjunto de Escala de Máquina Virtual de back-end. Por padrão, há duas instâncias do Conjunto de Dimensionamento 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. | Esta é 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. Isso 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. Essa abordagem é 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 é suportado com o Túnel Forçado 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. | 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. | 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 usar um único endereço IP nessa situação. |
| 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 conexões de entrada no Firewall do Azure são SNATed para um dos endereços IP privados do firewall para garantir o roteamento 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. Este 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. | Esta é uma limitação geral do FTP ativo quando usado com NAT do lado do cliente. |
| A métrica NetworkRuleHit está faltando 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. | 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 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 de suporte de patch que impede que você adicione uma marca 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. |
| A atualização de vários grupos IP falha com erro de conflito. | Quando você atualiza dois ou mais grupos IP conectados ao mesmo firewall, um dos recursos entra em um estado de falha. | Este é um problema/limitação conhecido. Quando você atualiza um grupo IP, ele dispara uma atualização em todos os firewalls aos quais o IPGroup está conectado. Se uma atualização para um segundo Grupo IP for iniciada enquanto o firewall ainda estiver no estado de Atualização , a atualização do IPGroup falhará. Para evitar a falha, os grupos IP conectados ao mesmo firewall devem ser atualizados um de cada vez. Permita tempo suficiente entre as atualizações para permitir que o firewall saia do estado de Atualizaçã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. | Esta 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 sempre SNAT o 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 de retorno, 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). | 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, conforme visto pelo firewall. Isto aplica-se aos seguintes casos de utilização: - Pedidos HTTP - Solicitações HTTPS com terminação TLS |
Uma correção está sendo investigada. |
| 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. |
| A zona física 2 no leste do Japão não está disponível para implantações de firewall. | Não é possível implantar um novo firewall com zona física 2. Além disso, se você parar um firewall existente implantado na zona física 2, ele não poderá ser reiniciado. Para obter mais informações, consulte Zonas de disponibilidade física e lógica. | Para novos firewalls, implante com as 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?. |
Azure Firewall Premium
O Firewall Premium do Azure tem os seguintes problemas conhecidos:
| Problema | Description | 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 esse recurso. |
| 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. | Configure a passagem UDP 80/443 como regras de rede. |
| Certificados assinados por clientes não confiáveis | Os certificados assinados pelo cliente não são confiáveis pelo firewall depois de recebidos de um servidor Web baseado em intranet. | Uma correção está sendo investigada. |
| Endereço IP de origem errado em Alertas com IDPS para HTTP (sem inspeção TLS). | Quando o tráfego HTTP de texto simples está em uso e 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 endereço IP 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. |