Condividi tramite

Problemi noti e limitazioni di Firewall di Azure

  • Articolo

Questo articolo elenca i problemi noti di Firewall di Azure. Viene aggiornato man mano che i problemi vengono risolti.

Per le limitazioni di Firewall di Azure, vedere Limiti, quote e vincoli dei servizi e della sottoscrizione di Azure.

Firewall di Azure Standard

Firewall di Azure Standard presenta i problemi noti seguenti:

Nota

Qualsiasi problema applicabile alla versione Standard vale anche per la versione Premium.

Problema Descrizione Strategia di riduzione del rischio
Il supporto DNAT per indirizzi IP privati è ​​limitato alle versioni Standard e Premium Il supporto per DNAT sull'indirizzo IP privato del Firewall di Azure è destinato alle aziende, pertanto è limitato alle versioni Standard e Premium del firewall. None
Le regole di filtro di rete per i protocolli non TCP/UDP (ad esempio ICMP) non funzionano per il traffico associato a Internet Le regole di filtro di rete per i protocolli non TCP/UDP non funzionano con SNAT per l'indirizzo IP pubblico. I protocolli non TCP/UDP sono supportati tra le subnet spoke e le reti virtuali. Firewall di Azure usa Load Balancer Standard, che attualmente non supporta SNAT per i protocolli IP. Sono in fase di studio opzioni per supportare questo scenario in una versione futura.
Supporto di PowerShell e CLI mancante per ICMP Azure PowerShell e l'interfaccia della riga di comando non supportano ICMP come protocollo valido nelle regole di rete. È comunque possibile usare ICMP come protocollo tramite il portale e l'API REST. A breve ICMP sarà aggiunto anche in PowerShell e nell'interfaccia della riga di comando.
I tag FQDN richiedono l'impostazione di protocol:port Le regole di applicazione con tag FQDN richiedono la definizione port:protocol. È possibile usare https come valore port:protocol. A breve questo campo sarà reso facoltativo quando vengono usati i tag FQDN.
Lo spostamento di un firewall in un altro gruppo di risorse o un'altra sottoscrizione non è supportato Lo spostamento di un firewall in un altro gruppo di risorse o un'altra sottoscrizione non è supportato. Il supporto di questa funzionalità è previsto per il futuro. Per spostare un firewall in un altro gruppo di risorse o sottoscrizione, è necessario eliminare l'istanza corrente e ricrearla nel nuovo gruppo di risorse o sottoscrizione.
Gli avvisi di Intelligence sulle minacce potrebbero essere mascherati Le regole di rete con destinazione 80/443 per i filtri in uscita mascherano gli avvisi di intelligence quando sono configurati in modalità di solo avviso. Creare filtri in uscita per 80/443 usando le regole dell'applicazione. Oppure impostare la modalità di intelligence per le minacce su Alert and Deny (Avviso e rifiuto).
Con gli hub virtuali protetti, le zone di disponibilità possono essere configurate solo durante la distribuzione. Non è possibile configurare le zone di disponibilità dopo la distribuzione di un firewall con hub virtuali protetti. Questo si verifica per motivi strutturali.
SNAT sulle connessioni in ingresso Oltre a DNAT, le connessioni tramite l'indirizzo IP pubblico del firewall (in ingresso) sono inviate tramite SNAT a uno degli indirizzi IP privati del firewall. Questo requisito è attualmente previsto (anche per le appliance virtuali di rete in modalità attivo/attivo) per consentire il routing simmetrico. Per mantenere l'origine iniziale per HTTP/S, prendere in considerazione l'uso delle intestazioni XFF. Usare ad esempio un servizio come Frontdoor di Azure o Gateway applicazione di Azure prima del firewall. È anche possibile aggiungere WAF come parte di Frontdoor di Azure e concatenarlo al firewall.
Supporto per il filtro FQDN di SQL disponibile solo in modalità proxy (porta 1433) Per Database SQL di Azure, Azure Synapse Analytics e Istanza gestita di SQL di Azure:

Il filtro FQDN di SQL è supportato solo in modalità proxy (porta 1433).

Per SQL IaaS di Azure:

Se si usano porte non standard, è possibile specificarle nelle regole dell'applicazione.		 Per SQL in modalità di reindirizzamento, che è l'impostazione predefinita se la connessione viene effettuata dall'interno di Azure, è invece possibile filtrare l'accesso usando il tag di servizio SQL nell'ambito delle regole di rete di Firewall di Azure.
Il traffico SMTP in uscita sulla porta TCP 25 è bloccato I messaggi di posta elettronica in uscita inviati direttamente a domini esterni (ad esempio outlook.com e gmail.com) sulla porta TCP 25 vengono bloccati dalla piattaforma Azure. Questo è il comportamento predefinito della piattaforma in Azure. Firewall di Azure non introduce alcuna restrizione più specifica. Usare i servizi di inoltro SMTP autenticati, che in genere si connettono tramite la porta TCP 587, ma supportano anche altre porte. Per altre informazioni, vedere Risolvere i problemi di connettività SMTP in uscita in Azure.

Un'altra opzione è quella di distribuire Firewall di Azure in una sottoscrizione Enterprise Agreement (EA) standard. Firewall di Azure in una sottoscrizione EA può comunicare con gli indirizzi IP pubblici usando la porta TCP 25 in uscita. Attualmente potrebbe funzionare anche con altri tipi di sottoscrizione, ma non è garantito che funzioni. Per gli indirizzi IP privati, come le reti virtuali, le VPN e Azure ExpressRoute, Firewall di Azure supporta una connessione in uscita sulla porta TCP 25.
Esaurimento della porta SNAT Firewall di Azure supporta attualmente 2.496 porte per indirizzo IP pubblico per ogni istanza del set di scalabilità di macchine virtuali back-end. Per impostazione predefinita, sono disponibili due istanze del set di scalabilità di macchine virtuali. Sono quindi presenti 4.992 porte per flusso (IP di destinazione, porta di destinazione e protocollo (TCP o UDP). Il firewall è scalabile fino a un massimo di 20 istanze. È una limitazione della piattaforma. È possibile aggirare i limiti configurando le distribuzioni di Firewall di Azure con almeno cinque indirizzi IP pubblici per le distribuzioni soggette a esaurimento SNAT. In questo modo la disponibilità delle porte SNAT aumenta di cinque volte. Allocare da un prefisso di indirizzo IP per semplificare le autorizzazioni downstream. Per una soluzione più permanente, è possibile distribuire un gateway NAT per superare i limiti delle porte SNAT. Questo approccio è supportato per le distribuzioni di rete virtuale.

Per altre informazioni, vedere Ridimensionare le porte SNAT con NAT di rete virtuale di Azure.
DNAT non è supportato con il tunneling forzato abilitato I firewall distribuiti con il tunneling forzato abilitato non supportano l'accesso in ingresso da Internet a causa del routing simmetrico. Si tratta di una scelta per progettazione. Il percorso di ritorno per le connessioni in ingresso passa attraverso il firewall locale, che non ha visto la connessione stabilita.
L'FTP passivo in uscita potrebbe non funzionare per i firewall con più indirizzi IP pubblici, a seconda della configurazione del server FTP. FTP passivo stabilisce connessioni diverse per canali di controllo e dei dati. Quando un firewall con più indirizzi IP pubblici invia dati in uscita, seleziona in modo casuale uno degli indirizzi IP pubblici come indirizzo IP di origine. L'FTP potrebbe avere esito negativo quando i canali di dati e di controllo usano indirizzi IP di origine diversi, a seconda della configurazione del server FTP. È stata pianificata una configurazione SNAT esplicita. Nell'attesa, è possibile configurare il server FTP in modo che accetti i canali di dati e di controllo da indirizzi IP di origine diversi (vedere un esempio per IIS). In alternativa, è consigliabile usare un solo indirizzo IP in questa situazione.
L'FTP passivo in ingresso potrebbe non funzionare a seconda della configurazione del server FTP FTP passivo stabilisce connessioni diverse per canali di controllo e dei dati. Le connessioni in ingresso in Firewall di Azure vengono inviate tramite SNAT a uno degli indirizzi IP privati del firewall per assicurare un routing simmetrico. L'FTP potrebbe avere esito negativo quando i canali di dati e di controllo usano indirizzi IP di origine diversi, a seconda della configurazione del server FTP. La possibilità di mantenere l'indirizzo IP di origine originale è in fase di analisi. Nel frattempo, è possibile configurare il server FTP in modo che accetti i canali di dati e di controllo da indirizzi IP di origine diversi.
L'FTP attivo non funziona quando il client FTP deve raggiungere un server FTP attraverso Internet. L'FTP attivo usa un comando PORT del client FTP che indica al server FTP l'IP e la porta da usare per il canale dati. Questo comando PORT usa l'IP privato del client che non può essere modificato. Il traffico lato client che attraversa il Firewall di Azure è sottoposto a NAT per le comunicazioni basate su Internet, rendendo il comando PORT non valido per il server FTP. Questa è una limitazione generale di Active FTP quando viene usato con NAT lato client.
Per la metrica NetworkRuleHit manca una dimensione del protocollo La metrica ApplicationRuleHit consente il protocollo basato su filtro, ma questa funzionalità non è presente nella metrica NetworkRuleHit corrispondente. È in corso la ricerca di una correzione.
Le regole NAT con porte comprese tra 64000 e 65535 non sono supportate Firewall di Azure consente l'uso di qualsiasi porta compresa nell'intervallo 1-65535 nelle regole di rete e dell'applicazione, tuttavia le regole NAT supportano solo le porte comprese nell'intervallo 1-63999. Si tratta di una limitazione corrente.
Gli aggiornamenti della configurazione potrebbero richiedere in media cinque minuti Un aggiornamento della configurazione di Firewall di Azure può richiedere in media da tre a cinque minuti e gli aggiornamenti paralleli non sono supportati. È in corso la ricerca di una correzione.
Firewall di Azure usa le intestazioni TLS di SNI per filtrare il traffico HTTPS e MSSQL Se il software del browser o del server non supporta l'estensione Server Name Indicator (SNI), non è possibile connettersi tramite Firewall di Azure. Se il software del browser o del server non supporta SNI, è possibile controllare la connessione usando una regola di rete anziché una regola dell'applicazione. Vedere Indicazione nome server per il software che supporta SNI.
Non è possibile aggiungere tag di criteri firewall usando il portale o i modelli di Azure Resource Manager (ARM) Criterio Firewall di Azure ha una limitazione del supporto delle patch che impedisce di aggiungere un tag usando il portale di Azure o i modelli ARM. Viene generato l'errore seguente: Non è possibile salvare i tag per la risorsa. È in corso la ricerca di una correzione. In alternativa, è possibile usare il cmdlet Set-AzFirewallPolicy di Azure PowerShell per aggiornare i tag.
IPv6 non è attualmente supportato Se si aggiunge un indirizzo IPv6 a una regola, si verifica un errore del firewall. Usare solo indirizzi IPv4. Il supporto di IPv6 è in fase di analisi.
L'aggiornamento di più gruppi IP ha esito negativo con un errore di conflitto. Quando si aggiornano due o più gruppi IP collegati allo stesso firewall, una delle risorse entra in uno stato di errore. È un problema o una limitazione nota.

Quando si aggiorna un gruppo IP, si attiva un aggiornamento in tutti i firewall a cui il gruppo IP è collegato. Se l'aggiornamento di un secondo gruppo IP viene avviato mentre il firewall è ancora in stato di aggiornamento, l'aggiornamento del gruppo IP ha esito negativo.

Per evitare l'errore, i gruppi IP collegati allo stesso firewall devono essere aggiornati uno alla volta. Lasciare un intervallo di tempo sufficiente tra un aggiornamento e l'altro per consentire al firewall di uscire dallo stato di aggiornamento.
La rimozione di RuleCollectionGroups tramite i modelli ARM non è supportata. La rimozione di RuleCollectionGroup tramite i modelli ARM non è supportata e genera un errore. Non è un'operazione supportata.
La regola DNAT per consentire qualsiasi (*) eseguirà il traffico SNAT. Se una regola DNAT consente qualsiasi (*) come indirizzo IP di origine, una regola di rete implicita corrisponde al traffico VNet-VNet ed esegue sempre lo SNAT del traffico. Si tratta di una limitazione corrente.
L'aggiunta di una regola DNAT a un hub virtuale protetto con un provider di sicurezza non è supportata. Ciò comporta un percorso asincrono per il traffico DNAT restituito, che viene indirizzato al provider di sicurezza. Non supportato.
Errore riscontrato durante la creazione di più di 2.000 raccolte di regole. Il numero massimo di raccolte di regole NAT/Applicazione o Rete è 2000 (limite di Resource Manager). Si tratta di una limitazione corrente.
Intestazione XFF in HTTP/S Le intestazioni XFF vengono sovrascritte con l'indirizzo IP di origine come visualizzato dal firewall. Si applica ai casi d'uso seguenti:
- Richieste HTTP
- Richieste HTTPS con terminazione TLS		 È in corso la ricerca di una correzione.
Non è possibile distribuire il firewall con le zone di disponibilità con un indirizzo IP pubblico appena creato Quando si distribuisce un firewall con zone di disponibilità, non è possibile usare un indirizzo IP pubblico appena creato. Creare per prima cosa un nuovo indirizzo IP pubblico ridondante di zona, quindi assegnare l'indirizzo IP creato in precedenza durante la distribuzione del firewall.
La zona fisica 2 in Giappone orientale non è disponibile per le distribuzioni del firewall. Non è possibile distribuire un nuovo firewall con la zona fisica 2. Inoltre, se si arresta un firewall esistente distribuito nella zona fisica 2, non è possibile riavviarlo. Per altre informazioni, vedere Zone di disponibilità fisiche e logiche. Per i nuovi firewall, eseguire la distribuzione con le zone di disponibilità rimanente o usare un'area diversa. Per configurare un firewall esistente, vedere Come configurare le zone di disponibilità dopo la distribuzione?.

Firewall di Azure Premium

Firewall di Azure Premium presenta i problemi noti seguenti:

Problema Descrizione Strategia di riduzione del rischio
Supporto ESNI per la risoluzione FQDN in HTTPS L'SNI crittografata non è supportato nell'handshake HTTPS. Attualmente solo Firefox supporta ESNI tramite una configurazione personalizzata. La soluzione suggerita è quella di disabilitare questa funzionalità.
L'autenticazione della certificazione client non è supportata I certificati client vengono usati per creare attendibilità reciproca sull'identità tra il client e il server. I certificati client vengono usati durante una negoziazione TLS. Firewall di Azure rinegozia una connessione con il server e non ha accesso alla chiave privata dei certificati client. None
QUIC/HTTP3 QUIC è la nuova versione principale di HTTP. È un protocollo basato su UDP su 80 (PLAN) e 443 (SSL). L'ispezione FQDN/URL/TLS non è supportata. Configurare il passaggio di UDP 80/443 come regole di rete.
Certificati firmati da clienti non attendibili I certificati firmati dal cliente non sono considerati attendibili dal firewall una volta ricevuti da un server Web basato su Intranet. È in corso la ricerca di una correzione.
Indirizzo IP di origine errato negli avvisi con IDPS per HTTP (senza ispezione TLS). Quando è in uso il traffico HTTP in testo normale e IDPS genera un nuovo avviso e la destinazione è un indirizzo IP pubblico, l'indirizzo IP di origine visualizzato è errato (viene visualizzato l'indirizzo IP interno anziché dell'indirizzo IP originale). È in corso la ricerca di una correzione.
Propagazione certificati Dopo l'applicazione di un certificato della CA al firewall, potrebbero essere necessari dai 5 ai 10 minuti per rendere effettivo il certificato. È in corso la ricerca di una correzione.
Supporto di TLS 1.3 TLS 1.3 è parzialmente supportato. Il tunnel TLS dal client al firewall si basa su TLS 1.2, mentre dal firewall al server Web esterno si basa su TLS 1.3. Gli aggiornamenti sono in corso di verifica.
Scadenza del certificato della CA intermedia TLSi In alcuni casi particolari, il certificato della CA intermedia può scadere due mesi prima della data di scadenza originale. Rinnovare il certificato della CA intermedia due mesi prima della data di scadenza originale. È in corso la ricerca di una correzione.

Passaggi successivi