Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
Dit artikel helpt u inzicht te hebben in de huidige bekende problemen en beperkingen in Azure Firewall. We werken deze informatie bij naarmate er problemen zijn opgelost, dus kom regelmatig terug voor de meest recente status.
Voordat u Azure Firewall implementeert of bestaande implementaties oplost, bekijkt u deze bekende problemen om veelvoorkomende problemen te voorkomen en passende tijdelijke oplossingen te plannen.
Zie Azure-abonnements- en servicelimieten, quota en beperkingen voor Azure Firewall-services.
Huidige capaciteitsbeperkingen
De volgende zones ondervinden momenteel capaciteitsbeperkingen:
| Regio/zone | Artikelnummer (SKU) | Beperkingen | Aanbeveling |
|---|---|---|---|
| Fysieke zone 1 en zone 4 in Oost-VS 2 EUAP | Basic, Standard en Premium | - U kunt geen nieuwe Azure Firewall implementeren in zone 1 en zone 4. | U wordt aangeraden een nieuwe Azure Firewall te implementeren in de resterende beschikbaarheidszones of een andere regio te gebruiken. Als u een bestaande firewall wilt configureren, raadpleegt u Hoe kan ik beschikbaarheidszones configureren na de implementatie? |
| - Fysieke zone 2 in | Standard en Premium | - U kunt geen nieuwe Azure Firewall implementeren in zone 3 in Zuidoost-Azië of zone 2 in Europa - noord.
- Als u een bestaande Azure Firewall stopt die in deze zone is geïmplementeerd, kan deze niet opnieuw worden gestart. Zie fysieke en logische beschikbaarheidszones voor meer informatie. |
U wordt aangeraden een nieuwe Azure Firewall te implementeren in de resterende beschikbaarheidszones of een andere regio te gebruiken. Als u een bestaande firewall wilt configureren, raadpleegt u Hoe kan ik beschikbaarheidszones configureren na de implementatie? |
| Fysieke zone 3 in VS - zuid-centraal | Basic, Standard en Premium | - U kunt geen nieuwe Azure Firewall implementeren in zone 3.
Geschatte datum beschikbaar: 31 maart 2026 |
U wordt aangeraden een nieuwe Azure Firewall te implementeren in de resterende beschikbaarheidszones of een andere regio te gebruiken. Als u een bestaande firewall wilt configureren, raadpleegt u Hoe kan ik beschikbaarheidszones configureren na de implementatie? |
| Fysieke zone 2 in Spanje - centraal | Basic, Standard en Premium | - U kunt geen nieuwe Azure Firewall implementeren in zone 2.
Geschatte datum beschikbaar: 31 december 2026 |
U wordt aangeraden een nieuwe Azure Firewall te implementeren in de resterende beschikbaarheidszones of een andere regio te gebruiken. Als u een bestaande firewall wilt configureren, raadpleegt u Hoe kan ik beschikbaarheidszones configureren na de implementatie? |
| US Gov Virginia | Premium | - Er is geen capaciteit voor Azure Firewall Premium SKU in US Gov Virginia, zowel zonegebonden als niet-zonegebonden implementaties worden geblokkeerd. | Azure Firewall Standard SKU implementeren of Premium SKU implementeren in een andere regio. |
| Fysieke zone 3 in US Gov Virginia | Basic en Standard | - Zonegebonden implementaties worden geblokkeerd in fysieke zone 3 in US Gov Virginia.
- U moet handmatig beschikbare zones selecteren voor een geslaagde implementatie en een suboptimale implementatie-ervaring maken. |
Selecteer zones 1 en 2 voor zonegebonden implementaties of gebruik een andere regio. |
| Fysieke zone 2 in West-US 2 | Basic, Standard en Premium | - U kunt geen nieuwe Azure Firewall implementeren in zone 2. | U wordt aangeraden een nieuwe Azure Firewall te implementeren in de resterende beschikbaarheidszones of een andere regio te gebruiken. Als u een bestaande firewall wilt configureren, raadpleegt u Hoe kan ik beschikbaarheidszones configureren na de implementatie? |
Waarschuwing
Als u een bestaande Azure Firewall-implementatie stopt in een van deze regio's met beperkte capaciteit, kunt u deze mogelijk niet opnieuw starten vanwege doorlopende capaciteitsbeperkingen. Plan hierop vooruit voordat u firewallinstanties in deze regio's stopt.
Bekende problemen met Azure Firewall Standard
Azure Firewall Standard heeft de volgende bekende problemen:
| Probleem | Beschrijving | Mitigatie |
|---|---|---|
| DNAT-ondersteuning voor privé-IP-adressen beperkt tot Standard- en Premium-versies | Ondersteuning voor DNAT in privé-IP-adres van Azure Firewall is alleen beschikbaar in de Standard- en Premium Firewall-versies, niet in de Basic-versie. | Geen |
| Azure Firewall-deallocatie en toewijzingsproces worden niet ondersteund wanneer privé-IP DNAT-regels zijn geconfigureerd | Het toewijzingsproces van Azure Firewall mislukt wanneer persoonlijke DNAT-regels zijn geconfigureerd | 1. De Azure Firewall vrijgeven 2. Verwijder alle persoonlijke IP DNAT-regels 3. Wijs de Azure Firewall toe en wacht totdat het privé-IP-adres is gevuld 4. De privé-IP DNAT-regels opnieuw configureren met het juiste privé-IP-adres |
| Netwerkfilterregels voor niet-TCP/UDP-protocollen (bijvoorbeeld ICMP) werken niet voor internetverkeer | Netwerkfilterregels voor niet-TCP/UDP-protocollen werken niet met SNAT naar uw openbare IP-adres. Niet-TCP/UDP-protocollen worden ondersteund tussen spoke-subnetten en VNets. | Azure Firewall maakt gebruik van de standaardversie van Standard Load Balancer, die momenteel geen ondersteuning biedt voor SNAT voor IP-protocollen. We verkennen opties voor ondersteuning van niet-TCP/UDP-protocollen voor internetverkeer in een toekomstige release. |
| Wanneer de toewijzing van een Azure Firewall ongedaan wordt gemaakt en vervolgens opnieuw wordt toegewezen, wordt mogelijk een nieuw privé-IP-adres toegewezen | Na het deallocatie- en toewijzingsproces van de Azure Firewall wordt dynamisch een privé-IP-adres toegewezen vanuit het Azure Firewall-subnet. Wanneer een nieuw privé-IP-adres wordt toegewezen dat verschilt van de vorige, veroorzaakt dit routeringsproblemen. | U moet de bestaande door de gebruiker gedefinieerde routes (UDR's) opnieuw configureren met het nieuwe privé-IP-adres. Er wordt een oplossing onderzocht om het privé-IP-adres na het toewijzingsproces te behouden. |
| Onderliggend firewallbeleid neemt geen DNS-instellingen over van bovenliggend beleid. | Wanneer u DNS-instellingen wijzigt in een hoofdbeleid voor de firewall, kunnen onderliggende beleidspolicies die eraan verbonden zijn, mogelijk niet domeinnamen oplossen in hun regels. | Stel DNS-instellingen rechtstreeks in op elk kindbeleid in plaats van te vertrouwen op het ouderbeleid. Er wordt gewerkt aan een oplossing om overname van DNS-instellingen toe te staan. |
| Ontbrekende PowerShell- en CLI-ondersteuning voor ICMP | Azure PowerShell en CLI bieden geen ondersteuning voor ICMP als een geldig protocol in netwerkregels. | Het is nog steeds mogelijk om ICMP als een protocol te gebruiken via de portal en de REST-API. Er wordt aan gewerkt om ICMP binnenkort toe te voegen in PowerShell en CLI. |
| FQDN-tags vereisen instelling van een protocol: poort | Voor toepassingsregels met FQDN-tags is definitie van poort: protocol vereist. | U kunt https gebruiken als de waarde voor poort:protocol. We werken eraan om de poort: protocolveld optioneel te maken wanneer FQDN-tags worden gebruikt. |
| Het verplaatsen van een firewall naar een andere resourcegroep of een ander abonnement wordt niet ondersteund | Het verplaatsen van een firewall naar een andere resourcegroep of een ander abonnement wordt niet ondersteund. | Het ondersteunen van deze functionaliteit staat op onze roadmap. Om een firewall naar een andere resourcegroep of ander abonnement verplaatsen, moet u het huidige exemplaar verwijderen en deze vervolgens opnieuw maken in de nieuwe resourcegroep of het nieuwe abonnement. |
| Waarschuwingen voor dreigingsinformatie kunnen gemaskeerd worden | Netwerkregels met bestemming 80/443 voor uitgaande filtering maskeren bedreigingsinformatiewaarschuwingen wanneer deze zijn geconfigureerd voor de modus alleen-waarschuwingen. | Maak uitgaande filters voor 80/443 met behulp van toepassingsregels. U kunt ook de modus voor bedreigingsinformatie wijzigen in Waarschuwen en weigeren. |
| Met beveiligde virtuele hubs kunnen beschikbaarheidszones alleen worden geconfigureerd tijdens de implementatie. | U kunt Beschikbaarheidszones niet configureren nadat een firewall met beveiligde virtuele hubs is geïmplementeerd. | Met opzet. |
| SNAT op inkomende verbindingen | Inkomende DNAT-regels wijzigen altijd het bron-IP-adres voor retourverkeer. | Als u het oorspronkelijke IP-adres van de client voor webverkeer wilt bijhouden, configureert u uw clients of proxyservers om het oorspronkelijke IP-adres in XFF-headers op te nemen. Azure Firewall behoudt deze IP-adressen in de XFF-header en voegt het FIREWALL-IP-adres toe aan de XFF-header bij het verwerken van regels voor webverkeer. |
| Ondersteuning voor SQL FQDN-filtering alleen in proxymodus (poort 1433) | Voor Azure SQL Database, Azure Synapse Analytics en Azure SQL Managed Instance: Filteren met SQL FQDN wordt alleen ondersteund in de proxymodus (poort 1433). Voor Azure SQL IaaS: Als u niet-standaardpoorten gebruikt, kunt u deze poorten opgeven in de toepassingsregels. |
Voor SQL in de omleidingsmodus (de standaardinstelling als u verbinding maakt vanuit Azure), kunt u in plaats daarvan de toegang filteren met behulp van de SQL-servicetag als onderdeel van Azure Firewall-netwerkregels. |
| Uitgaand SMTP-verkeer op TCP-poort 25 wordt geblokkeerd | Het Azure-platform blokkeert uitgaande e-mailberichten die rechtstreeks worden verzonden naar externe domeinen (zoals outlook.com en gmail.com) op TCP-poort 25. Uitgaand SMTP-verkeer blokkeren op poort 25 is het standaardplatformgedrag in Azure. Azure Firewall introduceert geen specifiekere beperking. |
Gebruik geverifieerde SMTP-relayservices, die doorgaans verbinding maken via TCP-poort 587, maar ook andere poorten ondersteunt. Zie Problemen met uitgaande SMTP-connectiviteit in Azure oplossen voor meer informatie. Een andere optie is het implementeren van Azure Firewall binnen een standaard Enterprise Agreement-abonnement. Azure Firewall in een EA-abonnement kan communiceren met openbare IP-adressen met behulp van uitgaande TCP-poort 25. Het kan werken in andere abonnementstypen, maar niet gegarandeerd. Voor privé-IP-adressen zoals virtuele netwerken, VPN's en Azure ExpressRoute ondersteunt Azure Firewall een uitgaande verbinding op TCP-poort 25. |
| uitputting van SNAT-poorten | Azure Firewall ondersteunt momenteel 2.496 poorten per openbaar IP-adres per instantie van de back-end virtuele machinesschaalset. Standaard zijn er twee instanties van Virtual Machine Scales Set. Er zijn dus 4992 poorten per stroom (doel-IP, doelpoort en protocol (TCP of UDP). De firewall kan opschalen tot maximaal 20 instellingen. | SNAT-poortuitputting is een platformbeperking. U kunt de limieten omzeilen door Azure Firewall-implementaties te configureren met minimaal vijf openbare IP-adressen voor implementaties die vatbaar zijn voor SNAT-uitputting. Door meer openbare IP-adressen toe te voegen, worden de SNAT-poorten vijf keer verhoogd. Wijs een IP-adresvoorvoegsel toe om toekomstige machtigingen te vereenvoudigen. Voor een permanentere oplossing kunt u een NAT-gateway implementeren om de SNAT-poortlimieten te overwinnen. NAT-gatewayimplementatie wordt ondersteund voor implementaties van virtuele netwerken. Zie SNAT-poorten schalen met Azure Virtual Network NAT voor meer informatie. |
| DNAT wordt niet ondersteund als geforceerde tunneling is ingeschakeld | Firewalls die zijn geïmplementeerd met geforceerde tunneling, bieden geen ondersteuning voor inkomende toegang via internet vanwege asymmetrische routering. | Het gebrek aan DNAT-ondersteuning met geforceerde tunneling is ontworpen vanwege asymmetrische routering. Het retourpad voor binnenkomende verbindingen gaat via de on-premises firewall, waardoor de verbinding niet tot stand is gebracht. |
| Uitgaande passieve FTP werkt mogelijk niet voor firewalls met meerdere openbare IP-adressen, afhankelijk van de configuratie van uw FTP-server. | Passieve FTP brengt verschillende verbindingen tot stand voor controle- en gegevenskanalen. Wanneer een firewall met meerdere openbare IP-adressen gegevens uitgaand verzendt, wordt willekeurig een van de openbare IP-adressen geselecteerd voor het bron-IP-adres. FTP kan mislukken wanneer gegevens en besturingskanalen verschillende bron-IP-adressen gebruiken, afhankelijk van de configuratie van uw FTP-server. | Er wordt een expliciete SNAT-configuratie gepland. In de tussentijd kunt u uw FTP-server zo configureren dat gegevens- en besturingskanalen van verschillende bron-IP-adressen worden geaccepteerd (bekijk een voorbeeld voor IIS). U kunt ook één IP-adres gebruiken bij het ondervinden van problemen met FTP-connectiviteit. |
| Inkomende passieve FTP werkt mogelijk niet, afhankelijk van de configuratie van uw FTP-server | Passieve FTP brengt verschillende verbindingen tot stand voor controle- en gegevenskanalen. Binnenkomende verbindingen op Azure Firewall worden gesnaten naar een van de privé-IP-adressen van de firewall zodat symmetrische routering is gegarandeerd. FTP kan mislukken wanneer gegevens en besturingskanalen verschillende bron-IP-adressen gebruiken, afhankelijk van de configuratie van uw FTP-server. | Behoud van het oorspronkelijke bron-IP-adres wordt onderzocht. In de tussentijd kunt u uw FTP-server zo configureren dat gegevens- en besturingskanalen van verschillende bron-IP-adressen worden geaccepteerd. |
| Actieve FTP werkt niet wanneer de FTP-client een FTP-server via internet moet bereiken. | Actieve FTP maakt gebruik van een POORT-opdracht van de FTP-client die de FTP-server stuurt welk IP-adres en welke poort moet worden gebruikt voor het gegevenskanaal. De OPDRACHT PORT maakt gebruik van het privé-IP-adres van de client die niet kan worden gewijzigd. Verkeer aan de clientzijde dat door de Azure Firewall gaat, heeft NAT toegepast voor communicatie via internet, waardoor de PORT-opdracht door de FTP-server als ongeldig wordt beschouwd. | Actieve FTP-fout is een algemene beperking van Active FTP wanneer deze wordt gebruikt met NAT aan de clientzijde. |
| Er ontbreekt een protocoldimensie in de metrische gegevens voor NetworkRuleHit | Met de metrische waarde ApplicationRuleHit kunt u filteren op basis van een protocol, maar deze mogelijkheid ontbreekt in de bijbehorende metrische gegevens voor NetworkRuleHit. | Er wordt een oplossing onderzocht. |
| NAT-regels met poorten tussen 64000 en 65535 worden niet ondersteund | Azure Firewall staat elke poort toe in het bereik 1-65535 toe in netwerk- en toepassingsregels, maar NAT-regels ondersteunen alleen poorten in het bereik van 1-63999. | De beperking voor NAT-regelpoorten is een huidige beperking. |
| Configuratie-updates kunnen gemiddeld vijf minuten duren | Een Azure Firewall-configuratie-update kan gemiddeld drie tot vijf minuten duren en parallelle updates worden niet ondersteund. | Er wordt een oplossing onderzocht. |
| Azure Firewall gebruikt SNI TLS-headers om HTTPS- en MSSQL-verkeer te filteren | Als browser- of serversoftware de SNI-extensie (Server Name Indicator) niet ondersteunt, kunt u geen verbinding maken via Azure Firewall. | Als browser- of serversoftware geen ondersteuning biedt voor SNI, kunt u de verbinding mogelijk beheren met behulp van een netwerkregel in plaats van een toepassingsregel. Raadpleeg Servernaamindicatie voor software die SNI ondersteunt. |
| Kan geen firewallbeleidstags toevoegen met behulp van arm-sjablonen (Portal of Azure Resource Manager) | Azure Firewall Policy heeft een patchondersteuningsbeperking die voorkomt dat u een tag toevoegt met behulp van Azure Portal of ARM-sjablonen. De volgende fout wordt gegenereerd: de tags voor de resource kunnen niet worden opgeslagen. | Er wordt een oplossing onderzocht. U kunt ook de Azure PowerShell-cmdlet Set-AzFirewallPolicy gebruiken om tags bij te werken. |
| IPv6 wordt momenteel niet ondersteund | Als u een IPv6-adres toevoegt aan een regel, mislukt de firewall. | Gebruik alleen iPv4-adressen. Ondersteuning voor IPv6 wordt onderzocht. |
| RuleCollectionGroups verwijderen met ARM-sjablonen wordt niet ondersteund. | Het verwijderen van een RuleCollectionGroup met ARM-sjablonen wordt niet ondersteund en resulteert in een fout. | Het verwijderen van RuleCollectionGroups met ARM-sjablonen is geen ondersteunde bewerking. |
| De DNAT-regel voor toestaan van alle (*) zal SNAT-verkeer. | Als een DNAT-regel elke (*) toestaat als het bron-IP-adres, komt een impliciete netwerkregel overeen met VNet-VNet verkeer en zal het verkeer altijd worden gesnat. | Het automatische SNAT-gedrag voor DNAT-regels met elke bron is een huidige beperking. |
| Het toevoegen van een DNAT-regel aan een beveiligde virtuele hub met een beveiligingsprovider wordt niet ondersteund. | Wanneer u een DNAT-regel toevoegt aan een beveiligde virtuele hub met een beveiligingsprovider, resulteert dit in een asynchrone route voor het retourneren van DNAT-verkeer, dat naar de beveiligingsprovider gaat. | Wordt niet ondersteund. |
| Er is een fout opgetreden bij het maken van meer dan 2000 regelverzamelingen. | Het maximale aantal NAT-/toepassings- of netwerkregelverzamelingen is 2000 (Resource Manager-limiet). | De verzamelingslimiet van 2000 regels is een huidige beperking. |
| Kan de firewall niet implementeren met beschikbaarheidszones en een nieuw gecreëerd openbaar IP-adres | Wanneer u een firewall met Beschikbaarheidszones implementeert, kunt u geen nieuw gemaakt openbaar IP-adres gebruiken. | Maak eerst een nieuw zoneredundant openbaar IP-adres en wijs dit eerder gemaakte IP-adres toe tijdens de firewallimplementatie. |
| Het koppelen van een openbaar IP-adres aan Azure Firewall wordt niet ondersteund in een scenario voor meerdere tenants. | Als u een openbaar IP-adres in tenant A maakt, kunt u dit niet koppelen aan een firewall die is geïmplementeerd in tenant B. | Geen. |
| VM's achter Azure Firewall kunnen geen verbinding maken met DNAT-regelbestemmingen met behulp van het openbare IP-adres van de firewall | Wanneer VM's verkeer routeren via Azure Firewall en verbinding proberen te maken met resources die zijn geconfigureerd met DNAT-regels met behulp van het openbare IP-adres van de firewall, mislukt de verbinding. De verbindingsfout treedt op omdat Azure Firewall geen ondersteuning biedt voor het vastmaken van verkeer van interne VM's naar het eigen openbare IP-adres van de firewall voor DNAT-regelbestemmingen. | Een oplossing voor deze beperking is momenteel in ontwikkeling. |
Bekende problemen met Azure Firewall Premium
Notitie
Elk probleem dat van toepassing is op Standard, is ook van toepassing op Premium.
Azure Firewall Premium heeft de volgende bekende problemen:
| Probleem | Beschrijving | Mitigatie |
|---|---|---|
| ESNI-ondersteuning voor FQDN-resolutie in HTTPS | Versleutelde SNI wordt niet ondersteund in HTTPS-handshake. | Momenteel ondersteunt alleen Firefox ESNI via aangepaste configuratie. Voorgestelde tijdelijke oplossing is het uitschakelen van de ESNI-functie. |
| Authenticatie met clientcertificaat wordt niet ondersteund | Clientcertificaten worden gebruikt om een wederzijdse identiteitsvertrouwensrelatie tussen de client en de server te bouwen. Clientcertificaten worden gebruikt tijdens een TLS-onderhandeling. Azure Firewall onderhandelt een verbinding met de server en heeft geen toegang tot de persoonlijke sleutel van de clientcertificaten. | Geen |
| QUIC/HTTP3 | QUIC is de nieuwe primaire versie van HTTP. Het is een UDP-gebaseerd protocol op poorten 80 (PLAN) en 443 (SSL). FQDN/URL/TLS-inspectie wordt niet ondersteund. | Configureer het doorgeven van UDP 80/443 als netwerkregels. |
| Niet-vertrouwde klantondertekende certificaten | De firewall vertrouwt ondertekende certificaten van klanten niet wanneer deze worden ontvangen van een intranetwebserver. | Er wordt een oplossing onderzocht. |
| IDPS geeft het verkeerde bron-IP-adres weer voor HTTP-waarschuwingen zonder TLS-inspectie | Wanneer IDPS waarschuwingen genereert voor HTTP-verkeer zonder opmaak naar openbare IP-adressen, wordt het interne IP-adres weergegeven in plaats van het oorspronkelijke bron-IP-adres. | Er wordt een oplossing onderzocht. |
| Certificaatverspreiding | Nadat een CA-certificaat is toegepast op de firewall, kan het 5-10 minuten duren voordat het certificaat van kracht wordt. | Er wordt een oplossing onderzocht. |
| Ondersteuning voor TLS 1.3 | TLS 1.3 wordt gedeeltelijk ondersteund. De TLS-tunnel van client naar de firewall is gebaseerd op TLS 1.2 en van de firewall naar de externe webserver is gebaseerd op TLS 1.3. | Men onderzoekt updates. |
| TLSi tussenliggende CA-certificaat verloopt | In sommige unieke gevallen kan het tussenliggende CA-certificaat twee maanden voor de oorspronkelijke vervaldatum verlopen. | Verleng het tussenliggende CA-certificaat twee maanden vóór de oorspronkelijke vervaldatum. Er wordt een oplossing onderzocht. |