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 |
|---|---|---|
| DNAT-ondersteuning voor privé-IP-adressen beperkt tot Standard- en Premium-versies | Ondersteuning voor DNAT op privé-IP-adres van Azure Firewall is bedoeld voor ondernemingen, dus is beperkt tot de Standard- en Premium Firewall-versies. | Geen |
| 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 voor bedreigingsinformatie kunnen worden 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. |
| 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, 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 werkt het mogelijk ook 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 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 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 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. 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. |
| 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 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. |