Dela via

Kända problem och begränsningar i Azure Firewall

  • Artikel

I den här artikeln visas kända problem för Azure Firewall. Det uppdateras när problem löses.

Azure Firewall-begränsningar finns i Azure-prenumerations- och tjänstgränser, kvoter och begränsningar.

Azure Firewall Standard

Azure Firewall Standard har följande kända problem:

Kommentar

Alla problem som gäller för Standard gäller även för Premium.

Problem beskrivning Åtgärd
DNAT-stöd för privata IP-adresser som är begränsade till Standard- och Premium-versioner Stöd för DNAT på en privat IP-adress i Azure Firewall är avsett för företag, så det är begränsat till standard- och Premium Firewall-versionerna. Ingen
Nätverksfiltreringsregler för icke-TCP-/UDP-protokoll (till exempel ICMP) fungerar inte för Internetbunden trafik Regler för nätverksfiltrering för icke-TCP/UDP-protokoll fungerar inte med SNAT till din offentliga IP-adress. Icke-TCP-/UDP-protokoll stöds mellan ekerundernät och virtuella nätverk. Azure Firewall använder Standard Load Balancer, som för närvarande inte stöder SNAT för IP-protokoll. Vi undersöker alternativ för att stödja det här scenariot i en framtida version.
Saknat PowerShell- och CLI-stöd för ICMP Azure PowerShell och CLI stöder inte ICMP som ett giltigt protokoll i nätverksregler. Det går fortfarande att använda ICMP som ett protokoll via portalen och REST-API:et. Vi arbetar med att lägga till ICMP i PowerShell och CLI snart.
FQDN-taggar kräver att protokoll: port anges Programregler med FQDN-taggar kräver port: protokolldefinition. Du kan använda https som port: protokoll-värde. Vi arbetar med att göra det här fältet valfritt när FQDN-taggar används.
Det går inte att flytta en brandvägg till en annan resursgrupp eller prenumeration Det går inte att flytta en brandvägg till en annan resursgrupp eller prenumeration. Stöd för den här funktionen finns i vår planering. För att kunna flytta en brandvägg till en annan resursgrupp eller prenumeration måste du ta bort den aktuella instansen och återskapa den i den nya resursgruppen eller prenumerationen.
Hotinformationsaviseringar kan maskeras Nätverksregler med mål 80/443 för utgående filtrering maskerar hotinformationsaviseringar när de är konfigurerade för aviseringsläge. Skapa utgående filtrering för 80/443 med hjälp av programregler. Eller ändra hotinformationsläget till Avisering och Neka.
Med skyddade virtuella hubbar kan tillgänglighetszoner endast konfigureras under distributionen. Du kan inte konfigurera Tillgänglighetszoner när en brandvägg med skyddade virtuella hubbar har distribuerats. Det här är avsiktligt.
SNAT för inkommande anslutningar Förutom DNAT är anslutningar via brandväggens offentliga IP-adress (inkommande) SNATed till en av brandväggens privata IP-adresser. Det här kravet i dag (även för aktiva/aktiva NVA:er) för att säkerställa symmetrisk routning. Överväg att använda XFF-huvuden för att bevara den ursprungliga källan för HTTP/S. Du kan till exempel använda en tjänst som Azure Front Door eller Azure Application Gateway framför brandväggen. Du kan också lägga till WAF som en del av Azure Front Door och kedja i brandväggen.
SQL FQDN-filtreringsstöd endast i proxyläge (port 1433) För Azure SQL Database, Azure Synapse Analytics och Azure SQL Managed Instance:

SQL FQDN-filtrering stöds endast i proxyläge (port 1433).

För Azure SQL IaaS:

Om du använder portar som inte är standard kan du ange dessa portar i programreglerna.		 För SQL i omdirigeringsläge (standard om du ansluter inifrån Azure) kan du i stället filtrera åtkomst med hjälp av SQL-tjänsttaggen som en del av Azure Firewall-nätverksregler.
Utgående SMTP-trafik på TCP-port 25 blockeras Utgående e-postmeddelanden som skickas direkt till externa domäner (som outlook.com och gmail.com) på TCP-port 25 blockeras av Azure-plattformen. Det här är standardbeteendet för plattformen i Azure. Azure Firewall introducerar inte någon mer specifik begränsning. Använd autentiserade SMTP-relätjänster, som vanligtvis ansluter via TCP-port 587, men som också stöder andra portar. Mer information finns i Felsöka problem med utgående SMTP-anslutning i Azure.

Ett annat alternativ är att distribuera Azure Firewall i en EA-standardprenumeration (företagsavtal). Azure Firewall i en EA-prenumeration kan kommunicera med offentliga IP-adresser med hjälp av utgående TCP-port 25. För närvarande kan det också fungera i andra prenumerationstyper, men det är inte garanterat att det fungerar. För privata IP-adresser som virtuella nätverk, VPN och Azure ExpressRoute stöder Azure Firewall en utgående anslutning på TCP-port 25.
SNAT-portöverbelastning Azure Firewall stöder för närvarande 2 496 portar per offentlig IP-adress per vm-skalningsuppsättningsinstans för serverdelen. Som standard finns det två vm-skalningsuppsättningsinstanser. Det finns alltså 4 992 portar per flöde (mål-IP, målport och protokoll (TCP eller UDP). Brandväggen skalar upp till högst 20 instanser. Det här är en plattformsbegränsning. Du kan kringgå gränserna genom att konfigurera Azure Firewall-distributioner med minst fem offentliga IP-adresser för distributioner som är känsliga för SNAT-överbelastning. Detta ökar SNAT-portarna som är tillgängliga med fem gånger. Allokera från ett IP-adressprefix för att förenkla underordnade behörigheter. För en mer permanent lösning kan du distribuera en NAT-gateway för att övervinna SNAT-portgränserna. Den här metoden stöds för distributioner av virtuella nätverk.

Mer information finns i Skala SNAT-portar med Azure Virtual Network NAT.
DNAT stöds inte med tvingad tunneltrafik aktiverat Brandväggar som distribueras med tvingad tunneltrafik aktiverat kan inte stödja inkommande åtkomst från Internet på grund av asymmetrisk routning. Detta är avsiktligt på grund av asymmetrisk routning. Retursökvägen för inkommande anslutningar går via den lokala brandväggen, som inte har sett anslutningen upprättad.
Utgående passiv FTP kanske inte fungerar för brandväggar med flera offentliga IP-adresser, beroende på ftp-serverkonfigurationen. Passiv FTP upprättar olika anslutningar för kontroll- och datakanaler. När en brandvägg med flera offentliga IP-adresser skickar utgående data väljer den slumpmässigt en av sina offentliga IP-adresser för källans IP-adress. FTP kan misslyckas när data- och kontrollkanaler använder olika käll-IP-adresser, beroende på din FTP-serverkonfiguration. En explicit SNAT-konfiguration planeras. Under tiden kan du konfigurera FTP-servern så att den accepterar data och styr kanaler från olika käll-IP-adresser (se ett exempel för IIS). Du kan också överväga att använda en enda IP-adress i den här situationen.
Inkommande passiv FTP kanske inte fungerar beroende på ftp-serverkonfigurationen Passiv FTP upprättar olika anslutningar för kontroll- och datakanaler. Inkommande anslutningar i Azure Firewall är SNATed till en av brandväggens privata IP-adresser för att säkerställa symmetrisk routning. FTP kan misslyckas när data- och kontrollkanaler använder olika käll-IP-adresser, beroende på din FTP-serverkonfiguration. Bevarandet av den ursprungliga käll-IP-adressen håller på att undersökas. Under tiden kan du konfigurera FTP-servern så att den accepterar data och styr kanaler från olika käll-IP-adresser.
Aktiv FTP fungerar inte när FTP-klienten måste nå en FTP-server över internet. Aktiv FTP använder ett PORT-kommando från FTP-klienten som dirigerar FTP-servern till vilken IP-adress och port som ska användas för datakanalen. Det här PORT-kommandot använder den privata IP-adressen för klienten som inte kan ändras. Trafik på klientsidan som passerar Azure Firewall är NATed för Internetbaserad kommunikation, vilket gör att PORT-kommandot ses som ogiltigt av FTP-servern. Detta är en allmän begränsning för Aktiv FTP när det används med NAT på klientsidan.
NetworkRuleHit-mått saknar en protokolldimension Måttet ApplicationRuleHit tillåter filtreringsbaserat protokoll, men den här funktionen saknas i motsvarande NetworkRuleHit-mått. En korrigering håller på att undersökas.
NAT-regler med portar mellan 64000 och 65535 stöds inte Azure Firewall tillåter alla portar i intervallet 1–65535 i nätverk och programregler, men NAT-regler stöder endast portar i intervallet 1–63999. Detta är en aktuell begränsning.
Konfigurationsuppdateringar kan ta fem minuter i genomsnitt En konfigurationsuppdatering för Azure Firewall kan ta tre till fem minuter i genomsnitt och parallella uppdateringar stöds inte. En korrigering håller på att undersökas.
Azure Firewall använder SNI TLS-huvuden för att filtrera HTTPS- och MSSQL-trafik Om webbläsar- eller serverprogramvaran inte stöder SNI-tillägget (Server Name Indicator) kan du inte ansluta via Azure Firewall. Om webbläsar- eller serverprogramvaran inte stöder SNI kanske du kan styra anslutningen med hjälp av en nätverksregel i stället för en programregel. Se Servernamnsindikator för programvara som stöder SNI.
Det går inte att lägga till brandväggsprinciptaggar med hjälp av portalen eller ARM-mallar (Azure Resource Manager) Azure Firewall Policy har en korrigeringsstödbegränsning som hindrar dig från att lägga till en tagg med hjälp av Azure Portal- eller ARM-mallarna. Följande fel genereras: Det gick inte att spara taggarna för resursen. En korrigering håller på att undersökas. Du kan också använda Azure PowerShell-cmdleten Set-AzFirewallPolicy för att uppdatera taggar.
IPv6 stöds inte för närvarande Om du lägger till en IPv6-adress i en regel misslyckas brandväggen. Använd endast IPv4-adresser. IPv6-stöd är under utredning.
Det går inte att uppdatera flera IP-grupper med konfliktfel. När du uppdaterar två eller flera IP-grupper som är anslutna till samma brandvägg hamnar en av resurserna i ett feltillstånd. Det här är ett känt problem/en begränsning.

När du uppdaterar en IP-grupp utlöses en uppdatering av alla brandväggar som IPGroup är ansluten till. Om en uppdatering av en andra IP-grupp startas medan brandväggen fortfarande är i uppdateringstillståndet misslyckas IPGroup-uppdateringen.

För att undvika felet måste IP-grupper som är anslutna till samma brandvägg uppdateras en i taget. Tillåt tillräckligt med tid mellan uppdateringar för att brandväggen ska komma ur uppdateringstillståndet.
Det går inte att ta bort RuleCollectionGroups med ARM-mallar. Det går inte att ta bort en RuleCollectionGroup med ARM-mallar och det resulterar i fel. Det här är inte en åtgärd som stöds.
DNAT-regel för att tillåta all (*) kommer att SNAT-trafik. Om en DNAT-regel tillåter någon (*) som käll-IP-adress matchar en implicit nätverksregel VNet-VNet-trafik och kommer alltid att SNAT trafiken. Detta är en aktuell begränsning.
Det går inte att lägga till en DNAT-regel i en säker virtuell hubb med en säkerhetsprovider. Detta resulterar i en asynkron väg för den returnerade DNAT-trafiken, som går till säkerhetsprovidern. Stöds ej.
Ett fel uppstod när fler än 2 000 regelsamlingar skapades. Det maximala antalet NAT-/program- eller nätverksregelsamlingar är 2 000 (Resource Manager-gräns). Detta är en aktuell begränsning.
XFF-huvud i HTTP/S XFF-huvuden skrivs över med den ursprungliga käll-IP-adressen enligt brandväggen. Detta gäller för följande användningsfall:
– HTTP-begäranden
– HTTPS-begäranden med TLS-avslutning		 En korrigering håller på att undersökas.
Det går inte att distribuera brandväggen med Tillgänglighetszoner med en nyligen skapad offentlig IP-adress När du distribuerar en brandvägg med Tillgänglighetszoner kan du inte använda en nyligen skapad offentlig IP-adress. Skapa först en ny zonredundant offentlig IP-adress och tilldela sedan den tidigare skapade IP-adressen under brandväggsdistributionen.
Fysisk zon 2 i Japan, östra är inte tillgänglig för brandväggsdistributioner. Du kan inte distribuera en ny brandvägg med fysisk zon 2. Om du stoppar en befintlig brandvägg som distribueras i fysisk zon 2 kan den inte startas om. Mer information finns i Fysiska och logiska tillgänglighetszoner. För nya brandväggar distribuerar du med de återstående tillgänglighetszonerna eller använder en annan region. Information om hur du konfigurerar en befintlig brandvägg finns i Hur konfigurerar jag tillgänglighetszoner efter distributionen?.

Azure Firewall Premium

Azure Firewall Premium har följande kända problem:

Problem beskrivning Åtgärd
ESNI-stöd för FQDN-upplösning i HTTPS Krypterad SNI stöds inte i HTTPS-handskakning. Idag stöder endast Firefox ESNI via anpassad konfiguration. Den föreslagna lösningen är att inaktivera den här funktionen.
Klientcertifieringsautentisering stöds inte Klientcertifikat används för att skapa ett ömsesidigt identitetsförtroende mellan klienten och servern. Klientcertifikat används under en TLS-förhandling. Azure-brandväggen omförhandlar en anslutning till servern och har ingen åtkomst till klientcertifikatens privata nyckel. Ingen
QUIC/HTTP3 QUIC är den nya huvudversionen av HTTP. Det är ett UDP-baserat protokoll över 80 (PLAN) och 443 (SSL). FQDN/URL/TLS-inspektion stöds inte. Konfigurera att skicka UDP 80/443 som nätverksregler.
Ej betrodda kundsignerade certifikat Kundsignerade certifikat är inte betrodda av brandväggen när de har tagits emot från en intranätbaserad webbserver. En korrigering håller på att undersökas.
Fel käll-IP-adress i aviseringar med IDPS för HTTP (utan TLS-inspektion). När HTTP-trafik i klartext används och IDPS utfärdar en ny avisering, och målet är en offentlig IP-adress, är den visade käll-IP-adressen fel (den interna IP-adressen visas i stället för den ursprungliga IP-adressen). En korrigering håller på att undersökas.
Spridning av certifikat När ett CA-certifikat har tillämpats på brandväggen kan det ta mellan 5 och 10 minuter innan certifikatet börjar gälla. En korrigering håller på att undersökas.
TLS 1.3-stöd TLS 1.3 stöds delvis. TLS-tunneln från klienten till brandväggen baseras på TLS 1.2 och från brandväggen till den externa webbservern baseras på TLS 1.3. Uppdateringar undersöks.
TLSi mellanliggande CA-certifikat upphör att gälla I vissa unika fall kan det mellanliggande CA-certifikatet upphöra att gälla två månader före det ursprungliga förfallodatumet. Förnya det mellanliggande CA-certifikatet två månader före det ursprungliga förfallodatumet. En korrigering håller på att undersökas.

Nästa steg