Bekende problemen en beperkingen van Azure Firewall

Dit artikel bevat de bekende problemen voor Azure Firewall. Het wordt bijgewerkt wanneer problemen worden opgelost.

Zie Azure-abonnements- en servicelimieten, quota en beperkingen voor Azure Firewall voor beperkingen.

Azure Firewall Standard

Azure Firewall Standard heeft de volgende bekende problemen:

Notitie

Elk probleem dat van toepassing is op Standard, is ook van toepassing op Premium.

Probleem Beschrijving Oplossing
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 onderzoeken mogelijkheden om dit scenario in een toekomstige release te ondersteunen.
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. Er wordt aan gewerkt om dit veld 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. Ondersteuning van deze functionaliteit staat op de planning. 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 met betrekking tot bedreigingsinformatie worden mogelijk gemaskeerd 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.
Azure Firewall DNAT werkt niet voor privé-IP-doelen DNAT-ondersteuning van Azure Firewall is beperkt tot inkomend/uitgaand internetverkeer. DNAT werkt momenteel niet voor privé-IP-doelen. Bijvoorbeeld, spoke naar spoke. Er wordt een oplossing onderzocht.

Private DNAT is momenteel beschikbaar als privé-preview. Bekijk het artikel over preview-functies van Azure Firewall voor de openbare preview-aankondiging.
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. Dit is standaard.
SNAT op inkomende verbindingen Naast DNAT worden verbindingen via het openbare IP-adres van de firewall (inkomend) met SNAT omgezet naar een van de privé-IP's van de firewall. Deze vereiste is (ook voor Actieve/Actieve NVA's) om symmetrische routering te garanderen. Als u de oorspronkelijke bron voor HTTP/S wilt behouden, kunt u XFF-headers gebruiken. Gebruik bijvoorbeeld een service als Azure Front Door of Azure Application Gateway vóór de firewall. U kunt ook WAF toevoegen als onderdeel van Azure Front Door en ketenen aan de firewall.
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 Uitgaande e-mailberichten die rechtstreeks worden verzonden naar externe domeinen (zoals outlook.com en gmail.com) op TCP-poort 25, kunnen worden geblokkeerd door het Azure-platform. Dit 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 in een standaardabonnement op Enterprise Overeenkomst (EA). Azure Firewall in een EA-abonnement kan communiceren met openbare IP-adressen met behulp van uitgaande TCP-poort 25. Op dit moment kan het ook werken in andere abonnementstypen, maar het werkt niet gegarandeerd. Voor privé-IP-adressen zoals virtuele netwerken, VPN's en Azure ExpressRoute ondersteunt Azure Firewall een uitgaande verbinding op TCP-poort 25.
SNAT-poortuitputting Azure Firewall ondersteunt momenteel 2496 poorten per openbaar IP-adres per instantie van de virtuele-machineschaalset van de back-end. Standaard zijn er twee instanties van virtuele-machineschaalsets. Er zijn dus 4992 poorten per stroom (doel-IP, doelpoort en protocol (TCP of UDP). De firewall schaalt maximaal 20 exemplaren op. Dit 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. Dit verhoogt de SNAT-poorten die vijf keer beschikbaar zijn. Wijs een IP-adresvoorvoegsel toe om downstreammachtigingen te vereenvoudigen. Voor een permanentere oplossing kunt u een NAT-gateway implementeren om de SNAT-poortlimieten te overwinnen. Deze benadering 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. Dit is standaard vanwege asymmetrische routering. Het retourtraject voor binnenkomende verbindingen gaat via de on-premises firewall, waarvoor geen verbinding is gemaakt.
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 gebruikmaken van verschillende bron-IP-adressen, 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 in deze situatie ook één IP-adres gebruiken.
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 in Azure Firewall worden met SNATed naar een van de privé-IP-adressen van de firewall om symmetrische routering te garanderen. FTP kan mislukken wanneer gegevens- en besturingskanalen gebruikmaken van verschillende bron-IP-adressen, 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. Deze PORT-opdracht maakt gebruik van het privé-IP-adres van de client die niet kan worden gewijzigd. Verkeer aan de clientzijde dat door de Azure Firewall wordt doorkruist, is geïmpteerd voor communicatie via internet, waardoor de PORT-opdracht ongeldig wordt gemaakt door de FTP-server. Dit 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. Deze beperking geldt momenteel.
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.
Het bijwerken van meerdere IP-groepen mislukt met conflictfout. Wanneer u twee of meer IP-groepen bijwerkt die zijn gekoppeld aan dezelfde firewall, krijgt een van de resources de status Mislukt. Dit is een bekend probleem/beperking.

Wanneer u een IP-groep bijwerkt, wordt er een update geactiveerd voor alle firewalls waaraan de IPGroup is gekoppeld. Als een update naar een tweede IP-groep wordt gestart terwijl de firewall nog steeds de status Bijwerken heeft, mislukt de UPDATE van IPGroup.

Om de fout te voorkomen, moeten IP-groepen die aan dezelfde firewall zijn gekoppeld, één voor één worden bijgewerkt. Laat voldoende tijd tussen updates om de firewall de status Bijwerken uit te schakelen.
RuleCollectionGroups verwijderen met ARM-sjablonen wordt niet ondersteund. Het verwijderen van een RuleCollectionGroup met ARM-sjablonen wordt niet ondersteund en resulteert in een fout. Dit is geen ondersteunde bewerking.
DNAT-regel voor het toestaan van een (*) zal SNAT-verkeer. Als een DNAT-regel een (*) toestaat als bron-IP-adres, komt een impliciete netwerkregel overeen met VNet-VNet-verkeer en wordt altijd SNAT het verkeer. Deze beperking geldt momenteel.
Het toevoegen van een DNAT-regel aan een beveiligde virtuele hub met een beveiligingsprovider wordt niet ondersteund. Dit resulteert 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). Deze beperking geldt momenteel.
XFF-header in HTTP/S XFF-headers worden overschreven met het oorspronkelijke bron-IP-adres, zoals wordt gezien door de firewall. Dit is van toepassing op de volgende gebruiksvoorbeelden:
- HTTP-aanvragen
- HTTPS-aanvragen met TLS-beëindiging
Er wordt een oplossing onderzocht.
Kan firewall niet implementeren met Beschikbaarheidszones met een nieuw gemaakt 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.
Privé-DNS-zone van Azure wordt niet ondersteund met Azure Firewall De privé-DNS-zone van Azure werkt niet met Azure Firewall, ongeacht de DNS-instellingen van Azure Firewall. Als u de wensstatus van het gebruik van een privé-DNS-server wilt bereiken, gebruikt u Azure Firewall-DNS-proxy in plaats van een Azure privé-DNS-zone.
Fysieke zone 2 in Japan - oost is niet beschikbaar voor firewallimplementaties. U kunt geen nieuwe firewall implementeren met fysieke zone 2. Als u bovendien een bestaande firewall stopt die is geïmplementeerd in fysieke zone 2, kan deze niet opnieuw worden gestart. Zie fysieke en logische beschikbaarheidszones voor meer informatie. Voor nieuwe firewalls implementeert u met de resterende beschikbaarheidszones of gebruikt u een andere regio. Zie Hoe kan ik beschikbaarheidszones configureren na de implementatie om een bestaande firewall te configureren.

Azure Firewall Premium

Azure Firewall Premium heeft de volgende bekende problemen:

Probleem Beschrijving Oplossing
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 om deze functie uit te schakelen.
Verificatie van clientcertificering 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-protocol van meer dan 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 Door de klant ondertekende certificaten worden niet vertrouwd door de firewall nadat deze is ontvangen van een intranetwebserver. Er wordt een oplossing onderzocht.
Verkeerde bron-IP-adres in waarschuwingen met IDPS voor HTTP (zonder TLS-inspectie). Wanneer HTTP-verkeer zonder opmaak wordt gebruikt en IDPS een nieuwe waarschuwing geeft en het doel een openbaar IP-adres is, is het weergegeven bron-IP-adres onjuist (het interne IP-adres wordt weergegeven in plaats van het oorspronkelijke IP-adres). Er wordt een oplossing onderzocht.
Certificaatdoorgifte Nadat een CA-certificaat is toegepast op de firewall, kan het tot 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. Updates worden onderzocht.
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.

Volgende stappen