Firewall di Azure problemi noti e limitazioni

  • Articolo

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

Per Firewall di Azure limitazioni, vedere Sottoscrizione di Azure e limiti, quote e vincoli del servizio.

Firewall di Azure Standard

Firewall di Azure Standard presenta i problemi noti seguenti:

Nota

Qualsiasi problema applicabile a Standard si applica anche a Premium.

Problema Descrizione Mitigazione
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 dell'intelligence per le minacce possono 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).
La modalità DNAT del Firewall di Azure non funziona per le destinazioni IP private Il supporto di DNAT del Firewall di Azure è limitato al traffico Internet in uscita/in ingresso. La modalità DNAT attualmente non funziona per le destinazioni IP private, ad esempio da spoke a spoke. È in corso la ricerca di una correzione.

DNAT privato è attualmente in anteprima privata. Guardare l'articolo Firewall di Azure funzionalità di anteprima per l'annuncio dell'anteprima pubblica.
Con hub virtuali protetti, le zone di disponibilità possono essere configurate solo durante la distribuzione. Non è possibile configurare 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 specificare tali porte 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 ai domini esterni (ad esempio outlook.com e gmail.com) sulla porta TCP 25 possono essere bloccati dalla piattaforma Azure. Si tratta del 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 consiste nel distribuire Firewall di Azure in una sottoscrizione di Contratto Enterprise (EA) standard. Firewall di Azure in una sottoscrizione EA può comunicare con indirizzi IP pubblici usando la porta TCP in uscita 25. Attualmente, può funzionare anche in altri tipi di sottoscrizione, ma non è garantito il funzionamento. Per indirizzi IP privati come reti virtuali, 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 2496 porte per ogni 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 disponibili 4992 porte per flusso (IP di destinazione, porta di destinazione e protocollo TCP o UDP). Il firewall aumenta fino a un massimo di 20 istanze. Si tratta di una limitazione della piattaforma. È possibile aggirare i limiti configurando Firewall di Azure distribuzioni con almeno cinque indirizzi IP pubblici per le distribuzioni soggette all'esaurimento SNAT. In questo modo si aumentano le porte SNAT disponibili 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 Azure Rete virtuale NAT.
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.
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. Potrebbe verificarsi un errore FTP quando i canali di controllo e dei dati 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.
FTP passivo in entrata 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 sono SNATed a uno degli indirizzi IP privati del firewall per garantire il routing simmetrico. Potrebbe verificarsi un errore FTP quando i canali di controllo e dei dati 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.
FTP attivo non funziona quando il client FTP deve raggiungere un server FTP attraverso Internet. FTP attivo utilizza un comando PORT dal client FTP che indirizza il server FTP quale IP e porta usare per il canale dati. Questo comando PORT usa l'indirizzo IP privato del client che non può essere modificato. Il traffico sul lato client che attraversa il Firewall di Azure è NATed per le comunicazioni basate su Internet, rendendo il comando PORT considerato non valido dal server FTP. Si tratta di una limitazione generale di FTP attivo 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 possono 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 browser o il software server non supporta l'estensione SNI (Server Name Indicator), 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 dei criteri firewall usando il portale o i modelli di Azure Resource Manager (ARM) Firewall di Azure Policy presenta una limitazione del supporto delle patch che impedisce di aggiungere un tag usando i modelli portale di Azure o ARM. Viene generato l'errore seguente: Non è stato 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 e viene visualizzato 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. Si tratta di un problema o di una limitazione nota.

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

Per evitare l'errore, i gruppi IP collegati allo stesso firewall devono essere aggiornati uno alla volta. Consentire un tempo sufficiente tra gli aggiornamenti per consentire al firewall di uscire dallo stato di aggiornamento .
La rimozione di RuleCollectionGroups con i modelli di Resource Manager non è supportata. La rimozione di un RuleCollectionGroup con i modelli di Resource Manager non è supportata e genera un errore. Non si tratta di un'operazione supportata.
La regola DNAT per consentire qualsiasi (*) consentirà il traffico SNAT. Se una regola DNAT consente qualsiasi (*) come indirizzo IP di origine, una regola di rete implicita corrisponde al traffico VNet-VNet e sNATrà sempre il 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 una route asincrona per il traffico DNAT restituito, che passa al provider di sicurezza. Non supportato.
Errore durante la creazione di più di 2000 raccolte regole. Il numero massimo di raccolte di regole NAT/applicazione o di 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 originale, come illustrato dal firewall. Questo è applicabile per i casi d'uso seguenti:
- Richieste HTTP
- Richieste HTTPS con terminazione TLS		 È in corso la ricerca di una correzione.
Non è possibile eseguire l'aggiornamento a Premium con zone di disponibilità nell'area Asia sud-orientale Non è attualmente possibile eseguire l'aggiornamento a Firewall di Azure Premium con zone di disponibilità nell'area Asia sud-orientale. Distribuire un nuovo firewall Premium in Asia sud-orientale senza zone di disponibilità o distribuirsi in un'area che supporta zone di disponibilità.
Non è possibile distribuire il firewall con 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 prima di tutto un nuovo indirizzo IP pubblico con ridondanza della zona, quindi assegnare questo indirizzo IP creato in precedenza durante la distribuzione del firewall.
La zona DNS privato di Azure non è supportata con Firewall di Azure La zona DNS privato di Azure non funziona con Firewall di Azure indipendentemente dalle impostazioni DNS Firewall di Azure. Per ottenere lo stato desiderato dell'uso di un server DNS privato, usare Firewall di Azure proxy DNS anziché una zona DNS privata di Azure.
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 che viene distribuito nella zona fisica 2, non può essere riavviato. Per altre informazioni, vedere Zone di disponibilità fisiche e logiche. Per i nuovi firewall, eseguire la distribuzione con le zone di disponibilità rimanenti 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 Mitigazione
Supporto ESNI per la risoluzione FQDN in HTTPS L'autenticazione SNI crittografata non è supportata nell'handshake HTTPS. Attualmente solo Firefox supporta ESNI tramite la configurazione personalizzata. Soluzione alternativa suggerita consiste nel disabilitare questa funzionalità.
L'autenticazione della certificazione client non è supportata I certificati client vengono usati per creare un trust di identità reciproca 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. Si tratta di un protocollo basato su UDP su 80 (PLAN) e 443 (SSL). L'ispezione FQDN/URL/TLS non sarà supportata. Configurare il passaggio di UDP 80/443 come regole di rete.
Certificati firmati dal cliente 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 il traffico HTTP in testo normale è in uso e IDPS genera un nuovo avviso e la destinazione è un indirizzo IP pubblico, l'indirizzo IP di origine visualizzato è errato (l'indirizzo IP interno viene visualizzato anziché l'indirizzo IP originale). È in corso la ricerca di una correzione.
Propagazione certificati Dopo l'applicazione di un certificato della CA nel firewall, potrebbero essere necessari tra 5 e 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 e dal firewall al server Web esterno si basa su TLS 1.3. Aggiornamenti sono in corso indagini.
Scadenza del certificato CA intermedio TLSi In alcuni casi univoci, il certificato ca intermedio può scadere due mesi prima della data di scadenza originale. Rinnovare il certificato CA intermedio due mesi prima della data di scadenza originale. È in corso la ricerca di una correzione.

Passaggi successivi