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.
Overzicht
Dit artikel helpt u inzicht te hebben in de huidige bekende problemen en beperkingen in Azure Firewall. Microsoft werkt deze informatie bij naarmate deze problemen oplost. Controleer daarom regelmatig op 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 servicelimieten.
Huidige capaciteitsbeperkingen
De volgende zones hebben 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. | Implementeer een nieuwe Azure Firewall in de resterende beschikbaarheidszones of gebruik een andere regio. 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 zones is geïmplementeerd, kunt u deze niet opnieuw starten. Zie fysieke en logische beschikbaarheidszones voor meer informatie. |
Implementeer een nieuwe Azure Firewall in de resterende beschikbaarheidszones of gebruik een andere regio. 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 |
Implementeer een nieuwe Azure Firewall in de resterende beschikbaarheidszones of gebruik een andere regio. 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 |
Implementeer een nieuwe Azure Firewall in de resterende beschikbaarheidszones of gebruik een andere regio. Als u een bestaande firewall wilt configureren, raadpleegt u Hoe kan ik beschikbaarheidszones configureren na de implementatie? |
| Fysieke zone 3 in US Gov Virginia | Basis en Standaard | - 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. | Implementeer een nieuwe Azure Firewall in de resterende beschikbaarheidszones of gebruik een andere regio. Als u een bestaande firewall wilt configureren, raadpleegt u Hoe kan ik beschikbaarheidszones configureren na de implementatie? |
| Fysieke zone 1, 2, 3 in Qatar Central | Basic, Standard en Premium | - Nieuwe Azure Firewall-implementaties zijn geblokkeerd. Estimated datum beschikbaar: 31 december 2026 |
Implementeer een nieuwe Azure Firewall in een andere regio. |
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:
| Issue | Beschrijving | Mitigation |
|---|---|---|
| DNAT-ondersteuning voor privé-IP-adressen beperkt tot Standard- en Premium-versies | Ondersteuning voor DNAT op Azure Firewall privé-IP-adres 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 Azure Firewall toewijzingsproces mislukt wanneer persoonlijke DNAT-regels zijn geconfigureerd | 1. De toewijzing van de Azure Firewall 2 ongedaan maken. Verwijder alle persoonlijke IP DNAT-regels 3. Wijs de Azure Firewall toe en wacht totdat het privé-IP-adres wordt ingevuld 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 gebruikt de 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 er verbinding wordt gemaakt 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 naar externe domeinen worden verzonden (zoals outlook.com en gmail.com) op TCP-poort 25. Het blokkeren van uitgaand SMTP-verkeer 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. Raadpleeg Problemen met uitgaande SMTP-connectiviteit in Azure oplossen voor meer informatie. Een andere optie is het implementeren van Azure Firewall in een standaard EA-abonnement (Enterprise Agreement). 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 2496 poorten per openbaar IP-adres per exemplaar van de virtuele-machineschaalset van de back-end. 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 Scale SNAT-poorten 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 zijn 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. De OPDRACHT PORT maakt gebruik van het privé-IP-adres van de client die niet kan worden gewijzigd. Verkeer aan de clientzijde dat de Azure Firewall passeert, wordt genat voor communicatie via internet, waardoor de PORT-opdracht door de FTP-server als ongeldig wordt gezien. | 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 elke poort in het bereik 1-65535 in netwerk- en toepassingsregels toestaat, maar NAT-regels ondersteunen alleen poorten in het bereik van 1-63999. | De beperking voor NAT-regelpoorten is een huidige beperking. |
| Azure Firewall SNI TLS-headers gebruikt 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 de portal- of Azure Resource Manager -sjablonen (ARM) | Azure Firewall Policy heeft een patchondersteuningsbeperking waarmee wordt voorkomen dat u een tag toevoegt met behulp van de 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 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. |
| 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. |
| Connectiviteitsproblemen bij het routeren van systeemeigen IPsec-verkeer van Azure VM's naar on-premises via Azure Firewall Standard | In sommige hybride implementaties gebruiken Azure virtuele machines systeemeigen IPsec-tunnels van het besturingssysteem om verbinding te maken met on-premises netwerken. Wanneer dit verkeer wordt gerouteerd via Azure Firewall Standard, met name met VPN Gateway of Globale VNet-peering, kunnen IPsec-pakketten mislukken vanwege dubbele inkapselingsscenario's (bijvoorbeeld aanvullende inkapseling die is geïntroduceerd door wereldwijde VNet-peering), wat leidt tot connectiviteitsproblemen. | Vermijd routering van systeemeigen IPsec-verkeer van Azure virtuele machines via Azure Firewall Standard. Een oplossing voor deze beperking is momenteel in ontwikkeling. |
| Beheerbewerkingen genereren DNS-query's die zichtbaar zijn in logboeken | Azure Firewall voert interne DNS-zoekopdrachten uit als onderdeel van normale beheer- en platformbewerkingen (bijvoorbeeld configuratie-updates, telemetrie en serviceconnectiviteit). Deze DNS-query's kunnen worden weergegeven in azure DNS-logboeken van klanten of hulpprogramma's voor beveiligingsbewaking, ook al worden ze niet geïnitieerd door klantverkeer. | Dit gedrag wordt verwacht en geeft geen onjuiste configuratie of beveiligingsprobleem aan. Filter of sluit indien nodig bekende Microsoft-servicedomeinen uit in DNS-bewakingsbeleid. |
bekende problemen met Azure Firewall Premium
Opmerking
Elk probleem dat van toepassing is op Standard, is ook van toepassing op Premium.
Azure Firewall Premium heeft de volgende bekende problemen:
| Issue | Beschrijving | Mitigation |
|---|---|---|
| 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. |
| Zelfondertekende certificaten bieden geen ondersteuning voor automatische verlenging | Bewerkingen voor automatisch vernieuwen mislukken wanneer zelfondertekende certificaten worden gebruikt voor TLS-inspectie. Deze beperking is van invloed op scenario's voor certificaatrotatie waarbij automatische verlenging is geconfigureerd in het firewallbeleid. | Gebruik een certificaat dat is uitgegeven door een vertrouwde certificeringsinstantie (CA) voor ondersteuning voor automatische verlenging. |
| Voor het vervangen van zelfondertekende certificaten moet TLS-inspectie worden uitgeschakeld | De Azure-portal staat het genereren van een nieuw zelfondertekend certificaat niet toe wanneer er al een is gekoppeld aan het firewallbeleid. Deze beperking is van invloed op scenario's waarin u zelfondertekende certificaten moet draaien of bijwerken. | Schakel TLS-inspectie uit en schakel deze opnieuw in en genereer het nieuwe certificaat. |
| Connectiviteitsproblemen bij het routeren van systeemeigen IPsec-verkeer van Azure VM's naar on-premises via Azure Firewall Premium | In sommige hybride implementaties gebruiken Azure virtuele machines systeemeigen IPsec-tunnels van het besturingssysteem om verbinding te maken met on-premises netwerken. Wanneer dit verkeer wordt gerouteerd via Azure Firewall Standard, met name wanneer een VPN Gateway of Globale VNet-peering is betrokken, kunnen IPsec-pakketten mogelijk niet worden doorgegeven aan de firewall, wat leidt tot verbindingsproblemen. | Vermijd routering van systeemeigen IPsec-verkeer van Azure virtuele machines via Azure Firewall Premium. Een oplossing voor deze beperking is momenteel in ontwikkeling. |